Subject: [tsvwg] Questions about src-port in draft-yong-tsvwg-gre-in-udp-encap-01

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 12 Sep 2013 11:21:36 +0100

I have a couple of transport questions about the vulnerabilities to 
off-path attacks that are posed by the current zero setting for the 
source port in the above draft, see below.

Gorry Fairhurst

---

Section 3. para 1.
- The draft currently says:
   The ingress device MAY set the
    UDP source port based on flow invariant fields from the payload
    header, otherwise it should be set to zero.
-  I still do not see why setting the source port to zero is better than 
setting to the IANA reserved value, or even better a radomised source 
port for the flow.  i.e. I am also unclear whether we should simply use 
standard UDP logic for the ephemeral port (see later).

Section 3. para 4:
    Note that the IPv6 header [RFC2460] contains a flow label field that
    may be used for load balancing in an IPv6 network [RFC6438].
- I suggest you insert a note here asking the working group for 
feedback, it strikes me that there is a chance here to recommend setting 
of the flow label.
- There certainly seems a chance here to recommend using the flow label 
in the hash (which would seem to be benign if it was not set). This 
needs to be discussed.
- The final document needs to be consistent with RFC6438.

Section 5: ICMP response
- Ideally this ICMP action should verify that the packet header 
encapsulated in the ICMP message corresponds to an active UDP session. 
Normal usage would suggest the application checks that both UDP ports 
are correct - thereby protecting from a DoS attack from a malicious node 
which is assumed to not know the source port.

---

From: Lucy yong <[email-masked]>
Date: Thu, 12 Sep 2013 15:56:38 +0000

Hi Gorry,

My reply is inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
Sent: Thursday, September 12, 2013 5:22 AM
To: [email-masked]; [email-masked]
Subject: [tsvwg] Questions about src-port in draft-yong-tsvwg-gre-in-udp-encap-01

I have a couple of transport questions about the vulnerabilities to off-path attacks that are posed by the current zero setting for the source port in the above draft, see below.

Gorry Fairhurst

---

Section 3. para 1.
- The draft currently says:
   The ingress device MAY set the
    UDP source port based on flow invariant fields from the payload
    header, otherwise it should be set to zero.
-  I still do not see why setting the source port to zero is better than setting to the IANA reserved value, or even better a radomised source port for the flow.  i.e. I am also unclear whether we should simply use standard UDP logic for the ephemeral port (see later).
[Lucy] IMO: zero is a simple value to choose for the purpose. We could let ingress tunnel to select a randomized source port for this purpose. The key is to have one source port number designated for the case when ingress tunnel is unable to generate flow entropy. I don't see that IANA reserved value for this is necessary because egress tunnel does not need to know how ingress selects the source port number. Justification for IANA reserved value is much harder; we only do it when it is necessary. 

Section 3. para 4:
    Note that the IPv6 header [RFC2460] contains a flow label field that
    may be used for load balancing in an IPv6 network [RFC6438].
- I suggest you insert a note here asking the working group for feedback, it strikes me that there is a chance here to recommend setting of the flow label.
- There certainly seems a chance here to recommend using the flow label in the hash (which would seem to be benign if it was not set). This needs to be discussed.
- The final document needs to be consistent with RFC6438.
[Lucy] For IPv6 network, there are two ways to encode the flow entropy: this draft and [RFC6438]. Which way router should be used depends on router capability. If routers support both of them, ingress tunnel can choose either one. [RFC6438] does specify that if the flow label in IPv6 header is set to zero, intermediate router should perform five tuple based load balancing. Like to hear operator feedback on the operational consideration on this.

Section 5: ICMP response
- Ideally this ICMP action should verify that the packet header encapsulated in the ICMP message corresponds to an active UDP session. 
Normal usage would suggest the application checks that both UDP ports are correct - thereby protecting from a DoS attack from a malicious node which is assumed to not know the source port.
[Lucy] We point out that using ICMP for backward compatibility generates security concern and may need other mechanism. For example, a tunneled layer/application can use its signaling protocol to sync up this capability without relying on ICMP. But we think how a tunneled layer/application to handle this is outside the scope of this draft. We can add some words to make this clearer.

Regards,
Lucy

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 12 Sep 2013 18:43:49 +0100

Hi Lucy et al - these are probably issues which various people have 
opinions on - I'll respond briefly and see who else has thoughts.

Gorry

> [Lucy] IMO: zero is a simple value to choose for the purpose. We could let ingress tunnel to select a randomized source port for this purpose. The key is to have one source port number designated f…
I am not clear about why zero is better than using the IANA-allocated 
dst number (as in RTP usage for UDP) or a random source port.

> [Lucy] For IPv6 network, there are two ways to encode the flow entropy: this draft and [RFC6438]. Which way router should be used depends on router capability. If routers support both of them, ingr…
Since [RFC6438] does not specify what to do with a zero flow label, it 
could be useful to suggest that in this BOTH could be simultaneously 
used ... at least this is worth discussing in the draft - because if it 
works it could provide a nice transition mechanism. I am sure there are 
cases where the flow label provide more entropy than visible at the 
tunnel level.

Do others have thoughts on whether to use Both or to leave this as 
something to choose by a user?

> [Lucy] We point out that using ICMP for backward compatibility generates security concern and may need other mechanism. For example, a tunneled layer/application can use its signaling protocol to s…
You suggest one solution that requires a control protocol... If we can 
do it in-band or using ICMP then the control messages may stand more 
chance of being supported by the path, even with NAPT, etc. (Using the 
randomized src port would give you this using standard ICMP).

> Lucy
Gorry

---

From: Lucy yong <[email-masked]>
Date: Thu, 12 Sep 2013 18:05:21 +0000

Gorry et al,

Yes, we like to hear other feedbacks on following issues Gorry open up.

The motivation of this draft is to use source UDP port for flow entropy and expect ingress tunnel being able to generate the flow entropy based on payload and gre header, which provides some randomized src port. For the special case where ingress tunnel can't generate flow entropy, it needs to fill a constant value that avoids the flow packet re-ordering. But I don't see how what value to use improves the security. Please explain.

Lucy

-----Original Message-----
From: Gorry Fairhurst [mailto:[email-masked]] 
Sent: Thursday, September 12, 2013 12:44 PM
To: Lucy yong
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] Questions about src-port in draft-yong-tsvwg-gre-in-udp-encap-01

Hi Lucy et al - these are probably issues which various people have opinions on - I'll respond briefly and see who else has thoughts.

Gorry

> [Lucy] IMO: zero is a simple value to choose for the purpose. We could let ingress tunnel to select a randomized source port for this purpose. The key is to have one source port number designated f…
I am not clear about why zero is better than using the IANA-allocated dst number (as in RTP usage for UDP) or a random source port.

> [Lucy] For IPv6 network, there are two ways to encode the flow entropy: this draft and [RFC6438]. Which way router should be used depends on router capability. If routers support both of them, ingr…
Since [RFC6438] does not specify what to do with a zero flow label, it could be useful to suggest that in this BOTH could be simultaneously used ... at least this is worth discussing in the draft - because if it works it could provide a nice transition mechanism. I am sure there are cases where the flow label provide more entropy than visible at the tunnel level.

Do others have thoughts on whether to use Both or to leave this as something to choose by a user?

> [Lucy] We point out that using ICMP for backward compatibility generates security concern and may need other mechanism. For example, a tunneled layer/application can use its signaling protocol to s…
You suggest one solution that requires a control protocol... If we can do it in-band or using ICMP then the control messages may stand more chance of being supported by the path, even with NAPT, etc. (Using the randomized src port would give you this using standard ICMP).

Gorry

---

From: Lucy yong <[email-masked]>
Date: Thu, 12 Sep 2013 18:39:22 +0000

Snip..

[Lucy] Here is the text from rfc6438.

   o  At intermediate routers that perform load distribution, the hash
      algorithm used to determine the outgoing component-link in an ECMP
      and/or LAG toward the next hop MUST minimally include the 3-tuple
      {dest addr, source addr, flow label} and MAY also include the
      remaining components of the 5-tuple.  This applies whether the
      traffic is tunneled traffic only or a mixture of normal traffic
      and tunneled traffic.

      *  Intermediate IPv6 router(s) will presumably encounter a mixture
         of tunneled traffic and normal IPv6 traffic.  Because of this,
         the design should also include {protocol, dest port, source
         port} as input keys to the ECMP and/or LAG hash algorithms, to
         provide additional entropy for flows whose flow label is set to
         zero, including non-tunneled traffic flows.

[Lucy]  It states that, when flow label is set to zero, router should use five tuple. If ingress tunnel generates the flow entropy and fill the entropy in both flow label and sre port, using both for LB at intermediate router does not gain anything. Like to hear other input on this.

Lucy

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 Sep 2013 13:17:04 +0100

Gorry - see in-line.

> [Lucy]  It states that, when flow label is set to zero, router should use five tuple. If ingress tunnel generates the flow entropy and fill the entropy in both flow label and sre port, using both f…
GF: I didn't read it quite this way - I read this as the intermediate 
tunnel routers had to has on the basic info from the 3-tuple, but that 
they were also allowed/recommended to add the 5-tuple (UDP) info as 
input entropy.

That doesn't really discuss what to recommend when you define a new UDP 
encapsulation that will set the UDP fields, and could (possibly) set the 
IPv6 flow label field. I was therefore wondering what we expected the 
ingress to place in the outer tunnel flow label field?

Gorry