1. NORM PI Update draft-ietf-rmt-pi-norm-revised-04 68th IETF - Prague Brian Adamson NRL

2. 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

3. 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.

4. NORM SSM Paradigm

5. 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

6. 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.

7. 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.

8. 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

9. 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?

10. 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)

11. 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.

12. 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.