Erik Kline writes: > <snip> > > > > I.e., either this document needs to formally update RFC 4303 by allowing > any > > number or another IP protocol number must be requested to the IANA. > > As I pointed out in my previous email that is not the case. > > The RFC4303 ESP has a Next Header field which contains indicates what > type of packet is inside the ESP packet. It typically contains IP > Protocol Numbers, but not always. Thats why the RFC4303 above says > "chosen from the set of IP Protocol Numbers". > > I disagree. 4303 S2.6 is very clearly talking about the Protocol Numbers > registry (the example of "41 means IPv6" is one of the things that give it > away).
Note that IP Protocol value 41 for ESP does NOT MEAN same thing than what is described in the RFC 2473. The payload format of the ESP is different than what is described in that RFC. ESP Tunnel mode adds other pieces to the packet in different locations. The reason 41 (and 4) where chosen to match the ESP Tunnel mode is because they do have similar use than ESP Tunnel mode, but the actual protocols are different. > I think this document needs to request a protocol number from IANA. That would be one option, but then there might be issues where someone actually tries to use this outside the ESP, and because the current specification requires things to be negotiated in the IKEv2, this is not really possible, and using this outside ESP will also break the traffic flow confidentiality completely as there is no encryption of the traffic. We could also say that if the USE_AGGFRAG is negotiated for the Child SA (ESP SA) then Next header field is ignored on recipient, and sent as zeros, and all packets inside the Child SA are going to use AGGFRAG_PAYLOAD format. We do loose some information that would be helpful when debugging configuration issues, but the protocol would still work. It would also made it harder to do future enhancements to this protocol. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
