Scott C Moonen writes: > Tero, I am not comfortable with the following statement: > > . . . thus it will send back traffic selectors having IPN1 and IP2 > as their IP addresses . . . > > I would prefer that the server re-map the TS values back to IP1 and IPN2 > when sending its response.
This is not possible, as the other end needs to know the address if IPN1 and IP2 (those are not known to him otherwise). Those addresses are used as original source and destination addresses for incremental checksum fixup. > This is consistent with the general > expectation that the response's TS payloads are a subset of the request's > payloads. Yes, but then we still would have problem that we do not get the original addresses from anywhere. Currently IKEv2 says they are taken from the traffic selectors, but if we do not send IPN1 and IP2 back from responder to initiator, initiator does not get them anywhere. > The client does not absolutely need this information (it would > perhaps help for deterministic checksum fixup, however in transport mode > as long as an integrity algorithm is used the checksum provides no > additional value anyway). RFC3948 do want them to do incremental checksum fixup, and one of the reasons we want to modify this text is to provide that information. > I think it is also advantageous to contain this > fixup processing to one code path (processing TS payloads in received > requests), and it also simplifies the response message processing (the > client does not need to complicate its checks to verify that the > response's TS payloads are a subset of the request's). This separation of > responsibility is more advantageous to a client implementation that needs > to be as minimal as possible. Yes, it might make it bit more simplier, but would loose functionality that is supposed to be there. The initiators processing of the responders reply is quite simple anyways, i.e. check if USE_TRASPORT_MODE was returned (i.e. transport mode was selected), and if so store traffic selectors as original addresses, and replace them similarly as is done in other cases. Then normal processing can continue without any changes (i.e. traffic selector verification, IPsec SA installing etc). > Finally, what I propose above is how our own IKEv1 implementation works in > cases where ID payloads are sent for transport mode. :) As a responder we > found it best to bend over backwards to cater to the initiator's view of > the world. In IKEv1 there is separate payloads for sending the original addresses. In IKEv2 we do not have that, thus we must use traffic selectors for that. > I'm also concerned about the following statement: > > After this it does SPD lookup based on those new traffic > selectors. . . . > If entry is found but it does not allow transport mode, then MUST > undo the address substitution and redo the SPD lookup using the > original traffic selectors. . . . > > This statement is incoherent to me. From the fact that the initiator > proposed transport mode, it is clear that the initiator identifies TSi > with itself and TSr with the server. No. As USE_TRASPORT_MODE is only hint in IKEv2. Responder has full choice of ignoring it and using tunnel mode instead. TSi and TSr do NOT identify initiator at all, initiator is already identified by the ID payloads. TSi and TSr are used to select suitable SPD entry for the given identified initiator. As for transport-mode NAT-T case the original TSi and TSr can be quite unknown for the responder, we first try with the converted addresses, but if we need to fall back to tunnel-mode NAT-T, then we want to keep original traffic selectors as now the packets exiting from the tunnel will have those addresses (i.e. packets coming from the tunnel will have IP1 and IPN2 as their source and destination addresses, as NAT in the middle does not substitute them). > The address substitution exactly > translates these addresses into the domain of the responder's SPD. If the > responder's policy indicates that transport mode is not acceptable for > this SPD entry, then I think the only possible outcome is that SA > negotiation should be failed. No other SPD entry could possibly match the > initiator's intentions. Initiator asked that if possible use transport mode with these addresses, if transport mode is not possible then use tunnel mode. Even if transport mode was not allowed, it is possible that responder do have tunnel mode rule that is allowed for that client even when transport mode was not. I do not see how you can claim that "No other SPD entry" could not be found, as initiator only gave hint that it would like to use transport mode. The use of tunnel vs transport mode is fully based on the responders policy. > However, the MUST quoted above causes the > responder to treat these addresses in an incoherent way: > > 1) The responder has detected a NAT in front of the initiator, so treating > IP1 as being within the domain of the responder's SPD isn't appropriate; > we need to use IPN1. Yes, for transport mode. For tunnel mode the IP1 is within the domain of responder's SPD as that is what responder will see in the packets coming out from the tunnel. > 2) NATs aside, the responder knows that the initiator identifies IP1 with > the initiator itself (because the initiator proposed transport mode), so > treating IP1 as anything other than the initiator (i.e., IPN1) -- perhaps > as some address behind the initiator for which it is acting as a gateway > -- isn't appropriate, because the initiator could not possibly have had > gateways in mind. I do not understand that statement at all. Other end is identified by the ID payloads, not by traffic selectors or by IP-addresses. If NATs are involved it is completely possible that responder have multiple clients connecting to it each having same IP1 (10.0.0.1) as their TSi field. Also it is possible that it has multiple clients using different IP1, but using same IPN1 as their outer address (but different ports for UDP encapsulation). RFC 3948 security considerations section has text about these different overlapping address problems. > 3) The responder has detected a NAT in front of itself, so treating IPN2 > as being within the domain of the responder's SPD isn't appropriate; we > need to use IP2. Again only for transport mode. For tunnel mode IPN2 is again ok, as that is the packet which is exiting from the tunnel. Of course if tunnel mode was used instead of transport mode then the implementation must use some method to make sure that those packets exiting from the tunnel and having destination address of IPN2 are still directly processed by the local stack. > 4) NATs aside, the responder knows that the initiator identifies IPN2 as > the responder (because the initiator proposed transport mode), so treating > IPN2 as anything other than the responder (i.e., IP2) -- as though it were > some address behind the responder for which the responder is acting as a > gateway -- isn't appropriate, because the initiator could not possibly > have had gateways in mind. > > I don't think this is an appropriate way for the responder to interpret > TSi and TSr. I propose that the MUST above be changed to "MUST fail the > SA negotiation." That would be against the 1.3.1 of the IKEv2bis or 3.10.1 of RFC4306 which says: ... If the request is accepted, the response MUST also include a notification of type USE_TRANSPORT_MODE. If the responder declines the request, the Child SA will be established in tunnel mode. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
