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

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 02 Sep 2015 11:42:35 -0700

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

Thanks for working through my Discuss about checksums and VPNs.

The version of the Discuss I cleared said this:

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?