Subject: [tsvwg] Review of draft-ietf-tsvwg-gre-in-udp-encap

From: Eliot Lear <[email-masked]>
Date: Mon, 9 May 2016 12:52:48 +0200

Hi,

I've reviewed draft-ietf-tsvwg-gre-in-udp-encap.

This document is generally well written, and almost ready to go.  I have
some small suggestions and a three or two below.

In Section 1:
>    A GRE-in-UDP tunnel offers the additional possibility of using GRE
>    across networks that might otherwise disallow it; for instance GRE-
>    in-UDP may be used to bridge two islands where GRE is not used
>    natively across the Internet.

I think what you're getting at here is that GRE is blocked either due to
security considerations or because it throws some routers out of the
fast path and hence is blocked for performance reasons.  A small
discussion of that seems warranted in order to justify the new
encapsulation.

Also somewhere in the introduction you should probably explain why a
non-DTLS version is needed.

Section 2.1.1:

>    3. GRE-in-UDP tunnel MUST NOT be used for traffic that does not
>    implement congestion control. IP-traffic can be assumed to be
>    congestion-controlled. GRE-in-UDP tunnels are not appropriate for
>    other traffic that does not use congestion control.

Leave a forward reference, a'la "this will be discussed in Section 8".

>    4. UDP source port values that are used for flow entropy SHOULD be
>    chosen from the ephemeral port range (49152-65535).

Reference(s) required.  Specifically, please define for the reader the
term "flow entropy". This is linked to [RFC5405bis].  Neither actually
define the term.  Moreover, this requirement seems to repeat the
requirement in Section 5.1.1 of that document.  Why is that done?

Section 2.1.2:

>    The section lists the changed requirements for a TMCE GRE-in-UDP
>    Tunnel that applies to a traffic-managed controlled environment.
>    This replaces requirements 1-3 listed in Section 2.1.1. The
>    requirements 4-7 in Section 2.1.1 remain unchanged for a TMCE GRE-
>    in-UDP Tunnel.

If I understand your intent correctly, it's probably just better to
separate out requirements into three groups:

 1. General requirements (2.1)
 2. Requirements for non-TMCE (2.1.1)
 3. Requirements for TMCE (2.1.2)

This "replaces" business makes the document hard to read by adding
excessive cross referencing.

Section 8:

>    In many cases, a GRE-in-UDP tunnel is used to carry IP traffic. IP
>    traffic is generally assumed to be congestion controlled, and thus a
>    tunnel carrying general IP traffic generally does not need
>    additional congestion control mechanisms.

I don't know why IP traffic is considered any safer than other traffic. 
IP traffic can be just as unsafe as any other traffic.  Even TCP can
misbehave.  I think the question you are aiming for is how do you detect
when there is a lack of congestion control?  This sort of aims towards
the circuit breaker draft.  Reference?

>
>    A default GRE-in-UDP tunnel can be used to carry IP traffic that is
>    known to be congestion controlled on the Internet. Internet IP
>    traffic is generally assumed to be congestion-controlled. The
>    default usage MUST NOT be used over the general Internet, or over
>    non-cooperating network operators, to carry traffic that is not
>    congestion-controlled.

The above paragraph does not parse well.  The premise seems to undermine
the conclusion.  I know that's not what you intended.

Eliot

---

From: Lucy yong <[email-masked]>
Date: Mon, 9 May 2016 16:56:57 +0000

Hi Eliot,

Thank you for the review. Good comments. Please see inline below.

From: Eliot Lear [mailto:[email-masked]]
Sent: Monday, May 09, 2016 5:53 AM
To: Black, David
Cc: [email-masked]; [email-masked]; tsvwg
Subject: Review of draft-ietf-tsvwg-gre-in-udp-encap

Hi,

This document is generally well written, and almost ready to go.  I have some small suggestions and a three or two below.

In Section 1:

I think what you're getting at here is that GRE is blocked either due to security considerations or because it throws some routers out of the fast path and hence is blocked for performance reasons.  A small discussion of that seems warranted in order to justify the new encapsulation.
[[Lucy]] The main blocker is a middle box. We can make that explicitly.

Also somewhere in the introduction you should probably explain why a non-DTLS version is needed.
[[Lucy]] How about to add this at last in Section 1.   “The document also specifies DTLS version of GRE-in-UDP tunnel that is used where/when security is a concern . “

Section 2.1.1:

[[Lucy]] ack

Reference(s) required.  Specifically, please define for the reader the term "flow entropy". This is linked to [RFC5405bis].  Neither actually define the term.  Moreover, this requirement seems to repeat the requirement in Section 5.1.1 of that document.  Why is that done?
[[Lucy]] Agree. Should add ‘flow entropy’ term definition. Propose, “Flow Entropy: The information to be derived from traffic or applications and to be used by network devices in ECMP process [RFC6438].”

Section 2.1.2:

If I understand your intent correctly, it's probably just better to separate out requirements into three groups:

This "replaces" business makes the document hard to read by adding excessive cross referencing.

[[Lucy]] this is editing preference. We can do two groups and list all requirements for each group; We can do three as you suggested. IMO: two properly make easier for reader.  I am OK with either way and like to hear community preference.

Section 8:

I don't know why IP traffic is considered any safer than other traffic.  IP traffic can be just as unsafe as any other traffic.  Even TCP can misbehave.  I think the question you are aiming for is how do you detect when there is a lack of congestion control?  This sort of aims towards the circuit breaker draft.  Reference?
[[Lucy]] how about:  “ In many cases, a GRE-in-UDP tunnel is used to carry IP traffic. As stated in [RFC5405bis], IP traffic is generally assumed to be congestion controlled. Thus a tunnel carrying general IP traffic generally does not need additional congestion control mechanisms.”

The above paragraph does not parse well.  The premise seems to undermine the conclusion.  I know that's not what you intended.
[[Lucy]] How about: “A default GRE-in-UDP tunnel can be used to carry IP traffic that is known to be congestion controlled on the Internet [RFC5405bis].  The default GRE-in-UDP tunnel MUST NOT be used over the general Internet, or over non-cooperating network operators, to carry traffic that is not congestion-controlled.”
Regards,
Lucy

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 9 May 2016 19:18:34 +0200

Hi Lucy,

Thanks for your prompt response.  Comments inline.

On 5/9/16 6:56 PM, Lucy yong wrote:
> I think what you're getting at here is that GRE is blocked either due
> to security considerations or because it throws some routers out of
> the fast path and hence is blocked for performance reasons.  A small
> */[[Lucy]] The main blocker is a middle box. We can make that
> explicitly./*
>
>

Ok.  I look forward to that text.

> */[[Lucy]] How about to add this at last in Section 1.   “The document
> also specifies DTLS version of GRE-in-UDP tunnel that is used
> where/when security is a concern . “ /*
>

You should also answer why GRE without DTLS is offered.  What I'm
getting at is that unless there's good reason, and presumably there is,
offering an unencrypted option should not be the default.

> */ /*
> */[[Lucy]] ack/*
> */[[Lucy]] Agree. Should add ‘flow entropy’ term definition. Propose,
> “Flow Entropy: The information to be derived from traffic or
> applications and to be used by network devices in ECMP process
> [RFC6438].” /*
>
>

Good.

> */[[Lucy]] this is editing preference. We can do two groups and list
> all requirements for each group; We can do three as you suggested.
> IMO: two properly make easier for reader.  I am OK with either way and
> like to hear community preference./*
>
> *//*//
>
>  
>
> Section 8:
>
>
> I don't know why IP traffic is considered any safer than other
> traffic.  IP traffic can be just as unsafe as any other traffic.  Even
> TCP can misbehave.  I think the question you are aiming for is how do
> you detect when there is a lack of congestion control?  This sort of
> aims towards the circuit breaker draft.  Reference?
>
> */[[Lucy]] how about:  “ In many cases, a GRE-in-UDP tunnel is used to
> carry IP traffic. As stated in [RFC5405bis], IP traffic is generally
> assumed to be congestion controlled. Thus a tunnel carrying general IP
> traffic generally does not need additional congestion control
> mechanisms.”/*
>

I guess I question both that assumption, especially over time, and even
the need for this text.  Let me put this another way: what happens if
you remove that text?  Does the rest of the document hold together? 
Because...
> *//*
> The above paragraph does not parse well.  The premise seems to
> undermine the conclusion.  I know that's not what you intended.
>
> */[[Lucy]] How about: “A default GRE-in-UDP tunnel can be used to
> carry IP traffic that is known to be congestion controlled on the
> Internet [RFC5405bis].  The default GRE-in-UDP tunnel MUST NOT be used
> over the general Internet, or over non-cooperating network operators,
> to carry traffic that is not congestion-controlled.”/*
>

Thanks.  I now understand your point.  I think the main point is not
whether it is IP traffic or whether it goes over the general Internet
but whether ingress traffic is known to be congestion controlled, and so
the first sentence is not germane to your main point (I don't think). 
But this is now stylistic.

Regards,

Eliot

---

From: Lucy yong <[email-masked]>
Date: Mon, 9 May 2016 19:12:36 +0000

Hi Eliot,

Please see inline below.

[snip]

You should also answer why GRE without DTLS is offered.  What I'm getting at is that unless there's good reason, and presumably there is, offering an unencrypted option should not be the default.
[[Lucy]] The draft currently specifies the non-DTLS GRE-in-UDP tunnel as default. DTLS based GRE-in-UDP tunnel is to be supported by configuration. So, question is what should be the default and configured? Like to hear other opinion on this.

Section 8:

I guess I question both that assumption, especially over time, and even the need for this text.  Let me put this another way: what happens if you remove that text?  Does the rest of the document hold together?  Because...
[[Lucy]] The sentence just gives an often use case to show the existing usage that does need congestion control mechanism at the tunnel. IMO:  good to state it out.

Thanks.  I now understand your point.  I think the main point is not whether it is IP traffic or whether it goes over the general Internet but whether ingress traffic is known to be congestion controlled, and so the first sentence is not germane to your main point (I don't think).  But this is now stylistic.
[[Lucy]] See your point. How about: “A default GRE-in-UDP tunnel can be used to carry traffic that is known to be congestion controlled on the Internet [RFC5405bis].  The default GRE-in-UDP tunnel MUST NOT be used over the general Internet, or over non-cooperating network operators, to carry traffic that is not congestion-controlled.”
Regards,
Lucy

Regards,

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 10 May 2016 13:24:39 +0200

Hi Lucy,

On 5/9/16 9:12 PM, Lucy yong wrote:
>
> *Hi Eliot,*
>
> * *
>
> *Please see inline below.*
>
> * *
>
> *[snip]*
>
> getting at is that unless there's good reason, and presumably there
> is, offering an unencrypted option should not be the default.
>
> */[[Lucy]] The draft currently specifies the non-DTLS GRE-in-UDP
> tunnel as default. DTLS based GRE-in-UDP tunnel is to be supported by
> configuration. So, question is what should be the default and
> configured? Like to hear other opinion on this./*
>
>
>

Fair enough but please be aware of RFC-7258.  Though not required, the
easiest way to demonstrate that this WG to have demonstrated that you've
considered pervasive surveillance is to document the logic behind your
choices.
> [...]
> but whether ingress traffic is known to be congestion controlled, and
> so the first sentence is not germane to your main point (I don't
> think).  But this is now stylistic.
>
> */[[Lucy]] See your point. How about: “A default GRE-in-UDP tunnel can
> be used to carry traffic that is known to be congestion controlled on
> the Internet [RFC5405bis].  The default GRE-in-UDP tunnel MUST NOT be
> used over the general Internet, or over non-cooperating network
> operators, to carry traffic that is not congestion-controlled.”/*
>
>
Sure.

Eliot

---

From: "Black, David" <[email-masked]>
Date: Thu, 12 May 2016 20:46:24 +0000

Commenting as draft shepherd (NOT as WG chair) ...

First - many thanks to Eliot for the review.

>>> What I'm getting at is that unless there's good reason, and presumably there is, offering an unencrypted option should not be the default.

>> [[Lucy]] The draft currently specifies the non-DTLS GRE-in-UDP tunnel as default. DTLS based GRE-in-UDP tunnel is to be supported by
>> configuration. So, question is what should be the default and configured? Like to hear other opinion on this.

> Fair enough but please be aware of RFC-7258.  Though not required, the easiest way to demonstrate that this
> WG to have demonstrated that you've considered pervasive surveillance is to document the logic behind your choices.

Fair enough, but please be aware of ;-) ...
... this IESG DISCUSS non-criterion (see: https://www.ietf.org/iesg/statement/discuss-criteria.html#stand-undisc):

> When an extension or minor update is made to an existing protocol that has unaddressed issues, it would not be
> appropriate to hold a DISCUSS on that document demanding that the problem in the base protocol specification
> be addressed; rather, the way to address problems of this sort is to update the base protocol specification.
> For example, a lack of consideration for pervasive monitoring in an existing specification would not justify
> holding a DISCUSS on the extension or minor update.

For the sake of discussion, this GRE/UDP draft could be viewed as a GRE extension.  In that context, a request for a DTLS default feels like an attempt to do something about a pervasive monitoring problem in GRE itself ... which isn’t exactly aligned with that DISCUSS Non-criterion ;-).  That said, an RFC 7258 vs. DISCUSS non-criterion debate here seems pointless, so please send further comments on this process topic to /dev/null :-).

I suggest the following:

- For a general Internet tunnel, DTLS SHOULD be the default.
                + A “MUST” requirement seems inappropriate based on the above DISCUSS non-criterion.
- For a Traffic-Managed Controlled Environment (TMCE) tunnel, no default is specified:
+ In practice, the network operator doing the traffic management can be expected to
also control whether DTLS is used (and I’d state that rationale in the draft).

Thanks, --David

From: Eliot Lear [mailto:[email-masked]]
Sent: Tuesday, May 10, 2016 7:25 AM
To: Lucy yong; Black, David
Cc: [email-masked]; [email-masked]; tsvwg
Subject: Re: Review of draft-ietf-tsvwg-gre-in-udp-encap

Hi Lucy,

Please see inline below.

[snip]

Fair enough but please be aware of RFC-7258.  Though not required, the easiest way to demonstrate that this WG to have demonstrated that you've considered pervasive surveillance is to document the logic behind your choices.

[...]

Sure.

Eliot

---

From: Edward <[email-masked]>
Date: Thu, 12 May 2016 14:51:16 -0700

A MUST here would be pretty inappropriate IMO.

Frankly, I think even an unqualified SHOULD is quite strong, given that
(a) the data may already be encrypted
(b) there is /still/ a high cost associated with encryption (and as such,
there is typically a decision process involved as to whether something
should be encrypted or not.)

I appreciate the aspiration, but anything stronger than a recommendation
for the operator here is unrealistic.

My 2c as both a co-author and an operator.

On Thu, May 12, 2016 at 1:46 PM, Black, David <[email-masked]> wrote:

> >>> What I'm getting at is that unless there's good reason, and
> presumably there is, offering an unencrypted option should not be the
> default.
>
>
>
> >> *[[Lucy]] The draft currently specifies the non-DTLS GRE-in-UDP tunnel
> as default. DTLS based GRE-in-UDP tunnel is to be supported by*
>
> >> *configuration. So, question is what should be the default and
> configured? Like to hear other opinion on this.*
>
>
>
> easiest way to demonstrate that this
>
> > WG to have demonstrated that you've considered pervasive surveillance is
> to document the logic behind your choices.
>
>
>
> ... this IESG DISCUSS non-criterion (see:
> https://www.ietf.org/iesg/statement/discuss-criteria.html#stand-undisc):
>
>
>
> > appropriate to hold a DISCUSS on that document demanding that the
> problem in the base protocol specification
>
> For the sake of discussion, this GRE/UDP draft could be viewed as a GRE
> extension.  In that context, a request for a DTLS default feels like an
> attempt to do something about a pervasive monitoring problem in GRE itself
> ... which isn’t exactly aligned with that DISCUSS Non-criterion ;-).  That
> said, an RFC 7258 vs. DISCUSS non-criterion debate here seems pointless, so
> please send further comments on this process topic to /dev/null :-).
>
>
>
> I suggest the following:
>
>
>
> *From:* Eliot Lear [mailto:[email-masked]]
> *Sent:* Tuesday, May 10, 2016 7:25 AM
> *To:* Lucy yong; Black, David
> *Cc:* [email-masked]; [email-masked];
> tsvwg
> *Subject:* Re: Review of draft-ietf-tsvwg-gre-in-udp-encap
>
>
>
> Hi Lucy,
>
> *[[Lucy]] How about to add this at last in Section 1.   “The document also
> specifies DTLS version of GRE-in-UDP tunnel that is used where/when
> security is a concern . “ *
>
>
> You should also answer why GRE without DTLS is offered.  What I'm getting
> at is that unless there's good reason, and presumably there is, offering an
> unencrypted option should not be the default.
>
> *[[Lucy]] The draft currently specifies the non-DTLS GRE-in-UDP tunnel as
> default. DTLS based GRE-in-UDP tunnel is to be supported by configuration.
> So, question is what should be the default and configured? Like to hear
> other opinion on this.*
>
>
>
>
> *[[Lucy]] How about: “A default GRE-in-UDP tunnel can be used to carry IP
> traffic that is known to be congestion controlled on the Internet
> [RFC5405bis].  The default GRE-in-UDP tunnel MUST NOT be used over the
> general Internet, or over non-cooperating network operators, to carry
> traffic that is not congestion-controlled.”*
>
>
> whether it is IP traffic or whether it goes over the general Internet but
> whether ingress traffic is known to be congestion controlled, and so the
> first sentence is not germane to your main point (I don't think).  But this
> is now stylistic.
>
> *[[Lucy]] See your point. How about: “A default GRE-in-UDP tunnel can be
> used to carry traffic that is known to be congestion controlled on the
> Internet [RFC5405bis].  The default GRE-in-UDP tunnel MUST NOT be used over
> the general Internet, or over non-cooperating network operators, to carry
> traffic that is not congestion-controlled.”*
>
>
>
> Sure.
>
> Eliot
>

---

From: "Black, David" <[email-masked]>
Date: Fri, 13 May 2016 15:41:31 +0000

Ed,

Thanks for the comments - here are some thoughts ... (still as draft shepherd, not WG chair) ...

> (b) there is /still/ a high cost associated with encryption (and as such, there is typically a
> decision process involved as to whether something should be encrypted or not.)

Qualifying the “SHOULD” (for the general Internet case only) to not apply to traffic known to be encrypted makes sense.   Please keep in mind that the concern here is privacy (encryption as a countermeasure to pervasive monitoring), and hence the scope of encryption used to qualify the requirement ought to include the encapsulated headers (inside the GRE header) not just payload data.

The decision process in (b) involves overriding the defaults, but I could see weakening the qualified “SHOULD” to a qualified “ought to” (in the sense of  “do this if you’re not sure”) to better support the idea that there should be a decision process.

> I appreciate the aspiration, but anything stronger than a recommendation for the operator here is unrealistic.

> also control whether DTLS is used (and I’d state that rationale in the draft).

In contrast, there may not be an operator in the general Internet case, so a general recommendation for the operator  in that case won’t fly ;-).

Thoughts?

Thanks, --David

From: Edward [mailto:[email-masked]]
Sent: Thursday, May 12, 2016 5:51 PM
To: Black, David
Cc: Eliot Lear; Lucy yong; [email-masked]; tsvwg
Subject: Re: Review of draft-ietf-tsvwg-gre-in-udp-encap

Frankly, I think even an unqualified SHOULD is quite strong, given that
(a) the data may already be encrypted
(b) there is /still/ a high cost associated with encryption (and as such, there is typically a decision process involved as to whether something should be encrypted or not.)

I appreciate the aspiration, but anything stronger than a recommendation for the operator here is unrealistic.
My 2c as both a co-author and an operator.

On Thu, May 12, 2016 at 1:46 PM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:
Commenting as draft shepherd (NOT as WG chair) ...

I suggest the following:

Thanks, --David

From: Eliot Lear [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, May 10, 2016 7:25 AM
To: Lucy yong; Black, David
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; tsvwg
Subject: Re: Review of draft-ietf-tsvwg-gre-in-udp-encap

Hi Lucy,

Please see inline below.

[snip]

[...]

Sure.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 May 2016 20:34:15 +0200

Hi David,

> also control whether DTLS is used (and I’d state that rationale in the

Yes, but give just a bit of guidance to the operator as to the
selection.  This could be by reference if one can think of the right one.

Eliot