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
