pasi.ero...@nokia.com writes: > Tero Kivinen wrote: > > > pasi.ero...@nokia.com writes: > > > - Section 2.23.1: If the responder doesn't find SPD entry for > > > transport mode with the modified traffic selectors, and does a lookup > > > with the original selectors, if it finds an entry for transport mode, > > > can it use it? > > > > I do not think it can use the transport mode SA using original > > selectors. This of course depends which traffic selectors are used > > when installing the SA data to SAD. If those original selectors are > > used then incoming packets will be dropped because they do not match > > the selectors for the SA (RFC4301 section 5.2, step 5). > > Actually, the incoming packets could actually match the selectors if > they somehow take a different "route" than the IKEv2 packets, and > bypass the NAT. > > (This is what's happening in RFC5555; see below) > > > If modified selectors is used when installing SA then those selectors > > were not matched against the SPD, and this can cause spoofing attacks. > > I agree this would violate the policy. > > > > (And would that screw up the initiator processing of > > > the reply? > > > > That again depends which traffic selectors are returned. If original > > traffic selectors are returned then initiator do not get information > > about the original addresses, thus it cannot do incremental checksum > > updating. Also depending what kind of checks initiator does, it might > > cause initiator to fail the reply processing. > > > > > Unfortunately,this question is relevant for RFC 5555...) > > > > What kind of things does the RFC5555 require? > > Basically, it's assuming that even if you're running IKEv2 over IPv4 > (and that IPv4 address is NATted), you can still negotiate transport > mode SAs for IPv6 addresses (which won't get NATted).
Hmm.... Let me see. They have IKEv2 session running over IPv4 addresses, and then they try to create IPsec SA using IPv6 addresses using transport mode over that IKEv2 SA. How are they going to do it, as section 2.11 says: ---------------------------------------------------------------------- 2.11. Address and Port Agility IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and AH associations for the same IP addresses it runs over. ---------------------------------------------------------------------- which usually means that for transport mode the addresses you expect to se on ESP packets are same as what they were for the IKE packet too, which is impossible now as the IKEv2 runs over IPv4, but ESP packets run over IPv6. Also even if they use packet where src = IP1 (ipv4), and dst = IPN2 (ipv4) and then it is natted twice to src = IPN1 (ipv4) and dst = IP2 (ipv4) (using the picture in section 2.23.1), with traffic selectors: TSi = any, any, src-IPv6-address - src-IPv6-address TSr = any, any, dst-IPv6-address - dst-IPv6-address and try to negotiate transport mode using those traffic selectors, I think most of the implementations will not allow such SA to be created. As there is no NAT for the IPv6 addresses, then the SPD lookup based on the traffic selectors would be fine, but there is no way to know whether there is NAT between the IPv6 address or not, as we only tested the presense of NAT for IPv4 addresses. I think the only easy solution to that kind of problem is to run two IKEv2 SAs between the peer, one for IPv4 traffic using NAT'ed IPv4 addresses, and another using IPv6 addresses and IPv6 transport mode traffic. It seems the RFC5555 is trying to break the section 2.11 rule, and thinks IKE can be used in such way to create SAs between any IP-addresses instead between the address over which the IKE SA runs on. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
