Subject: [IPsec] IKEv2 Traffic Selectors

From: Timothy Carlin <[email-masked]>
Date: Mon, 13 Feb 2012 15:37:53 -0500

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.

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 UNH-IOL would very much appreciate any thoughts the Working Group might have regarding this behavior!

Best Regards,
Timothy Carlin

----
Timothy Carlin
UNH-IOL
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Feb 2012 16:45:30 +0200

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.
> 
> 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-masked]

---

From: Timothy Carlin <[email-masked]>
Date: Fri, 24 Feb 2012 09:39:52 -0500

Hi Tero,

Thank you for your comments.  This was along the same lines as what we suspected.

Regards,
Tim Carlin