Hi Tero, Thank you for your comments. This was along the same lines as what we suspected.
Regards, Tim Carlin On Feb 14, 2012, at 9:45 AM, Tero Kivinen wrote: > Timothy Carlin writes: >> Hello, >> >> During testing, the UNH-IOL has encountered a behavior with regards >> to the handling of Traffic Selectors that causes interoperability >> issues. >> >> The issue center around the handling of this quote from RFC 5996, >> Section 2.9: >> >> “To enable the responder to choose the appropriate range in this case, >> if the initiator has requested the SA due to a data packet, the >> initiator SHOULD include as the first Traffic Selector in each of TSi >> and TSr a very specific Traffic Selector including the addresses in >> the packet triggering the request.” >> >> >> We've seen that implementations acting as the responder handle the >> Very Specific Traffic Selector in different ways, resulting in >> non-interoperability. Some implementations reject the connection, >> due to not matching configured selectors, while other >> implementations accept only this traffic selector, inadvertently >> narrowing the tunnel. > > Both of these types of implementation are not really following the > spirit of the IKEv2 RFC. > > The ones who reject the connection, only support startup style SAs, > and nothing else (which is allowed by IKEv2, but it is very limited > implementation). > > The others which only accept only this traffic selectors, usually are > limited to exactly one traffic selector, i.e. they do not support > multiple traffic selectors (which again is allowed by IKEv2, but again > is very limited implementation). > > I would myself consider both of them as broken IKEv2 implementations, > and not to be used outside the very specific scenarios. > > Most of these are IKEv1 implementations hacked to support IKEv2 very > quickly and in their hacking they didn't want to support multiple > traffic selectors in the same SA, as that would change the IPsec > packet engine also. > >> This also causes a detrimental oddity when the data packet causing >> SA creation is an ICMPv6 Echo Request. In this case, both TSi and >> TSr indicate ICMPv6, type 80, Code 00. This is a special case, >> since ICMP has no source and destination port. What should the >> proper behavior be for a packet type with no source and destination >> port? > > The RFC4301 section 4.4.1.3 has text about the ICMP "port" selectors, > but that text really only covers the policy parts. When filling up the > data from the packet information to the TS, this is not that much > applicable, but on the other hand the first TS is also matched against > the local policy, so they should be compatible. > > For the first TS matching the packet, I think best would be to use > both src and dst "port" selectors as same value, i.e. copy the value > to both fields. > > On the other hand reading 4.4.1.3 and matching the case C and D: > > ---------------------------------------------------------------------- > C. If a system is willing to send traffic with a particular > "port" value but NOT receive traffic with that kind of > port value, the system's traffic selectors are set as > follows in the relevant SPD entry: > > Local's > next layer protocol = ICMP > "port" selector = <specific ICMP type & code> > > Remote's > next layer protocol = ICMP > "port" selector = OPAQUE > > D. To indicate that a system is willing to receive traffic > with a particular "port" value but NOT send that kind of > traffic, the system's traffic selectors are set as follows > in the relevant SPD entry: > > Local's > next layer protocol = ICMP > "port" selector = OPAQUE > > Remote's > next layer protocol = ICMP > "port" selector = <specific ICMP type & code> > > For example, if a security gateway is willing to allow > systems behind it to send ICMP traceroutes, but is not > willing to let outside systems run ICMP traceroutes to > systems behind it, then the security gateway's traffic > selectors are set as follows in the relevant SPD entry: > > Local's > next layer protocol = 1 (ICMPv4) > "port" selector = 30 (traceroute) > > Remote's > next layer protocol = 1 (ICMPv4) > "port" selector = OPAQUE > ---------------------------------------------------------------------- > > (I.e. Local => incoming from the clear side, going to the SA, remote > => incoming from SA, going to the clear side). > > This would mean that if SGW has policy that allows clients to ping it > but not anything behind the SGW to ping out that would be the case C, > i.e. SGWs Local's policy part would say ICMP echo request and that > would match the incoming TSr, and the SGWs Remote's policy part would > say OPAQUE (i.e. TSi). For the normal narrowing rules to work this > would require the initiator system to use: > > TSi=ICMP, OPAQUE > TSr=ICMP, echo request > > I.e that would match the C case and would also case the case where the > SGWs policy says TSi=ICMP, ANY, TSr=ICMP, ANY. If you do what I > proposed earlier by putting both TSi and TSr same echo request, that > would not match the OPAQUE, and the policy negotiation would fail. On > the other hand using OPAQUE might cause other implementations to > fail... > > That is if I read the RFC4301 properly... > > On the other hand how many implementations have really implemented > that part of the ICMP filtering, I think most of the implementations > do not really care about the ICMP type and code, and am not sure how > many really implement ICMP OPAQUE parts... > >> The UNH-IOL would very much appreciate any thoughts the Working >> Group might have regarding this behavior! > -- > [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
