NORM PI Updatedraft-ietf-rmt-pi-norm-revised-04

68th IETF - PragueBrian Adamson

NRL

Overview

• Added details for application of IPSec security to NORM– Baseline security mode for SSM operation– Also applicable to ALC

• Some editorial cleanup and clarifications.– E.g., how to NACK when sender shortens FEC

code blocks on the fly

Baseline Secure NORM Operation

• Goal: Establish a baseline “secure mode” of operation for NORM that is realizable with existing security mechanisms.

• NORM SSM operation identified as likely most pragmatic paradigm to secure.

NORM SSM Paradigm

Some Current IP Security Protocols

• IPSec– Tunnel and Transport modes

• Unicast and Multicast supported

• DTLS– TLS (aka SSL) for datagrams– Unicast only

• SRTP– Security extension to RTP

(something similar could be done using NORM/ALC “EXT_AUTH” header extension?)

– Unicast and Multicast supported

Options Investigated

• Hybrid IPSec/ DTLS– IPSec for sender->receiver(s) multicast– DTLS for receiver(s)->sender unicast

• IPSec Transport Mode– Readily available in hosts– Multicast support wr2 replay attack protection

required experimentation

• SRTP-like adaptation– Development required.

IPSec Approach Developed and Tested

• Used transport mode IPSec– AH, ESP, and ESP+AH were tested.

• Two security associations (SA) per host– Sender->receiver(s) multicast– Receiver(s)->sender unicast

• Used IPSec replay attack protection for sender->receiver(s) flow.

• Receivers->sender flows replay attack protection strategy identified using NORM header fields and sender repair window state.

Sender Protection from Receiver NACK/ACK replay

• Make use of sequence number in NORM message header– 16 bits, but receiver feedback is sparse

• Need to maintain state only for receivers that have NACKed within current sender repair window

• Replay of NACKs from outside of repair window inflict little harm– Sender may transmit limited NORM_CMD(SQUELCH) or ignore.

• Similar for congestion control feedback and other receiver ACK messages.

• RECOMMEND use of encryption to minimize chance of complex attacks on long-lived NORM sessions.– But would likely rekey before repair window space

(objectId::fecBlockId::symbolId) wraps anyway

Key Management• NORM IPSec use compatible with out-of-band key

management including:– GDOI– GSAKMP– MIKEY

• Possible that a key update message like GDOI “GROUPKEY-PUSH” could be transmitted from the sender to the group as an in-band message using NORM (or ALC) reliable transport

• Reliability mechanism helps mitigate any packets that might be dropped during a key update, but graceful rollover might be accomplished as well.

• The two SAs could use a common key?

NORM PI Revision

• Included detailed description of IPSec usage in “Security Considerations” section.

• Followed guidelines on IPSec usage specification per Steve Bellovin’s draft.

• Examined other similar approaches such as RFC4552 (OSPF WG has also recently created a group security requirements draft)

Potential Future Specification

• EXT_AUTH extension allows for similar approach to be taken above IPSec layer– Similar to SRTP, NORM/ALC header fields

could be compressed (e.g. ala RoHC)– A different approach to replay protection

could be pursued if necessary– Implementation-unique or standardized as

needed.

• TESLA details are being worked out.

Summary

• A sufficient baseline secure mode of operation has been identified and described that should allow NORM (and ALC, if it follows) to proceed forward.