Skip to main content

GRE-in-UDP Encapsulation
RFC 8086

Yes

(Mirja Kühlewind)
(Spencer Dawkins)

No Objection

Alvaro Retana
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 18 and is now closed.

Alvaro Retana No Objection

(Mirja Kühlewind; former steering group member) Yes

Yes (for -18)

                            

(Spencer Dawkins; former steering group member) Yes

Yes (for -18)

                            

(Alia Atlas; former steering group member) No Objection

No Objection (2016-09-26 for -18)
Thanks for the well-written document.

(Alissa Cooper; former steering group member) No Objection

No Objection (2016-09-27 for -18)
I agree with Ben's comments about Section 1.

(Ben Campbell; former steering group member) No Objection

No Objection (2016-09-26 for -18)
I'm balloting no objection, but I have a few comments that may be worth considering:

- general: The draft has a structure where you mention requirements in one section, then go into more detail in later sections. While this is a perfectly reasonable structure, it has resulted in a fair bit of redundant 2119 language. In general it's better to avoid that because it can make future updates more error prone. In this case, most of the language is consistent, so it's probably not worth changing. But there are a few cases where the language appears inconsistent, or is restated in sufficiently different ways to be potentially confusing. I've tried to call out specifics, but may have missed some.

-1, paragraph 5, first sentence: I found the sentence structure confusing. I think you mean to say that GRE-in-UDP tunnels are not safe to carry arbitrary traffic over the Internet, but it can be read to mean to say that since the internet is an arbitrary traffic environment, it's not safe to use GRE-in-UDP on it.

-1, paragraph 6: When might security not be a concern? Would it make sense to start with an assumption that security _is_ a concern, then consider situations for which it might not be?

- 6.1, paragraph 1: Previous sections said UDP checksums SHOULD be used for IPv4. Should this section be interpreted to mean that _if_ the checksum is used, it MUST be processes this way? If so, that could use clarification.

-6.2, paragraph 2: Does the allowance to use the zero-checksum in some cases violate the MUST for UDP checksums over IPv6?

-8, third paragraph:
Isn’t this just a restatement of the previous requirement that all traffic carried over default gre-in-udp tunnels must be congestion controlled?

-8, paragraph 5:
This also seems a restatement of the requirement that traffic on generic tunnels MUST be congestion controlled. Given that you probably don’t select your network path based on the nature of the data, I think it’s better stated in the original terms.

-8, last paragraph:
Do circuit-breakers really keep non congestion-controlled traffic from “escaping”, or does it mitigate the damage if it does escape?

-11, 2nd paragraph: Previous sections just said DTLS can be used if there are security concerns. This is not consistent with that. (I prefer the SHOULD to a "can")

-11, last paragraph: Is SHOULD sufficient for this case?

(Benoît Claise; former steering group member) No Objection

No Objection (for -18)

                            

(Deborah Brungard; former steering group member) No Objection

No Objection (for -18)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -18)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (2016-09-28 for -18)
Rick Casarez <rick.casarez@gmail.com> performed the opsdir review

(Kathleen Moriarty; former steering group member) (was Discuss) No Objection

No Objection (2016-09-27 for -18)
Thank you, Lucy for the proposed text on using encryption and DTLS.

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2016-09-27 for -18)
- 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.

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -18)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -18)