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

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 20 Aug 2015 14:33:45 -0700

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

Thank you for working with me on this Discuss, and addressing my
Comments. I've revised this Discuss based on conversations with Ron (and
we're converging).

I have three questions, but I'm ready to clear.

For reference, the Checksum text in -13 now looks like this:

4.2.  Checksum Considerations

   As stated in [RFC2784], the GRE header can contain a checksum.  If
   present, the GRE header checksum can be used to detect corruption of
   the GRE header and GRE payload.

   The GRE header checksum cannot be used to detect corruption of the
   IPv6 delivery header.  Furthermore, the IPv6 delivery header does not
   contain a checksum of its own.  Therefore, no available checksum can
   be used to detect corruption of the IPv6 delivery header.

   In one failure scenario, the destination address in the IPv6 delivery
   header is corrupted.  As a result, the IPv6 delivery packet is
   delivered to a node other than the intended GRE egress node.
   Depending upon the state and configuration of that node, it will
   either:

   a.  Drop the packet

   b.  De-encapsulate the payload and forward it to its intended
       destination

   c.  De-encapsulate the payload and forward it to a node other than
       its intended destination.  For example, the payload might be
       intended for a node on one VPN, but delivered to an identically
       numbered node in another VPN.

   Behaviors a) and b) are acceptable.  Behavior c) is not acceptable.
   However, behavior c) is possible only when the payload destination
   address is not globally unique and the GRE egress node provides
   disambiguating context to that address.

   Before deploying GRE over IPv6, network operators should consider the
   likelihood of behavior c) in their network.  GRE over IPv6 MUST NOT
   be deployed other than where the network operator deems the risk
   associated with behavior c) to be acceptable.

   The risk associated with behavior c) could be mitigated with end-to-
   end authentication of the payload.
   
So, my questions are:

(1) how likely is it that endpoints in different VPNs would have
overlapping address ranges?

(2) is it correct that if endpoint A gets traffic that was intended for
an identically addressed endpoint B in another VPN using an overlapping
address range, and that traffic is authenticated, endpoint A can say
"this isn't for me", but if that traffic is not encrypted, is traffic
intended for endpoint B leaking to endpoint A?

(3) if I'm not completely in the weeds so far, is "end-to-end
authentication" something an operator can do? If the answer to (2) is
"yes", is "end-to-end encryption" something an operator can do?

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

This was the previous version of my Discuss - I'm moving it to the
Comments section. Thanks for helping me better understand the situation.

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.

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: "Black, David" <[email-masked]>
Date: Fri, 21 Aug 2015 16:19:38 +0000

Hi Spencer,

My 0.02 ...

> overlapping address ranges?

IMHO, this is likely enough to be unsafe to ignore.  IPv4 private address
space (e.g., 10.0.0.0/8) in the inner header is an "obvious suspect" here.

> intended for endpoint B leaking to endpoint A?

Yes - in this case endpoint B is relying on endpoint A to drop the cleartext
intended for endpoint B.  Also note that this is a case in which encryption
SHOULD NOT be used by itself w/o authentication (e.g., keyed cryptographic
message integrity check or authentication code).

> "yes", is "end-to-end encryption" something an operator can do?

IMHO, not end-to-end for the encapsulated traffic in both cases, as the
GRE tunnel is generally not end-to-end.  However an IPsec (or other) VPN
could be used (e.g., IPsec applied before GRE encap, removed afterwards),
although that may entail deployment of additional equipment.

Thanks,
--David

> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of Spencer Dawkins
> Sent: Thursday, August 20, 2015 5:34 PM
> To: The IESG
> Cc: [email-masked]; [email-masked]; draft-ietf-
> [email-masked]; [email-masked];
> [email-masked]
> Subject: [Int-area] Spencer Dawkins' Discuss on draft-ietf-intarea-gre-ipv6-
> 13: (with DISCUSS and COMMENT)
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 24 Aug 2015 18:15:55 -0500

Thanks, David,

Ron, let's see if we can tie this up and approve it.

Here's my understanding. I'm happy to listen to reason, of course.

Inline.

Spencer

> space (e.g., 10.0.0.0/8) in the inner header is an "obvious suspect" here.

It would be great to point the likelihood of collision out.

> intended for endpoint B.

OK.

> Also note that this is a case in which encryption

That's a good point that I hadn't thought through.

> although that may entail deployment of additional equipment.

So, there's a possibility that A gets traffic that's intended for B, in
another VPN, that's potentially unencrypted.

Theoretically, if B cares very much about that, B is running encryption on
the traffic inside the tunnel.

Is that where we are?

If so, can this be described in a couple of sentences?

Thanks,

Spencer

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 25 Aug 2015 08:59:04 -0500

On Mon, Aug 24, 2015 at 6:26 PM, Black, David <[email-masked]> wrote:

> > Theoretically, if B cares very much about that, B is running encryption
> on the traffic inside the tunnel.
>
>
>
> +1 - recommending use of an encrypted and authenticated VPN when this
> leakage
>
> is a concern seems like a fine thing to say, and moreover should be
> operator-
>
> deployable in general.
>

This is working for me. Is it working for the shepherd/authors/working
group?

Thanks,

Spencer

> FWIW, about half of the probabilities listed in Ron’s earlier reply to me
> don’t
>
> apply when this cross-VPN leakage is a concern, as arrival of VPN B
> cleartext
>
> at a network node that is not participating in VPN B is a concern even if
> that
>
> node promptly drops that cleartext.
>
>
>
> Thanks,
> --David
>
>
>
> *From:* Spencer Dawkins at IETF [mailto:[email-masked]]
> *Sent:* Monday, August 24, 2015 7:16 PM
> *To:* Black, David
> *Cc:* The IESG; [email-masked]; [email-masked];
> [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [Int-area] Spencer Dawkins' Discuss on
> draft-ietf-intarea-gre-ipv6-13: (with DISCUSS and COMMENT)
>
>
>
> Thanks, David,
>
>
>

---

From: "Black, David" <[email-masked]>
Date: Mon, 24 Aug 2015 23:26:29 +0000

> So, there's a possibility that A gets traffic that's intended for B, in another VPN, that's potentially unencrypted.
>
> Theoretically, if B cares very much about that, B is running encryption on the traffic inside the tunnel.

+1 - recommending use of an encrypted and authenticated VPN when this leakage
is a concern seems like a fine thing to say, and moreover should be operator-
deployable in general.

FWIW, about half of the probabilities listed in Ron’s earlier reply to me don’t
apply when this cross-VPN leakage is a concern, as arrival of VPN B cleartext
at a network node that is not participating in VPN B is a concern even if that
node promptly drops that cleartext.

Thanks,
--David

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Monday, August 24, 2015 7:16 PM
To: Black, David
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Int-area] Spencer Dawkins' Discuss on draft-ietf-intarea-gre-ipv6-13: (with DISCUSS and COMMENT)

Thanks, David,

Inline.

Spencer

On Fri, Aug 21, 2015 at 11:19 AM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:
Hi Spencer,

My 0.02 ...

IMHO, this is likely enough to be unsafe to ignore.  IPv4 private address
space (e.g., 10.0.0.0/8<http://10.0.0.0/8>) in the inner header is an "obvious suspect" here.

OK.

So, there's a possibility that A gets traffic that's intended for B, in another VPN, that's potentially unencrypted.

Theoretically, if B cares very much about that, B is running encryption on the traffic inside the tunnel.

Is that where we are?

Thanks,

Spencer

Thanks,
--David

> From: Int-area [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Spencer Dawkins
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; draft-ietf-
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>