Subject: [IPsec] Suggested ikev2bis traffic selector clarification

From: Scott C Moonen <[email-masked]>
Date: Mon, 18 Aug 2008 11:44:14 -0400

With at least one particular build of racoon2, I'm finding that I'm able 
to configure it such that it responds to the following traffic selector 
request:

        TSi: (ICMP, 2048-2048, 9.1.1.1-9.1.1.1), (0, 0-65535, 
9.1.1.1-9.1.1.1)
        TSr: (ICMP, 2048-2048, 9.2.2.2-9.2.2.2), (0, 0-65535, 
9.2.2.2-9.2.2.2)

with the following response:

        TSi: (0, 2048-2048, 9.1.1.1-9.1.1.1)
        TSr: (0, 2048-2048, 9.2.2.2-9.2.2.2)

What is surprising about this response is that it combines protocol 0 (all 
protocols) with a port specification.  RFC 4301 hints that this is not 
correct; when it describes the SPD, it indicates that "several additional 
selectors depend on the Next Layer Protocol value", and goes on to define 
port, type and code values only for TCP, UDP, ICMP, ICMPv6, and MIPv6. 
Similarly, RFC 4306 hints that this is not correct; it states that "for 
protocols for which port is undefined, or if all ports are allowed," the 
start port "MUST be zero" and the end port "MUST be 65535."  The only 
problem is that RFC 4306 doesn't clarify whether protocol 0 is a protocol 
for which port is undefined.

I do believe from my reading of both RFCs 4301 and 4306 that it is 
reasonable to expect not to see a port specification for a traffic 
selector with protocol 0, and in fact from RFC 4301 it seems that a 
compliant implementation could not express such a specification in its 
SPD, so that an SA using this specification could not be accepted. 
Furthermore, allowing this specification is a weak security risk; it's not 
obvious to the casual observer that the tunnel for protocol=0, port=2048 
can actually carry ICMP echo requests, but it can.  I'd like to suggest 
that the ikev2bis draft clarify the traffic selector description to 
indicate that the port range must be 0-65535 for protocol 0, such as the 
following:

   o  Start Port (2 octets) - Value specifying the smallest port number
      allowed by this Traffic Selector.  For protocols for which port is
      undefined, including protocol 0; or if all ports are allowed, this
                ^^^^^^^^^^^^^^^^^^^^^^
      field MUST be zero.  For the ICMP protocol, the two one-octet
      fields Type and Code are treated as a single 16-bit integer (with
      Type in the most significant eight bits and Code in the least
      significant eight bits) port number for the purposes of filtering
      based on this field.

   o  End Port (2 octets) - Value specifying the largest port number
      allowed by this Traffic Selector.  For protocols for which port is
      undefined, including protocol 0; or if all ports are allowed, this
                ^^^^^^^^^^^^^^^^^^^^^^
      field MUST be 65535.  For the ICMP protocol, the two one-octet
      fields Type and Code are treated as a single 16-bit integer (with
      Type in the most significant eight bits and Code in the least
      significant eight bits) port number for the purposed of filtering
      based on this field.

Is that acceptable?

By the way, I'm not trying to heap too much blame on racoon2 here.  It was 
an accidental pathological config in the first place (protocol=ALL, 
sport=2048, dport=2048) that caused this pathological response to be sent. 
 At the same time, I think it is helpful for implementations to know that 
this sort of traffic selector specification is invalid by definition and 
should not be sent or received.

Thanks,

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Dan McDonald <[email-masked]>
Date: Mon, 18 Aug 2008 12:00:25 -0400

On Mon, Aug 18, 2008 at 11:44:14AM -0400, Scott C Moonen wrote:
<SNIP!>
> for which port is undefined.

Consider a protocol like DNS which runs over either TCP or UDP while
utilizing the same port.  That'd be a perfect excuse for using proto=0,
port!=0.

>       undefined, including protocol 0; or if all ports are allowed, this

Only if we don't think there will be policies that exploit TCP or UDP over
the same port.  I suppose the extra cut-and-paste line(s) of configuration
(TCP line(s) + UDP line(s) + SCTP line(s)) would be acceptable, but let's at
least think a little about it.

Dan

---

From: [email-masked]
Date: Tue, 19 Aug 2008 19:05:51 +0900

> utilizing the same port.  That'd be a perfect excuse for using proto=0,

That will leave a question what to do with ICMP or MH.  Also, any
future protocol with protocol field.

As for the racoon2 behavior in question, it is somewhat intentional
feature, as I saw it not prohibited and I decided to let the kernel
IPsec routine decide what to do with it, although probably racoon2
should issue a warning message, at least.  I can accept prohibiting
it.

					FUKUMOTO Atsushi
					[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec