1 / 5

draft-ietf-msec-ipsec-extensions-04.txt

draft-ietf-msec-ipsec-extensions-04.txt. Brian Weis George Gross Dragan Ignjatic. Progress since IETF 66. Changes from -02 Many minor editorial & housekeeping changes George added a nice security considerations section. Lakshminath posted a request for comments on the IPsec mailing list

shino
Download Presentation

draft-ietf-msec-ipsec-extensions-04.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. draft-ietf-msec-ipsec-extensions-04.txt Brian Weis George Gross Dragan Ignjatic

  2. Progress since IETF 66 • Changes from -02 • Many minor editorial & housekeeping changes • George added a nice security considerations section. • Lakshminath posted a request for comments on the IPsec mailing list • Pasi Eronen kindly responded with three substantive comments discussed here • Waiting for more comments IETF67

  3. Pasi Comment 1 • Sections 4.1.2 and 4.4.2 are not quite clear whether IPsec SAs for multicast are unidirectional (separate SAs for sending and receiving) or possibly bidirectional (a bigger change to RFC4301). Response: • Section 4.1.2 last sentence specifically says that the SAD behaves the same as RFC4301. • Section 4.4.2 does mention that the GKM must provide a "direction attribute". Action: • Section 4.4.2 describes GSPD directionality, not SA directionality. Text will be added describing the relationship between GSPD directionality and SA creation. IETF67

  4. Pasi Comment 2 2) Section 4.1.3.1: "An implementation SHOULD offer PAD configuration capabilities that authorize the GKM policy configuration mechanism to set security policy for other aspects of an endpoint's GSPD/SAD configuration, not confined to its group security associations. This capability allows the group's policy to inhibit the creation of backchannels that might otherwise leak confidential group application data.” Why? Response: • What this was intended to enable are security policies that would use the SPD-O DISCARD processing option to prevent an insider Adversary from re-broadcasting (either multicast or unicast) the group's data (e.g. a pay-per-view content). • But Pasi points out that a SPD/PAD policy of "discard all outgoing traffic" would be needed to prevent it from sending it to someone else, and dislikes the SHOULD which overrides all other policy. Action: • Authors will discuss and clarify the threat of insider attacks. IETF67

  5. Pasi Comment 3 3) Appendix A.2 seems to suggest that GKM can also set up unicast IPsec SAs? ("However, the unicast inverse flows can use the group's IPsec group authentication mechanism.") This text needs clarification. Response: • One of the use cases is NORM, which does multicast from the Group Speaker to the Group Receivers, and unicast from Group Receiver(s) to the Group Speaker. The unicast messages include NACK repair requests, congestion control metering, and other session control messages. • Pasi replies that “the important thing to mention (if it is really the case) is that GKM can create unicast SAs. This complicates several things, such as SPI selection (which would need to be coordinated with the unicast key management subsystem). Currently, the draft does not seem to consider these issues. Action: • Authors will explicitly mention the NORM use case • Authors will discuss the implications of creating unicast SAs. IETF67

More Related