Subject: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-gre-in-udp-encap-18: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 27 Sep 2016 10:13:50 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-tsvwg-gre-in-udp-encap-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- Section 5: Do you need to say that (non-handshake?) traffic
that is not properly protected with DTLS MUST be discarded?

- Does 6.2(c) (in the 1st list) suggest some form of new DoS
vector? Not sure myself.

---

From: Lucy yong <[email-masked]>
Date: Tue, 27 Sep 2016 20:38:45 +0000

Hi Stephen,

Please see inline below.

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, September 27, 2016 12:14 PM
To: The IESG
Cc: [email-masked]; David L. Black; [email-masked]; [email-masked]; [email-masked]
Subject: Stephen Farrell's No Objection on draft-ietf-tsvwg-gre-in-udp-encap-18: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

- Section 5: Do you need to say that (non-handshake?) traffic that is not properly protected with DTLS MUST be discarded?
[Lucy] We can add "both tunnel encapsulator and decapsulator MUST implement the DTLS handshake protocol specified in [RFC6347]".

- Does 6.2(c) (in the 1st list) suggest some form of new DoS vector? Not sure myself.
[Lucy] the first list is the allowed conditions in order to use UDP checksum-zero in IPv6. Use of UDP checksum to detect header corruption provides a security feature caused by header corruption is discussed in Section 11.

Regards/Thanks,
Lucy

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Sep 2016 21:47:13 +0100

On 27/09/16 21:38, Lucy yong wrote:
> Hi Stephen,
> 
> Please see inline below.
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Tuesday, September 27, 2016
> 12:14 PM To: The IESG Cc: [email-masked];
> David L. Black; [email-masked]; [email-masked];
> [email-masked] Subject: Stephen Farrell's No Objection on
> draft-ietf-tsvwg-gre-in-udp-encap-18: (with COMMENT)
> 
> email addresses included in the To and CC lines. (Feel free to cut
> this introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
> information about IESG DISCUSS and COMMENT positions.
> 
> 
COMMENT:
> - Section 5: Do you need to say that (non-handshake?) traffic that is
> not properly protected with DTLS MUST be discarded? [Lucy] We can add
> "both tunnel encapsulator and decapsulator MUST implement the DTLS
> handshake protocol specified in [RFC6347]".

Sorry, I phrased my question badly. If you look at RFC6347 there
are various things said about when to discard packets (e.g. if
the sequence number is wrong in certain ways). But sometimes those
are MAY or SHOULD statements. I was wondering if you wanted to
strengthen those to MUSTs here in some or all cases.

(To be clear, I'd not suggest adding the sentence you suggest
above, though it's no harm.)

Cheers,
S.

> 
> - Does 6.2(c) (in the 1st list) suggest some form of new DoS vector?
> Not sure myself. [Lucy] the first list is the allowed conditions in
> order to use UDP checksum-zero in IPv6. Use of UDP checksum to detect
> header corruption provides a security feature caused by header
> corruption is discussed in Section 11.
> 
> Regards/Thanks, Lucy
> 
>

---

From: Edward <[email-masked]>
Date: Tue, 27 Sep 2016 13:47:15 -0700

Lucy, what is the specific text you are suggesting for the comment on
section 5 above?  I'm not sure I agree with the MUST remediation you're
suggesting, but it's contextual.

On Tue, Sep 27, 2016 at 1:38 PM, Lucy yong <[email-masked]> wrote:

> Cc: [email-masked]; David L. Black;
> [email-masked]; [email-masked]; [email-masked]
> - Section 5: Do you need to say that (non-handshake?) traffic that is not
> properly protected with DTLS MUST be discarded?
> [Lucy] We can add "both tunnel encapsulator and decapsulator MUST
> implement the DTLS handshake protocol specified in [RFC6347]".
>
> [Lucy] the first list is the allowed conditions in order to use UDP
> checksum-zero in IPv6. Use of UDP checksum to detect header corruption
> provides a security feature caused by header corruption is discussed in
> Section 11.
>
> Regards/Thanks,
> Lucy
>
>
>

---

From: Lucy yong <[email-masked]>
Date: Tue, 27 Sep 2016 21:35:23 +0000

Hi Stephen,

[Lucy] Propose to add: when a GRE-in-UDP tunnel is configured to use DTLS, upon receiving a packet not associating to the DTLS session and non-handshake message of DTLS [RFC6347], the receive MUST discard it and SHOULD log packet information. 

If this does not address your point, please propose the text you prefer.

Thanks,
Lucy

Cheers,
S.

---

From: Lucy yong <[email-masked]>
Date: Tue, 27 Sep 2016 22:39:53 +0000

Hi Stephen,	
[Lucy] Revised the text as the follow.

Sorry, I phrased my question badly. If you look at RFC6347 there are various things said about when to discard packets (e.g. if the sequence number is wrong in certain ways). But sometimes those are MAY or SHOULD statements. I was wondering if you wanted to strengthen those to MUSTs here in some or all cases.
[Lucy] Propose to add: when a GRE-in-UDP tunnel is configured to use DTLS, upon receiving a packet that is not related to the DTLS session nor a DTLS handshake message [RFC6347], the receive MUST discard it and SHOULD log packet information. 

If this does not address your point, please propose the text you prefer to see.

Thanks,
Lucy

(To be clear, I'd not suggest adding the sentence you suggest above, though it's no harm.)

Cheers,
S.

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 28 Sep 2016 08:09:56 +0100

Sent from my iPad
> On 27 Sep 2016, at 23:39, Lucy yong <[email-masked]> wrote:
> 
> 
> Hi Stephen,    
[gorry] **when** DTLS is used, this seems correct.

(To be clear, since this is an encapsulation protocol I would question a suggestion that the router end points should use DTLS as a default, I rather suggest that security should be end to end, and this is an option.)

>> corruption is discussed in Section 11.
[gorry]  this is not really a security function IMHO  - integrity detection and endpoint verification are a basic need of a transport protocol.   To me, the section 11 text highlights the limitations of this method which in some context may have security implications.

>> Regards/Thanks, Lucy
Gorry

---

From: "Black, David" <[email-masked]>
Date: Wed, 28 Sep 2016 19:55:37 +0000

Two comments as draft shepherd:

-- Section 5

> > Sorry, I phrased my question badly. If you look at RFC6347 there are various
> things said about when to discard packets (e.g. if the sequence number is wrong
> in certain ways). But sometimes those are MAY or SHOULD statements. I was
> wondering if you wanted to strengthen those to MUSTs here in some or all cases.
> > [Lucy] Propose to add: when a GRE-in-UDP tunnel is configured to use DTLS,
> upon receiving a packet that is not related to the DTLS session nor a DTLS
> handshake message [RFC6347], the receive MUST discard it and SHOULD log
> packet information.
> >

I agree with this.

Otherwise I strongly prefer to decline Stephen's invitation to start specifying a
GRE/UDP-specific profile of DTLS  via GRE/UDP-specific changes to  RFC 6347's
implementation requirements.

-- Section 6.2, item (c)

> >> order to use UDP checksum-zero in IPv6.

I don't think so.

The motivation for 6.2(c) is that when a zero UDP checksum is used with IPv6, there
is no checksum coverage of UDP ports, so something ought to be done.  The goal of
6.2.c is to make it more likely that corruption of the otherwise-checksum-unprotected
UDP destination port will result in the received packet being ignored and/or discarded
because there's nothing listening on the port to which the corruption mis-directed
the packet.

Thanks, --David

> From: Gorry Fairhurst [mailto:[email-masked]]
> Sent: Wednesday, September 28, 2016 3:10 AM
> To: Lucy yong
> Cc: Stephen Farrell; The IESG; Black, David; draft-ietf-tsvwg-gre-in-udp-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-gre-in-
> udp-encap-18: (with COMMENT)
> 
> 
> 
> Sent from my iPad
> > Sorry, I phrased my question badly. If you look at RFC6347 there are various
> things said about when to discard packets (e.g. if the sequence number is wrong
> in certain ways). But sometimes those are MAY or SHOULD statements. I was
> wondering if you wanted to strengthen those to MUSTs here in some or all cases.
> > [Lucy] Propose to add: when a GRE-in-UDP tunnel is configured to use DTLS,
> upon receiving a packet that is not related to the DTLS session nor a DTLS
> handshake message [RFC6347], the receive MUST discard it and SHOULD log
> packet information.
> >
> (To be clear, since this is an encapsulation protocol I would question a suggestion
> that the router end points should use DTLS as a default, I rather suggest that
> security should be end to end, and this is an option.)
> 
> [gorry]  this is not really a security function IMHO  - integrity detection and
> endpoint verification are a basic need of a transport protocol.   To me, the section
> 11 text highlights the limitations of this method which in some context may have
> security implications.
> 
> >> Regards/Thanks, Lucy
> >
> Gorry