Subject: Re: [Int-area] comment on draft-ietf-intarea-gre-ipv6

From: Ronald Bonica <[email-masked]>
Date: Thu, 5 Mar 2015 17:57:29 +0000

Hi Lucy,

The goal of this draft is *not* to prove the GRE behaves identically with IPv6 as it does with IPv4. In fact, its goal is to point out the differences.

Can you think of any differences between the two GRE environments that we have failed to point out?

                                                                                                       Ron

> 
> Message: 1
> Date: Wed, 4 Mar 2015 15:25:54 +0000
> From: Lucy yong <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: [Int-area] comment on draft-ietf-intarea-gre-ipv6
> Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4545BB21@dfweml701-
> chm>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi,
> 
> If this draft is to document the protocol of gre in IPv6 exact same as of gre in
> IPv4 and update rfc2784, IMHO, it should point out the gre application
> behavior differences in IPv4 network and IPv6 network. The exact same
> protocol does not mean the same behavior for an application since IPv4 and
> IPv6 networks have different behaviors such as header checksum.
> 
> Thanks,
> Lucy
> 
> 
> 
>

---

From: Lucy yong <[email-masked]>
Date: Thu, 5 Mar 2015 20:08:33 +0000

Hi Ron,

RFC2784 has this statement: See [RFC1122] for requirements relating to the
   delivery of packets over IPv4 networks.
Does this apply to over IPv6 networks?

Since IPv6 header does not have checksum, if a packet is mis-delivered to GRE decapsulator, will that cause a concern? This is not a concern when IPv4 network is the delivery network. 

Thanks,
Lucy

-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]] 
Sent: Thursday, March 05, 2015 11:57 AM
To: [email-masked]; Lucy yong
Subject: RE: [Int-area] comment on draft-ietf-intarea-gre-ipv6

Hi Lucy,

                                                                                                       Ron

---

From: "Templin, Fred L" <[email-masked]>
Date: Sat, 7 Mar 2015 02:09:30 +0000

Hi Lucy,

> From: Int-area [mailto:[email-masked]] On Behalf Of Lucy yong
> Sent: Thursday, March 05, 2015 12:09 PM
> To: Ronald Bonica; [email-masked]
> Subject: Re: [Int-area] comment on draft-ietf-intarea-gre-ipv6
> 
> Hi Ron,
> 
> Since IPv6 header does not have checksum, if a packet is mis-delivered to GRE decapsulator, will that cause a concern? This is not a
> concern when IPv4 network is the delivery network.

In terms of header integrity checks, they are very much in the same boat as RFC2473.
But, somehow that got standardized.

Thanks - Fred
[email-masked]

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

---

From: Lucy yong <[email-masked]>
Date: Sun, 8 Mar 2015 17:04:59 +0000

Hi Templin,

> Since IPv6 header does not have checksum, if a packet is mis-delivered 
> to GRE decapsulator, will that cause a concern? This is not a concern when IPv4 network is the delivery network.

In terms of header integrity checks, they are very much in the same boat as RFC2473.
But, somehow that got standardized.
[Lucy] RFC2473 is about IPv6 in IPv6, i.e., IPv6 as a delivery network for IPv6 traffic. Since IPv6 packets and upper layer applications have to follow RFC2460, i.e., protect the misdelivery and corruption, so that is OK if there is only such kind of tunnel in IPv6. GRE-in-IPv6 is deferent. They can't be in the same boat. If there are various network protocols that are tunneled over a same IPv6 network, it will have a problem due to packet misdelivery and corruption. IMO: the draft needs to document these.

Thanks,
Lucy 

Thanks - Fred

> The goal of this draft is *not* to prove the GRE behaves identically 
> with IPv6 as it does with IPv4. In fact, its goal is to point out the differences.
> 
> > IPv4 and update rfc2784, IMHO, it should point out the gre 
> > application behavior differences in IPv4 network and IPv6 network. 
> > The exact same protocol does not mean the same behavior for an 
> > application since IPv4 and

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Mar 2015 14:51:45 +0000

> From: Lucy yong [mailto:[email-masked]]
> Sent: Sunday, March 08, 2015 10:05 AM
> To: Templin, Fred L; Ronald Bonica; [email-masked]
> [Lucy] RFC2473 is about IPv6 in IPv6, i.e., IPv6 as a delivery network for IPv6 traffic. Since IPv6 packets and upper layer applications
> have to follow RFC2460, i.e., protect the misdelivery and corruption, so that is OK if there is only such kind of tunnel in IPv6. GRE-in-
> IPv6 is deferent. They can't be in the same boat. If there are various network protocols that are tunneled over a same IPv6 network, it
> will have a problem due to packet misdelivery and corruption. IMO: the draft needs to document these.

Oh, I thought you were concerned about lack of an integrity check for the encapsulating
IPv6 header. Are you saying that (in the RFC2473 case at least) it is OK to omit an integrity
check for the encapsulating IPv6 header as long as there is an integrity check for the
encapsulated IP header? But, somehow that is not OK for draft-ietf-intarea-gre-ipv6?

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Mar 2015 17:15:10 +0000

Hi Lucy,

Also, you say:

>  [Lucy] RFC2473 is about IPv6 in IPv6, i.e., IPv6 as a delivery network for IPv6 traffic.

but that is not correct. RFC2473 is about "Generic Packet Tunneling in IPv6", which
could include encapsulation of IPv4, IPv6, or other network protocols - and not just
IPv6 within IPv6 encapsulation.

Thanks - Fred

> From: Int-area [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Monday, March 09, 2015 7:52 AM
> To: Lucy yong; Ronald Bonica; [email-masked]

---

From: Lucy yong <[email-masked]>
Date: Mon, 9 Mar 2015 17:55:41 +0000

Hi Templin,

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Monday, March 09, 2015 12:15 PM
To: Lucy yong; Ronald Bonica; [email-masked]
Subject: RE: [Int-area] comment on draft-ietf-intarea-gre-ipv6

Hi Lucy,

>  [Lucy] RFC2473 is about IPv6 in IPv6, i.e., IPv6 as a delivery network for IPv6 traffic.

but that is not correct. RFC2473 is about "Generic Packet Tunneling in IPv6", which could include encapsulation of IPv4, IPv6, or other network protocols - and not just
IPv6 within IPv6 encapsulation.
[Lucy] You are right. It has that generalization although very focusing on IPv6. The misdelivery and corruption issues are concern there too. The draft is very old (1998). IPv6 was barely deployed then. We should address or document these issues if we are working on it now.  

Thanks,
Lucy

Thanks - Fred

> > > Since IPv6 header does not have checksum, if a packet is 
> > > mis-delivered to GRE decapsulator, will that cause a concern? This is not a concern when IPv4 network is the delivery network.
> >
> > [Lucy] RFC2473 is about IPv6 in IPv6, i.e., IPv6 as a delivery 
> > network for IPv6 traffic. Since IPv6 packets and upper layer 
> > applications have to follow RFC2460, i.e., protect the misdelivery 
> > and corruption, so that is OK if there is only such kind of tunnel 
> > in IPv6. GRE-in-
> > IPv6 is deferent. They can't be in the same boat. If there are 
> > various network protocols that are tunneled over a same IPv6 
> > network,
> it
> IPv6 header. Are you saying that (in the RFC2473 case at least) it is 
> OK to omit an integrity check for the encapsulating IPv6 header as 
> long as there is an integrity check for the encapsulated IP header? But, somehow that is not OK for draft-ietf-intarea-gre-ipv6?
> 
> Thanks - Fred
> > > The goal of this draft is *not* to prove the GRE behaves 
> > > identically with IPv6 as it does with IPv4. In fact, its goal is to point out the differences.
> > >

---

From: Tom Herbert <[email-masked]>
Date: Mon, 9 Mar 2015 11:50:55 -0700

> [Lucy] You are right. It has that generalization although very focusing on IPv6. The misdelivery and corruption issues are concern there too. The draft is very old (1998). IPv6 was barely deployed…

We added this paragraph to the GRE-in_UDP draft to describe how the
keyid might be used as a weak authentication. This might be applicable
to gre-ipv6 also:

An implementation MAY use the GRE keyid to authenticate the
   encapsulator. In this model, a shared value is either configured or
   negotiated between an encapsulator and decapsulator. When a GRE-in-
   UDP packet is received with the keyid present, it is checked to see
   if it is valid for the source to have set for the tunnel packet was
   sent on. An implementation MAY enforce that a keyid be used for
   source authentication on selected tunnels. When a decapsulator
   determines a presented keyid is not valid for the source to send or
   the keyid is absent and is considered required for authenticating
   the encapsulator for a tunnel, the packet MUST be dropped.

Thanks,
Tom

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Mar 2015 19:15:32 +0000

Hi Lucy,

> Sent: Monday, March 09, 2015 10:56 AM
> [Lucy] You are right. It has that generalization although very focusing on IPv6. The misdelivery and corruption issues are concern there
> too. The draft is very old (1998). IPv6 was barely deployed then. We should address or document these issues if we are working on it
> now.

RFC2460 is even older still - but, that does not necessarily mean we
should go back and add a checksum field to the IPv6 header. Like
RFC2460, RFC2473 is a standard and has been for a long time. So, if
we don't like it we would need to go back and deprecate it, right?

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Mar 2015 19:19:16 +0000

Hi Tom,

> From: Tom Herbert [mailto:[email-masked]]
> Sent: Monday, March 09, 2015 11:51 AM
> To: Lucy yong
> Cc: Templin, Fred L; Ronald Bonica; [email-masked]
> > [Lucy] You are right. It has that generalization although very focusing on IPv6. The misdelivery and corruption issues are concern
> there too. The draft is very old (1998). IPv6 was barely deployed then. We should address or document these issues if we are working
> on it now.
> >
> 

Sound reasonable. As I read this, I also realize that the draft in question
('draft-ietf-intarea-gre-ipv6') is nothing more than an operational mode
for RFC2473, as RFC2473 allows the inclusion of a GRE header immediately
following the IPv6 header. So, I'm not sure whether a new document is
needed vs. a (bis) of RFC2473 vs. do nothing, since RFC2473 already
covers GRE encapsulation over IPv6.

Thanks - Fred

---

From: Lucy yong <[email-masked]>
Date: Mon, 9 Mar 2015 20:35:38 +0000

Hi Templin,

> but that is not correct. RFC2473 is about "Generic Packet Tunneling in 
> IPv6", which could include encapsulation of IPv4, IPv6, or other 
> network protocols - and not just
> [Lucy] You are right. It has that generalization although very 
> focusing on IPv6. The misdelivery and corruption issues are concern 
> there too. The draft is very old (1998). IPv6 was barely deployed then. We should address or document these issues if we are working on it now.

RFC2460 is even older still - but, that does not necessarily mean we should go back and add a checksum field to the IPv6 header. Like RFC2460, RFC2473 is a standard and has been for a long time. So, if we don't like it we would need to go back and deprecate it, right?
[Lucy] I did not say that the time is a problem. It seems that there is a concern on RFC2473 and nobody looked at this since 1998 when IPv6 was barely deployed, (I would be wrong, new to int-are), I agree that we can correct/enhance a RFC if it is useful protocol and have a problem. 

Regards,
Lucy

Thanks - Fred

> > IPv6 header. Are you saying that (in the RFC2473 case at least) it 
> > is OK to omit an integrity check for the encapsulating IPv6 header 
> > as long as there is an integrity check for the encapsulated IP header? But, somehow that is not OK for draft-ietf-intarea-gre-ipv6?
> >
> > Thanks - Fred
> > > > > Message-ID: 
> > > > > <2691CE0099834E4A9C5044EEC662BB9D4545BB21@dfweml701-
> > > > > chm>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Mar 2015 21:03:12 +0000

Hi Lucy,

> Sent: Monday, March 09, 2015 1:36 PM
> RFC2460 is even older still - but, that does not necessarily mean we should go back and add a checksum field to the IPv6 header. Like
> RFC2460, RFC2473 is a standard and has been for a long time. So, if we don't like it we would need to go back and deprecate it, right?
> [Lucy] I did not say that the time is a problem. It seems that there is a concern on RFC2473 and nobody looked at this since 1998 when
> IPv6 was barely deployed, (I would be wrong, new to int-are), I agree that we can correct/enhance a RFC if it is useful protocol and
> have a problem.

There was a lot of discussion on whether IPv6 should include a header checksum
back in the very earliest days, and it turned out to be one of the fundamental
design points of the protocol. That means that upper layer protocols need to
include a pseudo header in their checksums that covers the IPv6 header.

However, when you have tunnels within tunnels, the outermost encapsulation
may not be covered by a pseudo header checksum of the inner protocol. This
can potentially be addressed by Tom's proposal of leveraging the GRE key field
as a weak integrity check to protect against mis-delivery.

You should see by now why I say that 'draft-ietf-intarea-gre-ipv6' and RFC2473
are in the same boat - the former is simply one operational mode of the latter.

Thanks - Fred

---

From: Lucy yong <[email-masked]>
Date: Mon, 9 Mar 2015 21:22:44 +0000

Hi Templin,
> > but that is not correct. RFC2473 is about "Generic Packet Tunneling 
> > in IPv6", which could include encapsulation of IPv4, IPv6, or other 
> > there too. The draft is very old (1998). IPv6 was barely deployed 
> > then. We should address or document these issues if we are
> working on it now.
> 
> should go back and add a checksum field to the IPv6 header. Like RFC2460, RFC2473 is a standard and has been for a long time. So, if we don't like it we would need to go back and deprecate it, right?
> [Lucy] I did not say that the time is a problem. It seems that there 
> is a concern on RFC2473 and nobody looked at this since 1998 when
> IPv6 was barely deployed, (I would be wrong, new to int-are), I agree 
> that we can correct/enhance a RFC if it is useful protocol and have a problem.

There was a lot of discussion on whether IPv6 should include a header checksum back in the very earliest days, and it turned out to be one of the fundamental design points of the protocol. That means that upper layer protocols need to include a pseudo header in their checksums that covers the IPv6 header.
[Lucy] Yes, this is a fundamental change in IPv6 from IPv4

However, when you have tunnels within tunnels, the outermost encapsulation may not be covered by a pseudo header checksum of the inner protocol. This can potentially be addressed by Tom's proposal of leveraging the GRE key field as a weak integrity check to protect against mis-delivery.
[Lucy] Agree.

You should see by now why I say that 'draft-ietf-intarea-gre-ipv6' and RFC2473 are in the same boat - the former is simply one operational mode of the latter.
[Lucy] Yap. But gre-ipv6 does not aim to address this issue yet. It just documents gre-in-ipv6 as of gre-in-ipv4. This was the reason I started this thread. If it just documents, it needs to point out the issue when using it; or it can enhance the protocol to make it work properly in IPv6.

Thanks,
Lucy

Thanks - Fred

> > > > applications have to follow RFC2460, i.e., protect the 
> > > > misdelivery and corruption, so that is OK if there is only such 
> > > > kind of tunnel in IPv6. GRE-in-
> > > > > > The exact same protocol does not mean the same behavior for 
> > > > > > an application since IPv4 and

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Mar 2015 21:35:32 +0000

Hi Lucy,

> Sent: Monday, March 09, 2015 2:23 PM
> > should go back and add a checksum field to the IPv6 header. Like RFC2460, RFC2473 is a standard and has been for a long time. So, if
> There was a lot of discussion on whether IPv6 should include a header checksum back in the very earliest days, and it turned out to be
> one of the fundamental design points of the protocol. That means that upper layer protocols need to include a pseudo header in their
> checksums that covers the IPv6 header.
> However, when you have tunnels within tunnels, the outermost encapsulation may not be covered by a pseudo header checksum of
> the inner protocol. This can potentially be addressed by Tom's proposal of leveraging the GRE key field as a weak integrity check to
> protect against mis-delivery.
> [Lucy] Agree.
> 
> [Lucy] Yap. But gre-ipv6 does not aim to address this issue yet. It just documents gre-in-ipv6 as of gre-in-ipv4. This was the reason I
> started this thread. If it just documents, it needs to point out the issue when using it; or it can enhance the protocol to make it work
> properly in IPv6.

I won't disagree with that. But, if there is to be a 'draft-ietf-intarea-gre-ipv6', it needs
to say "updates/obsoletes RFC2473". Either that, or perhaps more appropriately an
RFC2473(bis).

Thanks - Fred

---

From: Lucy yong <[email-masked]>
Date: Mon, 9 Mar 2015 21:42:12 +0000

Hi Templin,
> > > but that is not correct. RFC2473 is about "Generic Packet 
> > > Tunneling in IPv6", which could include encapsulation of IPv4, 
> > > IPv6, or other network protocols - and not just
> > > focusing on IPv6. The misdelivery and corruption issues are 
> > > concern there too. The draft is very old (1998). IPv6 was barely 
> > > deployed then. We should address or document these issues if we 
> > > are
> > working on it now.
> >
> > IPv6 was barely deployed, (I would be wrong, new to int-are), I 
> > agree that we can correct/enhance a RFC if it is useful protocol and have a problem.
> 
> There was a lot of discussion on whether IPv6 should include a header 
> checksum back in the very earliest days, and it turned out to be one 
> of the fundamental design points of the protocol. That means that upper layer protocols need to include a pseudo header in their checksums that covers the IPv6 header.
> However, when you have tunnels within tunnels, the outermost 
> encapsulation may not be covered by a pseudo header checksum of the 
> inner protocol. This can potentially be addressed by Tom's proposal of leveraging the GRE key field as a weak integrity check to protect against mis-delivery.
> [Lucy] Agree.
> 
> You should see by now why I say that 'draft-ietf-intarea-gre-ipv6' and 
> RFC2473 are in the same boat - the former is simply one operational mode of the latter.
> [Lucy] Yap. But gre-ipv6 does not aim to address this issue yet. It 
> just documents gre-in-ipv6 as of gre-in-ipv4. This was the reason I 
> started this thread. If it just documents, it needs to point out the issue when using it; or it can enhance the protocol to make it work properly in IPv6.

I won't disagree with that. But, if there is to be a 'draft-ietf-intarea-gre-ipv6', it needs to say "updates/obsoletes RFC2473". Either that, or perhaps more appropriately an RFC2473(bis).
[Lucy] it makes a sense.

Thanks,
Lucy

Thanks - Fred

> > > > > > mis-delivered to GRE decapsulator, will that cause a 
> > > > > > concern? This is not a concern when IPv4 network is the 
> > > > > > delivery
> network.
> > > > >
> > > > > misdelivery and corruption, so that is OK if there is only 
> > > > > such kind of tunnel in IPv6. GRE-in-
> > > > IPv6 header. Are you saying that (in the RFC2473 case at least) 
> > > > it is OK to omit an integrity check for the encapsulating IPv6 
> > > > header as long as there is an integrity check for the encapsulated IP header? But, somehow that is not OK for draft-ietf-intarea-gre-ipv6?
> > > >
> > > > Thanks - Fred
> > > > > > > The exact same protocol does not mean the same behavior 
> > > > > > > for an application since IPv4 and