Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Apr 2015 09:14:48 +0100

Because the IPv6 delivery header does not include a checksum of its
own, it is subject to corruption.

SB> It is subject to corruption whether or not it has a checksum.
SB> The point is that there may be undetected corruption. However
SB> detection in only probabilistic even with a checksum. So
SB> I think that that this text should be:

Because the IPv6 delivery header does not include a checksum of its
own, it is subject to higher probability of undetected corruption.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Apr 2015 09:24:17 +0100

On 30/03/2015 22:49, Ronald Bonica wrote:
>
> Lucy,
>
> Would the following text work?
>
> OLD>
>
>    own, it is subject to corruption.  However, even if the delivery
>
>    header is corrupted, to likelihood of that corruption resulting in
>
>    misdelivery of the payload is extremely low.
>
> <OLD
>
> NEW>
>
>    own,  the destination address in the delivery header is subject to
>
>    corruption. If the destination address in the deliver header is 
> corrupted,
>
>    the following outcomes are possible:
>
> 1)The delivery packet is dropped because the new destination address 
> is unreachable
>
> 2)The delivery packet is dropped because the new destination address 
> is reachable, but that node is not configured to process GRE delivery 
> packets from the ingress
>
> 3)The delivery packet is processed by a GRE egress other than that 
> which was originally specified by the GRE ingress. Processing options are:
>
> a.The payload packet is dropped because the payload destination is 
> unreachable from the node that processed the delivery packet
>
> b.The payload packet is delivered to its intended destination because 
> the payload destination is reachable from the node that processed the 
> delivery packet
>
> All of these outcomes are acceptable.
>
> <NEW
>
> Ron
>
Ron, maybe I am missing a caveat, but suppose the payload is a packet 
with a non-globally unique address space (for example 10.x.x.x, but not 
limited to IP) then there is a case 3 c which is that the packet was 
delivered to a node that it was not the intended ultimate destination 
and one has to hope that there is sufficient resilency in the system 
receiving the packet that this is of no consequence.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Apr 2015 09:30:47 +0100

Isn't systematic rather than random corruption more likely?

Stewart

On 31/03/2015 23:04, Ronald Bonica wrote:
>
> Lucy, David,
>
> The proposed text says that outcome 3c) is unacceptable but highly 
> unlikely. For example, assume the following:
>
> -That an IPv6 address is assigned to every milligram of matter on 
> earth, including every drop of water. (2**95 IPv6 addresses are assigned)
>
> -That every minute, the destination address on a delivery packet is 
> corrupted
>
> -The pattern of corruption is random
>
> Every time a destination address is corrupted, the odds are 1 / 
> 8,589,934,592 that the result will be an assigned address. This should 
> happen one ever 16, 331 years.
>
> Now, assume that only 1% of those of those 2**95 IPv6 addresses are 
> configured on devices that de-encapsulate GRE. In this case, outcomes 
> 3a), 3b) and 3c) will occur only once every 1,633,100 years!
>
> So, practically speaking, we don’t have much to worry about. But for 
> the purposes of the pedantry, we may need to say that GRE over IPv6 is 
> only practical when operators can deal with that risk.
>
> David, what is the minimum text that we can import to satisfy the 
> requirement.
>
> Ron
>
> *From:* Lucy yong [mailto:[email-masked]]
> *Sent:* Tuesday, March 31, 2015 3:21 PM
> *To:* Ronald Bonica; Black, David; [email-masked]; [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* RE: Start of WGLC for draft-ietf-intarea-gre-ipv6
>
> Hi Ron,
>
> 3c) may happen for a VPN or non-VPN case. The payload can be in 
> non-IPv6 space.  Is “Outcome 3c) is not acceptable, but it extremely 
> unlikely.” for particular network/usage in your mind?
>
> Is the goal here to prove such corruption is acceptable or extreme 
> unlikely?
>
> Regards,
>
> Lucy
>
> *From:*Int-area [mailto:[email-masked]] *On Behalf Of 
> *Ronald Bonica
> *Sent:* Tuesday, March 31, 2015 1:43 PM
> *To:* Black, David; [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] 
> <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6
>
> Resend…
>
> *From:* Ronald Bonica
> *Sent:* Tuesday, March 31, 2015 2:23 PM
> *To:* 'Black, David'; [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] 
> <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
> *Subject:* RE: Start of WGLC for draft-ietf-intarea-gre-ipv6
>
> David, Lucy,
>
> You are correct.  Maybe the following text will address the issue:
>
> OLD>
>
> b.The payload packet is delivered to its intended destination
>
> c.The payload packet is erroneously delivered to a node other than its 
> intended destination. The intended destination and the node to which 
> the payload is actually delivered are numbered identically, but reside 
> in different VPNs.
>
> Outcomes 1), 2), 3a) and 3b) are acceptable. Outcome 3c) is not 
> acceptable, but it extremely unlikely. Because IPv6 address space is 
> so large and so sparsely populated, outcome 1) is by far the most 
> probable. Therefore, the combined likelihood of all acceptable 
> outcomes by far exceeds the likelihood of the one unacceptable outcome.
>
> Furthermore, even if the payload is erroneously delivered to a node 
> other than its intended destination, that node will discard the packet 
> if the payload is also corrupted or if there are no applications 
> waiting to consume the packet.
>
> <NEW
>
> Ron
>
> *From:* Black, David [mailto:[email-masked]]
> *Sent:* Monday, March 30, 2015 7:48 PM
> *To:* Ronald Bonica; [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] 
> <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; Black, David
> *Subject:* RE: Start of WGLC for draft-ietf-intarea-gre-ipv6
>
> > Also, why would you object to 3b? The packet ends up at the right 
> node, just via an unexpected route.
>
> That assertion is based on the assumption that the payload destination 
> address is worldwide unique.
>
> There are lots of counterexamples that void the assumption, e.g., 
> 10.0.0.0/8.
>
> Thanks,
> --David
>
>
>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Apr 2015 10:38:22 -0700

> own, it is subject to higher probability of undetected corruption. 

The probability of undetected corruption is 100%. And a checksum isn't
the only way to detect errors.

IMO:

Because the IPv6 delivery header does not include error detection, it is
subject to undetected corruption.

Joe

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Apr 2015 19:05:00 +0100

On 01/04/2015 18:38, Joe Touch wrote:
> .
I accept that there are other possible error checking technique, but
the original text is talking about checksum. However no check is
perfect so I still think it needs to be:

Because the IPv6 delivery header does not include error detection,
it is subject to a higher probability of undetected corruption.

- Stewart

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Apr 2015 11:28:18 -0700

> it is subject to a higher probability of undetected corruption.

Point taken. Better.

Joe

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 31 Mar 2015 19:01:13 +0000

Hi, Lucy,

One approach is to add a 3.c) to the list that Ron shared. I think there is another potential approach to your initial comment: we could note that for a tunneling protocol (GRE), this is equivalent to the relaxation of the UDP checksum in RFC 6935, and keep the existing text.

Fred, RFC 2473 does not mention checksums.

Thanks,

Carlos.

> On Mar 30, 2015, at 7:47 PM, Black, David <[email-masked]> wrote:
> 
> > Also, why would you object to 3b? The packet ends up at the right node, just via an unexpected route.
> 
> That assertion is based on the assumption that the payload destination address is worldwide unique.
> 
> There are lots of counterexamples that void the assumption, e.g., 10.0.0.0/8.
> 
> Thanks,
> --David
> 
> From: Lucy yong [mailto:[email-masked] <mailto:[email-masked]>]
> Sent: Monday, March 30, 2015 6:31 PM
> To: Ronald Bonica; Zuniga, Juan Carlos; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Black, David
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6
> 
> Hi Ron,
> 
> 3b) is the concern. GRE payload may be non-IP type. If a gre-in-ipv6 tunnel is used for mux of different payload types, the outcome may be unknown and can be unacceptable upon IP address and/or GRE header are corrupted.
> 
> Lucy
> 
> 
> 
> From: Ronald Bonica [mailto:[email-masked] <mailto:[email-masked]>]
> Sent: Monday, March 30, 2015 5:14 PM
> To: Lucy yong; Zuniga, Juan Carlos; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Black, David
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6
> 
> Lucy,
> 
> Why would you object to 3a? Dropping the packet is the preferred behavior?
> 
> Also, why would you object to 3b? The packet ends up at the right node, just via an unexpected route. Recall that the destination address in the payload header is protected by the UDP/TCP checksum.
> 
> Are you thinking that there might be a 3c)?
> 
>                       Ron
> 
> 
> From: Lucy yong [mailto:[email-masked] <mailto:[email-masked]>]
> Sent: Monday, March 30, 2015 6:05 PM
> To: Ronald Bonica; Zuniga, Juan Carlos; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Black, David
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6
> 
> Hi Ron,
> 
> 1)      and 2 ) are fine. IMO: 3) works under certain conditions but not all.
> 
> I add David Black (TSVWG chair) to the thread. He can provide the thorough check.
> 
> Regards,
> Lucy
> 
> From: Ronald Bonica [mailto:[email-masked] <mailto:[email-masked]>]
> Sent: Monday, March 30, 2015 4:49 PM
> To: Lucy yong; Zuniga, Juan Carlos; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6
> 
> Lucy,
> 
>    corruption. If the destination address in the deliver header is corrupted,
> 1)      The delivery packet is dropped because the new destination address is unreachable
> 2)      The delivery packet is dropped because the new destination address is reachable, but that node is not configured to process GRE delivery packets from the ingress
> 3)      The delivery packet is processed by a GRE egress other than that which was originally specified by the GRE ingress. Processing options are:
> a.       The payload packet is dropped because the payload destination is unreachable from the node that processed the delivery packet
> b.      The payload packet is delivered to its intended destination because the payload destination is reachable from the node that processed the delivery packet
> 
> From: Lucy yong [mailto:[email-masked] <mailto:[email-masked]>]
> Sent: Monday, March 30, 2015 4:50 PM
> To: Zuniga, Juan Carlos; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6
> 
> Thanks authors to add section 4.1.
> 
> I am not sure if the statement of “However, even if the delivery header is corrupted, to likelihood of that corruption resulting in misdelivery of the payload is extremely low.” is proper. IPv6 requires the end point/upper layer to deal with the header corruption. Could we state that this is the difference from gre-in-ipv4 instead?
> 
> Lucy
> 
> 
> From: Int-area [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Zuniga, Juan Carlos
> Sent: Monday, March 30, 2015 3:27 PM
> To: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Subject: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6
> 
> Dear Int-Area and 6man WGs,
> 
> At the Int-Area WG meeting in Dallas there were some comments on draft-ietf-intarea-gre-ipv6. It was decided to submit the document for WG Last Call to the Int-Area & 6man WGs as soon as the agreed changes were made.
> 
> The document has now been updated accordingly, so this email starts an Int-Area/6man WGs Last Call on:
> 
> http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-04 <http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-04>
> 
> Please respond to this email to support the document and/or send comments by 2015-04-06.
> 
> In addition, to satisfy RFC 6702 "Promoting Compliance with Intellectual Property Rights (IPR)":
> Are you personally aware of any IPR that applies to draft-ietf-intarea-gre-ipv6?
> If so, has this IPR been disclosed in compliance with IETF IPR rules?
> (See RFCs 3979, 4879, 3669, and 5378 for more details.)
> 
> Best,
> 
> Juan Carlos Zuniga
> (as Int-Area WG co-chair)
>

---

From: Lucy yong <[email-masked]>
Date: Tue, 31 Mar 2015 19:07:18 +0000

Hi Carlos,

I am not clear what you propose. UDP checksum includes IP header. GRE does not.

Lucy

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, March 31, 2015 2:01 PM
To: Black, David; Lucy yong
Cc: Ronald P. Bonica; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6

Hi, Lucy,

Thanks,

Carlos.

Thanks,
--David

From: Lucy yong [mailto:[email-masked]]
Sent: Monday, March 30, 2015 6:31 PM
To: Ronald Bonica; Zuniga, Juan Carlos; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Black, David
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Hi Ron,

Lucy

From: Ronald Bonica [mailto:[email-masked]]
Sent: Monday, March 30, 2015 5:14 PM
To: Lucy yong; Zuniga, Juan Carlos; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Black, David
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Lucy,

                      Ron

From: Lucy yong [mailto:[email-masked]]
Sent: Monday, March 30, 2015 6:05 PM
To: Ronald Bonica; Zuniga, Juan Carlos; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Black, David
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Hi Ron,

Regards,
Lucy

From: Ronald Bonica [mailto:[email-masked]]
Sent: Monday, March 30, 2015 4:49 PM
To: Lucy yong; Zuniga, Juan Carlos; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Lucy,

OLD>

NEW>

<NEW

                          Ron

From: Lucy yong [mailto:[email-masked]]
Sent: Monday, March 30, 2015 4:50 PM
To: Zuniga, Juan Carlos; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Lucy

From: Int-area [mailto:[email-masked]] On Behalf Of Zuniga, Juan Carlos
Sent: Monday, March 30, 2015 3:27 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6

http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-04

Best,

Juan Carlos Zuniga

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area

---

From: David Farmer <[email-masked]>
Date: Tue, 31 Mar 2015 18:49:56 -0500

The Security Considerations for this Draft are not sufficient by today's 
standards in my opinion.  The Security Considerations of RFC2784 does 
not even discuss data protection (encryption) or tunnel end point 
authentication issues, and this draft basically just references RFC2784. 
  Any proper discussion of Security Considerations for this topic should 
at least include references on these issues.  I point you to RFC4023 
section 8, for an much more in depth handling of Security Considerations 
of similar issues.

I'm not sure its necessary to go to that depth, but some pointers to 
IPSec and/or SSL would seem a minimum, especially since IPSec was 
suppose to be a key feature for IPv6. Also, RFC6196 has a good 
discussion of security issues with tunnels in general.

Thanks

On 3/30/15 15:27 , Zuniga, Juan Carlos wrote:
> At the Int-Area WG meeting in Dallas there were some comments on
> draft-ietf-intarea-gre-ipv6. It was decided to submit the document for
> WG Last Call to the Int-Area & 6man WGs as soon as the agreed changes
> were made.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 2 Apr 2015 19:38:52 +0000

Lucy, Tom, Steward,

I agree with what you are saying and have tried to craft some text that addresses all of your comments. Please tell me if the following text does the trick.

                                                                                                                                                        Ron

OLD>
   As stated in [RFC2784], the Checksum field contains the IP (one's
   complement) checksum sum of the all the 16 bit words in the GRE
   header and the payload packet.  Therefore, the checksum does not
   ensure the integrity of the IPv6 delivery header.

NEW>
   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 or its own. Therefore, no 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.

Before deploying GRE over IPv6, network operators should consider the
likelihood of behavior c) in their network. Network operators should deploy
GRE over IPv6 if they can tolerate the risk associated with behavior c).

<NEW

                                         Ron

---

From: Lucy yong <[email-masked]>
Date: Thu, 2 Apr 2015 19:58:06 +0000

Hi Ron,

Good Try. See inline below.

From: Ronald Bonica [mailto:[email-masked]]
Sent: Thursday, April 02, 2015 2:39 PM
To: Lucy yong; Black, David; [email-masked]; [email-masked]; Stewart Bryant (stbryant)
Cc: [email-masked]; [email-masked]
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Lucy, Tom, Steward,

                                                                                                                                                        Ron

OLD>

NEW>

[Lucy] nit: “on its own”

a)      Drop the packet

Before deploying GRE over IPv6, network operators should consider the
likelihood of behavior c) in their network. Network operators should deploy
GRE over IPv6 if they can tolerate the risk associated with behavior c).
[Lucy] “can deploy” is better than “should deploy”

I am fine with the text for the corruption case. Do we need to address misdelivery as well.

Thanks,
Lucy

<NEW

                                         Ron

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 2 Apr 2015 22:01:01 +0000

Lucy,

Both good catches. Stand by for text on misdelivery.

                                            Ron

From: Lucy yong [mailto:[email-masked]]
Sent: Thursday, April 02, 2015 3:58 PM
To: Ronald Bonica; Black, David; [email-masked]; [email-masked]; Stewart Bryant (stbryant)
Cc: [email-masked]; [email-masked]
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Hi Ron,

To: Lucy yong; Black, David; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Stewart Bryant (stbryant)

Lucy, Tom, Steward,

                                                                                                                                                        Ron

OLD>

NEW>

a)      Drop the packet

Thanks,
Lucy

<NEW

                                         Ron