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

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 06 Aug 2015 06:40:25 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-intarea-gre-ipv6-11: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm balloting this question as Discuss because we haven't had a chance to
close on it in e-mail yet. To be clear, I'm sure we'll be able to do that
fairly quickly.

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.
   
What I'm trying to understand ("Discuss"), is what the risk factors
actually look like for GRE over IPv6 in this draft.

The working assumption is that packets with corrupted addresses can be
mis-delivered anywhere, and when you don't have a checksum that allows
you to figure out that the packet has been corrupted, the accidental
endpoint is going to try to deliver it to some unsuspecting application.

In GRE over UDP, we ended up with some conservative recommendations,
because a corrupted UDP packet with no checksum could be misdelivered
anywhere on the Internet.

I suspect that's also true for GRE directly over IPv6, but want to
understand better before the document is approved.

The recommendations in
https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-07#section-5.2
are (provided 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.
   
A similar set of recommendations are included in
https://tools.ietf.org/html/rfc7510#section-3.2, for MPLS over UDP.

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

My previous comments (reproduced below) have already been addressed.
Thank you!
   
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: Ronald Bonica <[email-masked]>
Date: Thu, 6 Aug 2015 21:55:15 +0000

Hi Spencer,

Good point. I am about to post a new version of the draft that addresses this issue, as we discussed earlier today.

                                                                            Ron

> -----Original Message-----
> From: Spencer Dawkins [mailto:[email-masked]]
> Sent: Thursday, August 06, 2015 9:40 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; draft-ietf-intarea-gre-
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Spencer Dawkins' Discuss on draft-ietf-intarea-gre-ipv6-11: (with
> DISCUSS and 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.)
> 
> 
> close on it in e-mail yet. To be clear, I'm sure we'll be able to do that fairly
> quickly.
> 
> What I'm trying to understand ("Discuss"), is what the risk factors actually
> look like for GRE over IPv6 in this draft.
> 
> The working assumption is that packets with corrupted addresses can be mis-
> delivered anywhere, and when you don't have a checksum that allows you to
> figure out that the packet has been corrupted, the accidental endpoint is
> going to try to deliver it to some unsuspecting application.
> 
> I suspect that's also true for GRE directly over IPv6, but want to understand
> better before the document is approved.
> 
> The recommendations in
> 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.
>