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
