Tero, changing the MUST to MAY is ok. If we choose SHOULD then I would prefer to present alternatives, something to the effect of "SHOULD either [do what you proposed] or accept the proposal with the use of tunnel mode, as appropriate."
Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen <kivi...@iki.fi> To: Scott C Moonen/Raleigh/i...@ibmus Cc: "ipsec@ietf.org" <ipsec@ietf.org> Date: 08/28/2009 07:47 AM Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP Scott C Moonen writes: > 1) I still prefer to echo back TS payloads as I described. I realize that > the TS payloads are the only opportunity that IKEv2 has to reproduce the > effect of IKEv1's NAT-OA payloads. But using the traffic selectors in > this way -- and only if the responder ends up agreeing to transport mode! > -- still strikes me aesthetically as quite jarring, which is certainly a > subjective thing but not a meaningless thing. :) As I indicated, I'm not > worried about being unable to deterministically fixup the checksums > because in transport mode with integrity protection, checksums aren't > critical. I'm interested to hear what other implementers think. The problem is that if you do not fix checksums incrementally you need to recalculate them completely, which is costly operation, especially when it happens after decryption, which means you cannot usually use the hardware on the network card. Then when you have recalculated them you need to recalculate them again to verify them. In some implementations you can skip that calculation by using special flags in implementation, but there is no generic way to do it (except for IPv4 UDP where you can set the checksum to 0). See RFC3948 section 3.1.2 for details. Using traffic selectors for the NAT-OA payloads is already in the RFC4306: 2.23. NAT Traversal ... The original source and destination IP address required for the transport mode TCP and UDP packet checksum fixup (see [Hutt05]) are obtained from the Traffic Selectors associated with the exchange. So this is not new thing to add to IKEv2, the problem is that currently RFC4306 does not tell how to do that so it actually works. In my text I try to fix this omission and specify how it can be done without breaking existing MUSTs in RFC4306 and trying to follow other text in RFC4306. > 2) I think we have a fundamental disagreement about whether it is proper > for addresses in foreign networks to be configured in the SPD. Our own > IKEv1 NAT-T implementation has made some (I think reasonable) design > assumptions that exclude this, even in NAT-T tunnel mode. So, briefly, > the MUST as you have written it is not even possible for our > implementation to satisfy, because by definition our SPD cannot contain > addresses from foreign networks. As you might guess, our assumptions lead > to certain implications (such as the fact that we need to do various IP > header address fixup and also port translation). I'm not sure it's worth > boring the list with all the details. Perhaps what I can do is put > together a note over the next couple of days to privately discuss our > implementation with you. I'd mainly like to make sure that if there is a > MUST here, it is written in such a way that implementations such as ours > are not broken by definition. Hmm... Actually now when you point it out, I think the MUST is too strong, as there might also be implementations which do not support tunnel mode at all (host implementations are not required to support tunnel mode), thus perhaps that second policy lookup "MUST" needs to be changed to "SHOULD" or even "MAY". Would that be acceptable for you? > 3) I agree with you about my suggested replacement text, "MUST fail the SA > negotiation." Because of the way that USE_TRANSPORT_MODE is negotiated, > what I propose is not correct. For our own implementation, the correct > behavior would be to accept the proposed SA without use of transport mode. > At the moment I'm not sure how best to word this MUST to accommodate > implementations that do and do not allow foreign network addresses in the > SPD. -- kivi...@iki.fi
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
