Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-03.txt

From: "C. M. Heard" <[email-masked]>
Date: Thu, 12 Sep 2013 15:54:16 -0700 (PDT)

Greetings,

Ron asked me to take a look at this document and comment to the
INTAREA mailing list.  Since I'm not a GRE subject matter expert,
I'm not in a position to judge whether the document accurately
represents current practice.  My comments will therefore necessarily
be limited to issues of document consistency and clarity.

Section 1, Introduction, and Section 3.1, General requirements:

I see that RFC 2784 was updated by RFC 2890, and as far as I can
tell, RFC 2890 is still in force.  Is this worth mentioning, for
sake of completeness?  If yes, here are suggestions for changes to
the text:

Section OLD:
   Generic Routing Encapsulation (GRE) [RFC2784] can be used to carry
   any network layer protocol over any network layer protocol.  GRE has
   been implemented by many vendors and is widely deployed on the
   Internet.

Section 1 NEW:
   Generic Routing Encapsulation (GRE) [RFC2784][RFC2890] can be
   used to carry any network layer protocol over any network layer
   protocol.  GRE has been implemented by many vendors and is widely
   deployed on the Internet.

Section 3.1 OLD:
   Implementations MUST satisfy all of the requirements stated in
   [RFC2784].

Section 3.1 NEW:
   Implementations MUST satisfy all of the requirements stated in
   [RFC2784] and optionally MAY satisfy those stated in [RFC2890].

A normative reference to RFC 2890 would need then to be added.

If RFC 2890 is obsolete and/or sparsely implemented, please
disregard these suggestions.

Section 1.2, Terminology:

Presumably MPLS packets are not fragmentable.  If so, I would
 suggest the following change:

OLD:
   o  non-fragmentable packet - all IPv4 packets with DF-bit equal to 1.
      Also, for the purposes of this document, all IPv6 packets are
      considered to be non-fragmentable.

NEW:
   o  non-fragmentable packet - all IPv4 packets with DF-bit equal to 1.
      Also, for the purposes of this document, all IPv6 packets and MPLS
      packets are considered to be non-fragmentable.

Section 2.1,  Candidate Strategies:

OLD:
   Strategy 1 is an attractive alternative to Strategy 1, because it
   does not rely on PMTUD.  [...]

NEW:
   Strategy 1 is an attractive alternative to Strategy 4, because it
   does not rely on PMTUD.  [...]

Section 2.2, Strategic Overview, at the very end:

   The non-default mode of operation is desirable in some scenarios
   where networks block ICMP messages required by PMTUD.

Would it be possible to provide an informative reference or to add
some explanatory text to make this more specific?  I grant that such
an explanation is not strictly necessary to explain how GRE
fragmentation works, but it would sure help motivate the the design
choices described in the document.  it also seems to me that such
information would help an operator decide when (and when not) to use
the non-default mode.

Section 3.2, Tunnel MTU (TMTU) Estimation and Discovery

   However, if an implementation supports PMTUD or PLPMTUD for GRE
   tunnels, it MUST include a configuration option that disables those
   procedures.  This configuration option may be required to mitigate
   certain denial of service attacks (see Section 8).  When PMTUD is
   disabled, the TMTU MUST be set to a value that is less than or equal
   to the LMTU associated with the next-hop towards tunnel egress, minus
   the GRE overhead.

I understand the reason for having a switch to turn off conventional
PMTUD, namely the possiblility of attacks from forged ICMPv4/ICMPv6
Packet Too Big messages.  However, it does not seem to me that
PLPMTUD alone, without the use of ICMP messages, is vulnerable to
this attack, so why turn it off, too?  If that reasoning is correct,
here is possible replacement text:

   However, if an implementation supports PMTUD for GRE tunnels, it MUST
   include a configuration option that disables this procedure.  This
   configuration option may be required to mitigate certain denial of
   service attacks (see Section 8).  When PMTUD is disabled, the TMTU
   MUST be set to a value that is less than or equal to the LMTU
   associated with the next-hop towards tunnel egress, minus the GRE
   overhead.  PLPMTUD procedures MAY continue to be run when this
   option is selected, but if they do, they MUST NOT rely on the
   contents of any ICMPv4/ICMPv6 messages.

Section 4.1, Tunneling GRE Over IPv4:

   However, the GRE ingress router MUST support a configuration option
   that invokes the following behavior:

   o  when the GRE payload is IPv6, the DF-bit on the delivery header is
      set to 0 (Fragments Allowed)

   o  when the GRE payload is IPv4, the DF-bit value is copied from the
      payload header to the delivery header

For a while I was quite confused about the above text.  After some
head scratching I noticed that it seems to beinconsistent with the
following text in Section 2.2, Strategic Overview, since IPv6 is
considered non-fragmentable for the purposes of this draft:

   However, if the ingress router delivers fragmentable payload over
   IPv4, it copies the DF-bit value from the payload header to the
   delivery header.  Therefore, the GRE delivery packet may be
   fragmented by any router between the GRE ingress and egress.  When
   this occurs, the GRE delivery packet is reassembled by the GRE
   egress.

After looking at the informative reference RFC 4459, and then
chaining back to RFC 2003 (IP Encapsulation within IP, referenced by
RFC 4459 but not the present draft), it seemed that what was said
in Section 2.2 was right, and that the above-quoted text from
Section 4.1 should read as follows:

   However, the GRE ingress router MUST support a configuration option
   that invokes the following behavior:

   o  when the GRE payload is IPv6 or MPLS, the DF-bit on the delivery
      header is set to 1 (Fragmention Not Allowed)

   o  when the GRE payload is IPv4, the DF-bit value is copied from the
      payload header to the delivery header

   When the DF-bit on the delivery header is set to 0, the GRE delivery
   packet may be fragmented by any router between the GRE ingress and
   egress and the GRE delivery packet will be reassembled by the GRE
   egress.

If I correctly understood what I read in RFC 4459 and RFC 2003, the
rationale for allowing the delivery packet to be fragmented when a
payload IPv4 packet has DF=0 is because the IPv4 source node may not
implement PMTUD (which an IPv6 node needs to do) or may be behind a
middlebox that blocks ICMP messages and/or clears the DF bit (the
latter being possible for IPv4 but not IPv6).  But this isn't
explained very clearly in either of those RFCs and not at all in the
present draft; that was why I requested above a rationale for the
non-default option in comments above.

If I am wrong and the text should stay the way it is, I think an
explanation of why to set DF=0 in the delivery header when the
payload is IPv6 would very much be in order, and it would also be a
good idea to specify what happens for MPLS payloads.

Section 5.3, MPLS Payloads

   The GRE ingress router MUST discard the packet.  As it is impossible
   to reliably identify the payload source, the GRE ingress router MUST
   NOT attempt to send an ICMPv4 Destination Unreachable message or an
   ICMPv6 Packet Too Big message to the payload source.

RFC 4023 Section 5.1 identifies an exception to this situation when
the ingress router is also the MPLS encapsulator.  In order to take
that situation into account, may I suggest the following alternative
text, largely plagiarized from RFC 4023:

   The GRE ingress router MUST discard the packet.  In general, it is
   impossible to reliably identify the payload source, and in that case
   the GRE ingress router MUST NOT attempt to send an ICMPv4 Destination
   Unreachable message or an ICMPv6 Packet Too Big message to the
   payload source.  However, there is an exception to this rule if the
   ingress router is the MPLS encaplsuation entity and it receives an IP
   packet for encapsulation, which it first encapsulates in MPLS and then
   encapsulates in MPLS-in-GRE.  In that case, if the source of the IP
   packet is reachable from the ingress router, and if the result of
   encapsulating the packet in MPLS would be a packet whose size exceeds
   the Tunnel MTU, then the ingress router SHOULD send the IP source of
   the discarded packet the proper ICMP error message.

Secton 8, Security Considerations:

OLD:
   PMTU Discovery is vulnerable to two denial of service attacks (see
   Section 8 of [RFC1191] for details).  Both attacks are based upon on
   a malicious party sending forged ICMPv4 Destination Unreachable or
   ICMPv6 Packet Too Big messages to a host.  In the first attack, the
   forged message indicates an inordinately small PMTU.  In the second
   attack, the forged message indicates an inordinately large MTU.  In
   both cases, throughput is adversely affected.  On order to mitigate
   such attacks, GRE implementations MUST include a configuration option
   to disable PMTU discovery on GRE tunnels.  Also, they MAY include a
   configuration option that conditions the behavior of PMTUD to
   establish a minimum PMTU.

NEW:
   PMTU Discovery is vulnerable to a denial of service attack (see
   Section 8 of [RFC1191] and Section 6 of [RFC1981] for details).  This
   attack is based upon on a malicious party sending a forged ICMPv4
   Destination Unreachable or ICMPv6 Packet Too Big messages to a host
   indicating an inordinately small PMTU, causing throughput to be
   adversely affected.  On order to mitigate this attack, GRE
   implementations MUST include a configuration option to disable PMTU
   discovery on GRE tunnels.  Also, they MAY include a configuration
   option that conditions the behavior of PMTUD to establish a minimum
   PMTU.

Rationale: both RFC 1981 and RFC 1191 specify that a host should
never raise its estimate of the PMTU based on a Datagram Too Big
message and so should not be vulnerable to an attacker sending
forged ICMP messages indicating an inordinately large PMTU.

General comment: if my understanding that Strategy 1 is never
supported for IPv6 payloads is correct, then a GRE tunnel carrying
IPv6 payloads must have a TMTU of at least 1280 bytes.  If that was
the intent, I'm content with the text as is (modulo corrections
requested above).  If that was NOT the intent, there is probably be
a need for further clarifications.

Thanks for the opportunity to review the document.  I hope that my
comments are helpful.

Mike Heard

On Thu, 15 Aug 2013, Ronald Bonica wrote:
> Folks,
> 
> This draft version addresses issues raised by Lars and Bob.
> 
>                                      Ron
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Thursday, August 15, 2013 1:49 PM
> > To: Ronald Bonica; Carlos Pignataro; Joe Touch; Dr.Joseph D.Touch
> > Subject: New Version Notification for draft-bonica-intarea-gre-mtu-03.txt
> > 
> > 
> > A new version of I-D, draft-bonica-intarea-gre-mtu-03.txt
> > has been successfully submitted by Ron Bonica and posted to the IETF
> > repository.
> > 
> > Filename:        draft-bonica-intarea-gre-mtu
> > Revision:        03
> > Title:           A Fragmentation Strategy for Generic Routing Encapsulation (GRE)
> > Creation date:   2013-08-15
> > Group:           Individual Submission
> > Number of pages: 12
> > URL:             http://www.ietf.org/internet-drafts/draft-bonica-intarea-gre-mtu-03.txt
> > Status:          http://datatracker.ietf.org/doc/draft-bonica-intarea-gre-mtu
> > Htmlized:        http://tools.ietf.org/html/draft-bonica-intarea-gre-mtu-03
> > Diff:            http://www.ietf.org/rfcdiff?url2=draft-bonica-intarea-gre-mtu-03
> > 
> > Abstract:
> >    This memo documents a GRE fragmentation strategy that has been
> >    implemented by many vendors and deployed in many networks.  It was
> >    written so that a) implementors will be aware of best common practice
> >    and b) those who rely on GRE will understand how implementations
> >    work.  The scope of this memo is limited to point-to-point GRE
> >    tunnels.  All other tunnel types are beyond the scope of this memo.
> > 
> > 
> > 
> > 
> > 
> > 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.
> > 
> > The IETF Secretariat
> > 
> > 
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Sep 2013 19:35:19 +0000

Hi, this document suggests using PLPMTUD (RFC4821) for GRE tunnels,
but it doesn't say anything about how that might be done or for what
purposes. I have produced an implementation that does exactly that:

  http://linkupnetworks.com/seal/sealv2-0.0.tgz

Briefly, the implementation works as follows:

  1) If the inner packet is no larger than 1280 bytes minus the
     length of the encapsulation headers, encapsulate and send
     without fragmentation.

  2) If the inner packet is larger than 1500 bytes but no larger
     than the path MTU, encapsulate and send without fragmentation.

  3) For all other packets, encapsulate and use SEAL fragmentation
     to break the packets into a size that should be small enough
     to traverse the tunnel without further fragmentation even if
     there are other tunnels in the path. At the same time, probe
     the path to see if packets of this size can be delivered without
     fragmentation and, if so, discontinue the fragmentation process
     and send future packets in this size range as whole packets.

The procedures are specified in 'draft-templin-intarea-seal', which
can be found here:

    http://tools.ietf.org/html/draft-templin-intarea-seal

Thanks - Fred
[email-masked]