On Mon, Feb 3, 2025 at 12:04 AM Valery Smyslov <s...@elvis.ru> wrote:
> 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? > All good; thanks for the explanation. I think in my own case, I was a little too easily turned around about control plane versus data plane traffic in various contexts. > ## 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
