Subject: [Int-area] Spencer Dawkins' No Objection on draft-ietf-intarea-gre-ipv6-11: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 04 Aug 2015 05:57:54 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-intarea-gre-ipv6-11: 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-intarea-gre-ipv6/

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

In this text, in section 2.1,

   However, if the GRE Checksum Present field is set to zero, the GRE
   header is not protected by any checksum.  Furthermore, depending on
   which of the above-mentioned conditions are true, selected portions
   of the GRE payload will not be protected by any checksum.

   Network operators should evaluate risk factors in their networks and
   configure GRE ingress nodes appropriately.
   
We have a conversation about the risk factors pretty much every time we
talk about turning checksums off, and often, we start without a shared
understanding of what can go wrong. I'm wondering if there's a canonical
description of the risks that could be referenced here. I've asked
TSV-DIR if one exists (so, no action for the draft authors, unless you
already have a reference in mind), but in the absence of a reasonable
reference, a forward pointer to section 4.2 might be helpful.

In this text, in section 3.2,

   Before activating a GRE tunnel and periodically thereafter, the GRE
   ingress node MUST execute procedures that verify the tunnel's ability
   to carry a 1280-byte IPv6 payload packet from ingress to egress,
   without fragmenting the payload.  Having executed those procedures,
   the GRE ingress node MUST activate or deactivate the tunnel
   accordingly.
   
I understand "MUST deactivate" (thank you), but wonder if "activate" is a
MUST here.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 5 Aug 2015 16:37:29 -0500

So, I've talked to some folks, and thought for a while ...

> https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-ipv6/

We've gone around the block on checksums a few times in
https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-07#section-5.2,
about when it's safe to use GRE in UDP with UDP checksums turned off, and
I'm thinking that GRE in IPv6 with no IPv6 header checksums would be
similar enough to GRE in UDP with UDP checksums turned off that I should
ask if the authors might have looked at those recommendations, which are
(reproduced here for your convenience):

   When UDP is used over IPv6, the UDP checksum is relied upon to
   protect both the IPv6 and UDP headers from corruption, and so MUST
   used with the following exceptions:

     a. Use of GRE-in-UDP in networks under single administrative
        control (such as within a single operator's network) where it
        is known (perhaps through knowledge of equipment types and
        lower layer checks) that packet corruption is exceptionally
        unlikely and where the operator is willing to take the risk of
        undetected packet corruption.

     b. Use of GRE-in-UDP in networks under single administrative
        control (such as within a single operator's network) where it
        is judged through observational measurements (perhaps of
        historic or current traffic flows that use a non-zero checksum)
        that the level of packet corruption is tolerably low and where
        the operator is willing to take the risk of undetected packet
        corruption.

     c. Use of GRE-in-UDP for traffic delivery for applications that
        are tolerant of mis-delivered or corrupted packets (perhaps
        through higher layer checksum, validation, and retransmission
        or transmission redundancy) where the operator is willing to
        rely on the applications using the tunnel to survive any
        corrupt packets.

   For these exceptions, the UDP zero-checksum mode can be used.

I'll leave this as a comment for now, but I'm looking forward to hearing
back about this ...

Thanks,

Spencer

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 6 Aug 2015 10:02:33 +0000

Spencer,

Thanks for your review and comments! Please see inline.

> On Aug 4, 2015, at 2:57 PM, Spencer Dawkins <[email-masked]> wrote:
> 

Yes, a forward pointer (i.e., “, see Section 4.2”) can help at the end of the sentence.

> I understand "MUST deactivate" (thank you), but wonder if "activate" is a

Are there cases in which it would not want to activate it? That said, I think that a SHOULD activate is effective, and I do not mind using MUST sparingly.

Thanks,

— Carlos.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 6 Aug 2015 07:39:45 -0500

Hi, Carlos,

On Thu, Aug 6, 2015 at 5:02 AM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> Are there cases in which it would not want to activate it? That said, I
> think that a SHOULD activate is effective, and I do not mind using MUST
> sparingly.

If I'm understanding correctly, the point isn't whether you MUST or SHOULD
activate the tunnel if the verification passes, but that you MUST
deactivate the tunnel if verification fails, and leave it deactivated for
as long as verification fails.

Is this accurate?

"Having executed those procedures, the GRE ingress node MUST deactivate any
tunnel that fails this verification, and MUST NOT activate any tunnel that
does not pass verification."

Thanks,

Spencer

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 7 Aug 2015 15:52:28 +0000

Hi Spencer,

Thanks for updating your ballot, I see that only the GRE checksum issue remains in the DISCUSS. In this context, please see inline.

> On Aug 5, 2015, at 5:37 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> On Tue, Aug 4, 2015 at 7:57 AM, Spencer Dawkins <[email-masked] <mailto:[email-masked]>> wrote:
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-ipv6/ <https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-ipv6/>
> 
> 
> 
> We've gone around the block on checksums a few times in https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-07#section-5.2 <https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-07#section-5.2>, about when it's safe to use GRE in UDP with UDP checksums turned off, and I'm thinking that GRE in IPv6 with no IPv6 header checksums would be similar enough to GRE in UDP with UDP checksums turned off that I should ask if the authors might have looked at those recommendations, which are (reproduced here for your convenience):
> 

The situation with GRE over IPv6 is different, because of two principal reasons:
1. The GRE checksum does not include the network pseudo header.
2. GRE is not an application transport but a tunneling protocol.

What we could do is point to Section 2.3 (or Sections 2.3 and 2.4) of RFC 6936 https://tools.ietf.org/html/rfc6936#section-2.3 <https://tools.ietf.org/html/rfc6936#section-2.3>, as they already discuss these reasons.

Would that work?

Thanks,

— Carlos.

> I'll leave this as a comment for now, but I'm looking forward to hearing back about this ...
> 
> Thanks,
> 
> Spencer
>