Subject: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu

From: Brian Haberman <[email-masked]>
Date: Wed, 08 Apr 2015 12:54:51 -0400

All,
     I have completed my AD Evaluation of draft-ietf-intarea-gre-mtu as
a part of the publication process.  I only have a few minor comments for
the authors to address.  Once that is done, I will start the IETF Last Call.

* Section 1 - The 4th paragraph specifies that the techniques described
in this document are limited on what protocols can be in the GRE
payload, but doesn't say anything about the delivery protocol. The
Terminology section indicates only v4 and v6 are applicable as the
delivery protocol discussed in this document.  I think it would be
useful to expand the 4th paragraph of the intro to mention the limit on
the delivery protocol.

* Section 1.1

- s/specific MTU discovery/specific to MTU discovery/

- The definition of "fragmentable packet" should include mention of IPv6

- The definition of PTB should be consistent and indicate that IPv6 uses
ICMPv6 Type=2 for PTB messages.

* Section 2.2 - I would suggest clarifying the first bullet by saying
that the fragmentation logic is derived from the payload protocol.

Regards,
Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 8 Apr 2015 17:59:57 +0000

Hi,

Just looking now, this document is seriously messed up. It leaves open
the possibility for denial of service to IPv6 packets of 1280 bytes or
smaller which is a violation of the robustness principle. I had the same
comment regarding the other GRE document.

If people want to see how to handle tunnel MTU, please review
Section 3.13 of draft-templin-aerolink.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: Wednesday, April 08, 2015 9:55 AM
> To: [email-masked]; [email-masked]
> Subject: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu
> 
> All,

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 8 Apr 2015 19:20:12 +0000

Brian,

Thanks for the review. I will spin a new version of the draft addressing all of these comments.

I will spin a new version of the draft addressing all of these comments.

                                  Ron

> From: Brian Haberman [mailto:[email-masked]]
> Sent: Wednesday, April 08, 2015 12:55 PM
> Subject: AD Evaluation: draft-ietf-intarea-gre-mtu
> 
> All,
>      I have completed my AD Evaluation of draft-ietf-intarea-gre-mtu as a part
> of the publication process.  I only have a few minor comments for the
> authors to address.  Once that is done, I will start the IETF Last Call.
> 
> * Section 1 - The 4th paragraph specifies that the techniques described in this
> document are limited on what protocols can be in the GRE payload, but
> doesn't say anything about the delivery protocol. The Terminology section
> indicates only v4 and v6 are applicable as the delivery protocol discussed in
> this document.  I think it would be useful to expand the 4th paragraph of the
> intro to mention the limit on the delivery protocol.
> 
> * Section 1.1
> 
> * Section 2.2 - I would suggest clarifying the first bullet by saying that the
> fragmentation logic is derived from the payload protocol.
> 
> Regards,
> Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 8 Apr 2015 19:30:55 +0000

To be constructive, one way forward would be to define a new field in the GRE
header called the "fragment" field. It would be used to fragment the payload
packet prior to encapsulating each fragment in a separate delivery header.
This would be an example of tunnel fragmentation as suggested in Section
3.1.7 of RFC2764.

End result is that the tunnel egress still has to reassemble, but the system
would not run afoul of IPv4 nor IPv6 fragmentation pitfalls since everything
would look like a whole (unfragmented) packet to the underlying links inside
the tunnel.

'draft-templin-aerolinlk' is one example of this; 'draft-herbert-gue-fragmentation'
is a second.

Thanks - Fred

> From: Int-area [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Wednesday, April 08, 2015 11:00 AM
> To: Brian Haberman; [email-masked]; [email-masked]
> Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu
> 
> Hi,
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Brian Haberman <[email-masked]>
Date: Wed, 08 Apr 2015 18:18:00 -0400

Fred,

> This would be an example of tunnel fragmentation as suggested in Section

That would be a fine proposal to write-up, but it does not belong in
this document.  *This* document describes what vendors have implemented.
 It is an Informational document.

If anything were to go in this document, I could see an additional
description in the Security Considerations section that describes the
vulnerability you are concerned about.

WG?

Regards,
Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 9 Apr 2015 05:13:24 +0000

Hi Brian,

>   It is an Informational document.

Exactly.

> vulnerability you are concerned about.

This was discussed even before the document was adopted. The document 
was originally shooting for BCP and due to these concerns, all 
prescriptive text was removed and it became solely a description of 
existing (and widely deployed) implementations. I had summarized this in 
the WG summary of the Shepherd writeup. I am not sure what to add to the 
Security considerations of this draft, but it is worth exploring.

Thanks
Suresh

---

From: Brian Haberman <[email-masked]>
Date: Thu, 09 Apr 2015 06:36:04 -0400

Hi Suresh,

> Security considerations of this draft, but it is worth exploring.

Given that Fred raised the issue, I would ask that he propose text for
the Security Considerations section that the WG to consider.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 09 Apr 2015 14:03:02 -0400

> the Security Considerations section that the WG to consider.

Will there be a text proposal for this or can the authors spin a new
document based on the existing commentary?

Regards,
Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 9 Apr 2015 18:12:49 +0000

Hi Brian,

I don't have plans of submitting a text proposal, but I have to say that this
document concerns me on many levels. It essentially says that there are
deployed implementations that do not honor the robustness principle
and then seeks to bless them by noting the behavior in the RFC series.

The presence of fragmentation should be an indication to network
operators that something is out of tune and needs to be tuned. It
should not be an excuse to take the tunnel down unconditionally.

Thanks - Fred

> Sent: Thursday, April 09, 2015 11:03 AM
> To: Suresh Krishnan; Templin, Fred L; [email-masked]; [email-masked]

---

From: Brian Haberman <[email-masked]>
Date: Thu, 09 Apr 2015 14:18:49 -0400

Fred,

> and then seeks to bless them by noting the behavior in the RFC series.

This is not blessing these behaviors.  It is documenting what has been
deployed.  The goal is to provide sufficient information so that people
understand what is going on since this approach is not standardized.  If
the WG felt it important to describe limitations/issues with the
approach, it would be well within its right to do so in the document.

There are plenty of examples of Informational RFCs describing deployed
protocols not developed in the IETF.  More than a few times, these
efforts have helped operators understand observed behaviors or led to a
standardization effort to fix issues identified in these Informational
documents.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 09 Apr 2015 14:20:08 -0400

Given the below response, a new version should be generated based on my
feedback and we can continue with the publication process.

Regards,
Brian