Subject: [tsvwg] Editorial comments on draft-yong-tsvwg-gre-in-udp-encap-01

From: [email-masked]
Date: Thu, 12 Sep 2013 11:15:24 +0100

Please see below some comments on the present use of keywords and text in
the draft (I'll forward a second email shortly with a few questions).

Gorry

----

Section 1. Last para
- This sentence does not make sense to me:
  Hash functions in existing IP routers a GRE-in-UDP tunnel
   transits will automatically utilize and benefit from this procedure
   without needing any change or upgrade.
- Is something like this better:
  Hash functions in existing IP routers will automatically utilize
  and benefit from a GRE-in-UDP tunnel
   without needing any change or upgrade to the forwarding.

Section 1. Last para
   Wide Area networks.
                   ^
- suggest you remove capitalisation, but if you keep it, then please
capitilise 'n'.

Section 2.
- This section misses a RFC 2119 standards declaration.

Para 3:
   To simplify packet processing at the tunnel egress, packets destined
   to this special UDP destination port [TBD] should have their UDP
              ^^^^^                                           ^^^^
- change /special/ to /assigned/
- should? - I think this needs to be SHOULD, with an explanatory sentence
explaining that this is the mechanism used by receivers to identify this
protocol.

Para 3:
   relax this constraint to allow the zero UDP
   checksum.
- This needs to add "for specific use-cases" and then para 5 needs to
directly follow this. This keeps the implications clear.

Para 5:
      In addition IPv6 nodes must conform to the following:
- This needs to be a MUST.

Section 4
   If a tunnel ingress must perform fragmentation on a packet before
   encapsulation, it must use the same source
- The second /must/ is a requirement, please replace by MUST.

para 3:
   Tunnel end points that support
   ECN must use the method described in
- This needs to be a MUST!

Section 6:
- Do you wish to ask IANA for a service name for this port - I think you
should.

Section 7.1
- Transport protocols in general should describe the vulnerabilities to on
and off-path attack. The standard defence to off-path data injection
attacks is to use port randomisation of the source port. At the moment
this draft does not provide this function, and this may be a serious issue
to consider. It could be resolved by requiring the sender to set the
source port using the standard algorithm.
- RFC 6056 is BCP.
- Please update the security considerations section of the draft to
identify this issue.

Section 7.1
- A second issue is that there is no ICMP verification method specified.
This also leads to an off-path DoS vulnerability.
- RFC 6056 is BCP.
- Please update the security considerations section of the draft to
identify this issue.

Section 10
- Please add normative reference to RFC 2119.
- I am not sure that RFC 6335 is normative?

---

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

Hi Gorry,

Thank you very much for the review and suggestion. I am fine with editing suggestions.

Regarding the resilience to off-path attack, although UDP, in general, is used as a transport protocol, this application only uses it to provide flow entropy. Both tunnel endpoints do not rely on UDP protocol to provide any transport function. This is the difference from other UDP protocol usages. Zero value in source UDP port is used if the ingress tunnel is unable to generate flow entropy from the payload and/or gre header, which results all the encapsulated packets forwarded to the same path over IP networks. Therefore, IMO, rfc6056 does not help off-path attack for this case. If an ingress tunnel end point uses the algorithm in rfc6056 to generate one Ephemeral port for this purpose, it works.

We point out that ICMP verification method prompt some security concern but think the solution addressing that is out of the scope of this document. Based on the application, there are some ways to address it. For example, application layer could use signaling protocol to confirm the use of this encapsulation for tunneling; then tunnel ingress will ignore ICMP notice.

Other authors may have opinion on these.

Thanks,
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, September 12, 2013 5:15 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Editorial comments on draft-yong-tsvwg-gre-in-udp-encap-01 

Please see below some comments on the present use of keywords and text in the draft (I'll forward a second email shortly with a few questions).

Gorry

----

Section 1. Last para

Section 1. Last para
   Wide Area networks.
                   ^
- suggest you remove capitalisation, but if you keep it, then please capitilise 'n'.

Section 2.

Para 3:
   To simplify packet processing at the tunnel egress, packets destined
   to this special UDP destination port [TBD] should have their UDP
              ^^^^^                                           ^^^^
- change /special/ to /assigned/
- should? - I think this needs to be SHOULD, with an explanatory sentence explaining that this is the mechanism used by receivers to identify this protocol.

Para 3:
   relax this constraint to allow the zero UDP
   checksum.
- This needs to add "for specific use-cases" and then para 5 needs to directly follow this. This keeps the implications clear.

Para 5:

Section 4

para 3:

Section 6:
- Do you wish to ask IANA for a service name for this port - I think you should.

Section 7.1
- Transport protocols in general should describe the vulnerabilities to on and off-path attack. The standard defence to off-path data injection attacks is to use port randomisation of the source port. At the moment this draft does not provide this function, and this may be a serious issue to consider. It could be resolved by requiring the sender to set the source port using the standard algorithm.
- RFC 6056 is BCP.
- Please update the security considerations section of the draft to identify this issue.

Section 7.1
- A second issue is that there is no ICMP verification method specified.
This also leads to an off-path DoS vulnerability.
- RFC 6056 is BCP.
- Please update the security considerations section of the draft to identify this issue.

Section 10

---

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

> Regarding the resilience to off-path attack, although UDP, in general, is used as a transport protocol, this application only uses it to provide flow entropy. Both tunnel endpoints do not rely on U…
Leastways for this draft - I suggest it would be useful to decsribe the 
attack.

> We point out that ICMP verification method prompt some security concern but think the solution addressing that is out of the scope of this document. Based on the application, there are some ways to…
Again, let's first document and see whether a protocol mechanism is needed.

Thanks,

Gorry

---

From: Lucy yong <[email-masked]>
Date: Thu, 12 Sep 2013 17:53:29 +0000

-----Original Message-----
From: Gorry Fairhurst [mailto:[email-masked]] 
Sent: Thursday, September 12, 2013 12:33 PM
To: Lucy yong
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] Editorial comments on draft-yong-tsvwg-gre-in-udp-encap-01

> Regarding the resilience to off-path attack, although UDP, in general, is used as a transport protocol, this application only uses it to provide flow entropy. Both tunnel endpoints do not rely on U…
Leastways for this draft - I suggest it would be useful to decsribe the attack.
[Lucy] I am not sure that using rfc6056 can prevent off-path attack in this application. In this application, the udp source port is used for flow entropy, egress tunnel can't perform any sanity check against UDP source port. What do I miss here?

[Lucy] agree.

Lucy

Thanks,

Gorry

---

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

See a couple of comments in-line.

Gorry

On 12/09/2013 18:53, Lucy yong wrote:
> Leastways for this draft - I suggest it would be useful to describe the attack.
GF: So are you saying there is no off-path vulnerability or something 
else? ... The text I was suggesting to write was to document the case, 
rather than to solve this - though clearly documenting a solution is 
better (I think we should understand if this is some special usage of 
the src-port field that needs to be considered or whether it's just 
normal practice).

> Again, let's first document and see whether a protocol mechanism is needed.
GF: OK, so my suggestion was to add security considerations text to 
identify the issue.