Hi Erik, please see inline.
> Erik Kline has entered the following ballot position for > draft-ietf-ipsecme-g-ikev2-20: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot- > positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Internet AD comments for draft-ietf-ipsecme-g-ikev2-20 > CC @ekline > > * comment syntax: > - https://github.com/mnot/ietf-comments/blob/main/format.md > > * "Handling Ballot Positions": > - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > > ## Comments > > ### S4.4.2 > > * "UDP encapsulation of ESP packets [RFC3948] cannot be specified in > G-IKEv2 and thus it is not used for the multicast Data-Security SAs." > > I didn't immediately follow why this should necessarily be true. If > there's an explanation, or a link to section I didn't properly grok, > some brief addition might be nice. UDP encapsulation is used in IPsec to allow NAT traversal (NATs usually have trouble with mapping outbound ESP traffic to inbound one if pure ESP is used). In IKEv2 UDP encapsulation is not negotiated explicitly: if both peers support it, then they evaluate whether NAT is present in between during IKE SA establishment and if this is the case, they just encapsulate ESP in UDP. With G-IKEv2 the presence of NATs between the GM and the GCKS doesn't matter. The possible presence of NATs between group senders and group receivers would have mattered, but the GCKS is in general unaware of this. In addition, we believe that NATs would not be as unfriendly to multicast ESP SAs as they are to unicast communications, because multicast traffic is unidirectional and NATs do not need to do any mapping of inbound/outbound SAs - they can just change source IP as they like, thus no UDP encapsulation is needed. And the last point - we also think that using NATs for multicast ESP is moot in general - RFC 4301 specifies that source IP address may also be used (e.g. in case of SSM) when mapping an incoming ESP packet to an SA (along with the SPI and the destination IP), so at lease NATs should not change source IP on their discretion. Sorry for long and messy explanation. We thought it was too long to include into the document, and we failed to compact it :-) Do you think that some text should be added anyway? > ## Nits > > ### S1 > > * "where multicast communications indicated with double line" -> > "where multicast communications are indicated with a double line" Fixed, thank you. Regards, Valery. _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
