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

From: Ronald Bonica <[email-masked]>
Date: Thu, 5 Feb 2015 20:40:36 +0000

Tom,

Good point. I will fix this in the next version of the draft.

                                           Ron

> 
> Please clarify receiver checksum handling in section 2.1.
> 
> >From the draft:
> 
> The Checksum Present field SHOULD be set to zero by senders if IPv6
>    is used as a delivery protocol.  Receivers MUST also accept a value
>    of one in this field and use it to calculate the GRE header length
>    but they MUST NOT verify the contents of the Checksum field.
> 
> Why is it a MUST NOT for receivers to validate checksums? Doesn't this
> violate RFC2784?
> 
> Thanks,
> Tom
> 
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 6 Feb 2015 09:25:04 -0800

> Good point. I will fix this in the next version of the draft.

Hi Ronald,

In section 2.1 of draft-ietf-intarea-gre-ipv6-02, making checksum
verification optional at the receiver still seems to change behavior
specified in RFC2784 section 2.2:

"Note that a compliant implementation MUST accept and process this field."

I take this to mean that if checksum field is present it must be
verified, and I believe this is consistent with other use cases of
optional checksums (like the UDPv4 checksum).

More generally though, I don't understand why IPv6 as GRE EtherType,
or any EtherType for that matter, should have any bearing on how the
GRE checksum is handled for either transmit or receive. In fact, given
that IPv6 doesn't have a header checksum, it seems like there might be
more motivation to use GRE checksum with IPv6 than IPv4.

Thanks,
Tom

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

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 6 Feb 2015 21:50:05 +0000

Tom,

Good point. If I don't hear otherwise by next Friday, post another version with the following change:

OLD>
   When the delivery protocol is IPv6, the GRE ingress router SHOULD set
   the Checksum Present field to zero.  GRE egress routers MUST accept
   either a value of zero or one in this field.  If the GRE egress
   router receives a value of one, it MUST use that information to
   calculate the GRE header length.  However, the GRE ingress router is
   not required to use the checksum to verify packet integrity.
<OLD

NEW>
   When the delivery protocol is IPv6, the GRE ingress router SHOULD set
   the Checksum Present field to zero.  GRE egress routers MUST accept
   either a value of zero or one in this field.  If the GRE egress
   router receives a value of one, it MUST use that information to
   calculate the GRE header length and verify packet integrity.
<NEW

Ron

> -----Original Message-----
> From: Tom Herbert [mailto:[email-masked]]
> Sent: Friday, February 06, 2015 12:25 PM
> To: Ronald Bonica
> Cc: [email-masked]
> Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6
> 
> In section 2.1 of draft-ietf-intarea-gre-ipv6-02, making checksum verification
> optional at the receiver still seems to change behavior specified in RFC2784
> section 2.2:
> 
> I take this to mean that if checksum field is present it must be verified, and I
> believe this is consistent with other use cases of optional checksums (like the
> UDPv4 checksum).
> 
> More generally though, I don't understand why IPv6 as GRE EtherType, or
> any EtherType for that matter, should have any bearing on how the GRE
> checksum is handled for either transmit or receive. In fact, given that IPv6
> doesn't have a header checksum, it seems like there might be more
> motivation to use GRE checksum with IPv6 than IPv4.
> 
> Thanks,
> Tom
> 
> >                                            Ron
> >
> >
> >>
> >> Why is it a MUST NOT for receivers to validate checksums? Doesn't
> >> this violate RFC2784?
> >>
> >> Thanks,
> >> Tom
> >>
> >>
> >

---

From: Tom Herbert <[email-masked]>
Date: Fri, 6 Feb 2015 14:13:36 -0800

>    calculate the GRE header length and verify packet integrity.
The SHOULD to set Checksum present to zero still seems unnecessary,
and again there's no reason to a make this recommendation specifically
for IPv6. I suggest that you just remove this section completely,
assuming that RFC2784 is clear enough on checksum handling.

Tom

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 10 Feb 2015 05:39:31 +0000

Hi Tom,

On 02/06/2015 12:25 PM, Tom Herbert wrote:
>>h

I just want to clarify one thing. This text is specifically about using 
IPv6 as the delivery protocol and not as the payload protocol (i.e. what 
is in the EtherType). The intention of the text was to avoid 
checksumming already checksummed payload packets similar to what is 
described for UDP in RFC6935. e.g. If the payload protocol is IPv4, it 
already has a checksum. Why do another checksum in the encapsulating 
IPv6 GRE packet?

Please note that RFC2784 did not provide any guidance about setting the 
Checksum Present field. Do I understand correctly that you want to leave 
things the way they are?

Thanks
Suresh

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 23 Feb 2015 16:50:27 +0000

Hi, I have a comment on this document. 'draft-ietf-intarea-gre-ipv6' is very
much in the same boat as RFC2473 in terms of MTU and Fragmentation
considerations. So, why not just cite Sections 6.7 and 7 of RFC2473 instead
of inventing new text here since the considerations are exactly the same?

But then, there would still be three problems inherent in both documents:

1) There may be no way for the tunnel ingress to determine the MTU on
     the path to the egress, e.g., if ICMP PTB messages are lost or somehow
    forged by an attacker

2) ICMP PTB messages may be lost on the  return path from the tunnel
    ingress to the original source

3) Even in environments where 1) and 2) are not a matter of concern, the
    original source could see an MTU smaller than 1500.

These issues are addressed by Section 3.13 of 'draft-templin-aerolink',
which is applicable for all tunneling environments.  What is in RFC2473
right now (and what 'draft-ietf-intarea-gre-ipv6' should be citing) is only
applicable for controlled environments.

Thanks - Fred
[email-masked]