Subject: Re: [Int-area] FW: I-D Action:draft-ietf-intarea-gre-ipv6-09.txt

From: Ronald Bonica <[email-masked]>
Date: Thu, 25 Jun 2015 21:20:42 +0000

Lucy,

Good point. I have posted a new version of the draft that omits the offending paragraph.

I tried to wordsmith the offending paragraph so that it would say what I meant. However, when I did that, it became redundant with the preceding paragraph.

The final sentence in Section 2.1 encourages operators to evaluate the risks in their network and configure the GRE ingress appropriately. So, if they need the Checksum Present field to be set to one, they can configure that behavior.

                                                                           Ron

> 
> Message: 3
> Date: Thu, 25 Jun 2015 17:15:38 +0000
> From: Lucy yong <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: [Int-area] FW:  I-D Action:
> 	draft-ietf-intarea-gre-ipv6-09.txt
> Message-ID: <2691CE0099834E4A9C5044EEC662BB9D5718B286@dfweml701-
> chm>
> Content-Type: text/plain; charset="us-ascii"
> 
> Some comments:
> 
> Section 2.1 description is not right. GRE checksum can't detect a mis-
> delivered packet and neither the checksum function in the payload. GRE
> checksum only provides integrity check on GRE header and GRE payload.
> 
> Only IPv4 payload has the equivalent payload integrity check as of GRE
> checksum. GRE does not directly carry TCP or UDP. When GRE payload
> protocol is not IPv6, the payload still can carry TCP or UDP. For example, GRE
> payload is either Ethernet or MPLS that carries IP/TCP/UDP flows. This
> satisfies "the payload carries TCP or UDP"; in this case, TCP and UDP
> checksum does not provide the same integrity check as of GRE checksum.
> 
> GRE can be used in many ways. These examples seem not sufficient for the
> justification of GRE checksum zero.
> 
> Since Ipv6 has flow label, it would be good for the draft to describe use of
> flow label in IPv6 header.
> 
> Regards,
> Lucy
> 
> 
> 
> 
> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: Thursday, June 25, 2015 11:07 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-09.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Internet Area Working Group Working Group
> of the IETF.
> 
>         Title           : IPv6 Support for Generic Routing Encapsulation (GRE)
>         Authors         : Carlos Pignataro
>                           Ron Bonica
>                           Suresh Krishnan
> 	Filename        : draft-ietf-intarea-gre-ipv6-09.txt
> 	Pages           : 10
> 	Date            : 2015-06-25
> 
> Abstract:
>    Generic Routing Encapsulation (GRE) can be used to carry any network-
>    layer payload protocol over any network-layer delivery protocol.  GRE
>    procedures are specified for IPv4, used as either the payload or
>    delivery protocol.  However, GRE procedures are not specified for
>    IPv6.
> 
>    This document specifies GRE procedures for IPv6, used as either the
>    payload or delivery protocol.  It updates the GRE specification, RFC
>    2784.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-ipv6/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gre-ipv6-09
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
> 
> 
> ------------------------------
> 
> End of Int-area Digest, Vol 119, Issue 4
> ****************************************

---

From: Lucy yong <[email-masked]>
Date: Thu, 25 Jun 2015 22:59:45 +0000

Ron,

Quick fix. :)

   The GRE ingress node SHOULD set the Checksum Present field to zero.
   However, implementations MAY support a configuration option that
   causes the GRE ingress node to set the Checksum Present field to one.

Does this mean that, by default, GRE ingress node sets Checksum Present field to zero, and it is optional for an implementation to support GRE Checksum? Please clarify. Should it be "implementations MUST support a configuration option ...".

IMHO: The text in Section 2.1 and 4.2 has some redundancy. Please check.

Thanks,
Lucy

-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]] 
Sent: Thursday, June 25, 2015 4:21 PM
To: [email-masked]; Lucy yong
Subject: RE: [Int-area] FW: I-D Action:draft-ietf-intarea-gre-ipv6-09.txt

Lucy,

                                                                           Ron

> protocol is not IPv6, the payload still can carry TCP or UDP. For 
> example, GRE payload is either Ethernet or MPLS that carries 
> IP/TCP/UDP flows. This satisfies "the payload carries TCP or UDP"; in 
> this case, TCP and UDP checksum does not provide the same integrity check as of GRE checksum.
> 
> GRE can be used in many ways. These examples seem not sufficient for 
> the justification of GRE checksum zero.
> 
> Since Ipv6 has flow label, it would be good for the draft to describe 
> use of flow label in IPv6 header.
> 
> Regards,
> Lucy
> 
> 
> 
> 
> From: Int-area [mailto:[email-masked]] On Behalf Of 
> internet- [email-masked]
>  This draft is a work item of the Internet Area Working Group Working 
> Group of the IETF.
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
>

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 26 Jun 2015 19:41:24 +0000

Hi Lucy,

I am reluctant to mandate a configuration option that causes the GRE ingress node to set the Checksum present field to one. Rationale follows:

Imagine a packet traveling across the Internet. Depending on the packet type, some portions of the packet are protected by checksums and other portions of the packet are not.  Now encapsulate that packet in a GRE header, with the GRE Checksum Present field set to zero. The portions of the packet that were protected by checksums before encapsulation are still protected. The portions of the packet that were not protected by checksums before encapsulation are still not protected.

In light of this, the above mentioned configuration switch is a good thing to have, but not a strict requirement.

Also, Sections 2.1 and 4.2 are very similar, because the both deal with checksums. However:

- Section 2.1 we are talking about the GRE payload, which may be protected by multiple, possibly redundant checksums
- Section 4.2 we are talking about the IPv6 delivery header, which isn't protected by any checksum

                                                                        Ron

> From: Lucy yong [mailto:[email-masked]]
> Sent: Thursday, June 25, 2015 7:00 PM
> To: Ronald Bonica; [email-masked]
> Does this mean that, by default, GRE ingress node sets Checksum Present
> field to zero, and it is optional for an implementation to support GRE
> Checksum? Please clarify. Should it be "implementations MUST support a
> configuration option ...".
> 
> I tried to wordsmith the offending paragraph so that it would say what I
> meant. However, when I did that, it became redundant with the preceding
> paragraph.
> 
> The final sentence in Section 2.1 encourages operators to evaluate the risks
> in their network and configure the GRE ingress appropriately. So, if they
> need the Checksum Present field to be set to one, they can configure that
> behavior.
> 
>                                                                            Ron
> 
> 
> 
> >
> > Message: 3
> > Message-ID:
> <2691CE0099834E4A9C5044EEC662BB9D5718B286@dfweml701-
> > chm>

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 26 Jun 2015 20:14:07 +0000

Hi,

the UDP checksum field is not a codepoint to exchange configuration information in.

In other words, zero has been a special case since the first specification of UDP. But all other values cannot be overloaded to have special meaning.

Lars

---

From: Lucy yong <[email-masked]>
Date: Fri, 26 Jun 2015 20:17:39 +0000

Lars,

I am confused by your comment. This thread is about GRE encapsulation over IPv6 network. Not about UDP encapsulation.

Lucy

-----Original Message-----
From: Eggert, Lars [mailto:[email-masked]] 
Sent: Friday, June 26, 2015 3:14 PM
To: Lucy yong
Cc: Ronald Bonica; [email-masked]
Subject: Re: [Int-area] I-D Action:draft-ietf-intarea-gre-ipv6-09.txt

Hi,

Lars

On 2015-6-25, at 15:59, Lucy yong <[email-masked]> wrote:
> Subject: RE: [Int-area] FW: I-D 
> Action:draft-ietf-intarea-gre-ipv6-09.txt
> 
> Lucy,
> 
>> Section 2.1 description is not right. GRE checksum can't detect a 
>> mis- delivered packet and neither the checksum function in the 
>> payload. GRE checksum only provides integrity check on GRE header and GRE payload.
>> 
>> Only IPv4 payload has the equivalent payload integrity check as of 
>> GRE checksum. GRE does not directly carry TCP or UDP. When GRE 
>> payload protocol is not IPv6, the payload still can carry TCP or UDP. 
>> For example, GRE payload is either Ethernet or MPLS that carries

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 26 Jun 2015 20:41:32 +0000

Sorry, please disregard. I need coffee.

Lars

---

From: Ronald Bonica <[email-masked]>
Date: Sat, 27 Jun 2015 20:05:32 +0000

Lars,

I'm not sure that I am parsing your comment correctly.

The current draft doesn't set, use or even examine the TCP or UDP Checksums. It merely notes that if the TCP or UDP checksums are present, and the GRE checksum is present, the two checksums will protect some of the same fields.

                                                                                         Ron

> Sent: Friday, June 26, 2015 4:14 PM
> To: Lucy yong
> In other words, zero has been a special case since the first specification of
> UDP. But all other values cannot be overloaded to have special meaning.
> 
> Lars
>