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

[Lucy yong <[e-mail]>]

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

On 12/09/2013 16:56, Lucy yong wrote:
> 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.
>
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?


> 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.
>
Again, let's first document and see whether a protocol mechanism is needed.
[Lucy] agree.

Lucy

> Other authors may have opinion on these.
>
> Thanks,
> Lucy
>
Thanks,

Gorry
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, September 12, 2013 5:15 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> 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
> - 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?
>
>
>
>