Hi Ron,
Thanks for writing this, and for sending it for review to this list.
Please find my review below, which includes sets of comments and suggestions
organized as more substantive / more editorial and prefaced with "CMP:". Hope
these are clear and useful, and glad to iterate on them.
More Substantive:
================
Generic Routing Encapsulation (GRE) Fragmentation Strategy
Abstract
This memo documents a GRE fragmentation strategy upon which many
vendors have converged. Specifically, it defines procedures to be
executed by GRE ingress routers. It is published so that those
...
CMP: The focus of this document is only point-to-point GRE tunnels,
CMP: and does not include any type of Multipoint GRE tunnels. As such,
CMP: I would make this focus explicit in the Abstract, Intro, and in
CMP: the document title.
1. Problem Statement
...
However, implementors and network operators have discovered that some
fragmentation strategies work better than others. A poorly chosen
fragmentation strategy can cause operational issues, including black-
holing, packet reassembly on GRE egress routers and unexpected
interactions with Path MTU Discovery [RFC1191] [RFC1981].
CMP: A big part of a generic discussion of this takes place in RFC 4459.
CMP: That's an informational document, that would make of a great
CMP: Informational pointer since Section 3 of RFC 4459 contrasts
CMP: different approaches.
1.1. How To Use This Document
This memo is presented in sections. Section 2 enumerates design
goals. Section 3 defines procedures that all GRE ingress routers
must execute.
CMP: The impact of this "must" is not clear to me; please see below the
CMP: comments on that section.
1.2. Terminology
The following terms are specific MTU discovery:
o link MTU (LMTU) - the maximum transmission unit, i.e., maximum
packet size in octets, that can be conveyed over a link without
fragmentation
o path MTU (PMTU) - the minimum LMTU of all the links in a path
between a source node and a destination node
CMP: There are two specific clarifications that are important here, I
CMP: believe: i. PMTU is unidirectional, and on a per-direction. So
CMP: in this case is the LMTU from source to destination. ii. there
CMP: is not necessarily "a path", but likely there are multi-paths.
CMP: so given ECMP, this needs to clarify it is of all paths from
CMP: source to sink (and not *the* path *between* source and sink).
3.2. Tunnel MTU (TMTU) Discovery
Implementations MUST maintain a local data structure that reflects
the TMTU of each GRE tunnel that originates on the node. The TMTU
MUST be equal to the PMTU associated with the path between the tunnel
ingress and the tunnel egress, minus the GRE overhead.
CMP: This "MUST" is only applicable when PMTUD is in effect, which is
CMP: not a MUST for this scenario. I would condition the MUST to "when
CMP: PMTUD is being used for the tunnel". For completeness, an editorial:
CMP: The way the first sentence is written appears to be too restrictive
CMP: of how to implement TMTU. The TMTU can be kept as an element in the
CMP: existing data structures hosting tunnel endpoint state.
By default, implementations MUST discover the PMTU associated with
the path between the tunnel ingress and the tunnel egress. PMTU
discovery procedures defined in [RFC1191] and [RFC1981] and will
never permit the PMTU to exceed the LMTU associated with the first IP
hop in the path to the tunnel egress.
CMP: This MUST seems too strict to me. For example, for cases in which
CMP: ICMPs are blocked between the source and destination of the GRE
CMP: tunnel, this requirement can lead to black-holing (instead of
CMP: suboptimal performance at the destination GRE endpoint), and the
CMP: medicine would be worst than the sickness. Or put a different way,
CMP: PMTUD MUST work for this to be a MUST -- however, it is impossible
CMP: to ensure PMTUD MUST work if ICMP 3/4s are blocked. And there is
CMP: no (to my knowledge) PL-PMTUD defined for GRE -- only for TCP.
CMP:
CMP: A nit as well: This is not necessarily a LMTU, but in the case of
CMP: ECMP in the first hop, this is the smallest of the LMTUs associated
CMP: with the paths...
However, implementations MUST include a configuration option that
disables PMTU Discovery for GRE tunnels. This configuration option
may be required to mitigate certain denial of service attacks (see
Section 7). When PMTU discovery for GRE tunnels is disabled, the
TMTU for a tunnel MUST default to the LMTU associated with the first
IP hop in the path to the tunnel egress, minus the GRE overhead.
However, implementations MAY include a configuration option through
which the TMTU can be set to another value, which is likely to be
lower.
CMP: This is good for the case of a single GRE tunnel, but it changes
CMP: if the GRE tunnel is protected with IPsec -- unless, the IPsec
CMP: overhead is somehow counted towards the "GRE Delivery Header".
CMP: I believe there is another key requirement for TMTUD for IPv4: the
CMP: configurability of how to set the DF-bit in the Delivery Header.
CMP: Specifically, the DF can be copied from the tunneled packet (if v4)
CMP: or it can always be set. RFC 2003 (which should also be an Info
CMP: pointer) allows for both. A discussion on why setting DF helps
CMP: speed up the convergence of PMTUD (and consequently of TMTUD)
CMP: would also operators. And a requirement needs to exist for the
CMP: ability to configure this behavior.
CMP: Actually, on third important point as well :-) For PMTUD for GRE
CMP: and TMTUD, when the GRE Tunnel uses GRE Keys, then the Key
CMP: included in the embedded packet of the ICMP PTB should be checked
CMP: against the configured/used Key in the GRE Tunnel (like with TCP).
CMP: This needs to be called out also in the Security Considerations.
4.1. Tunneling GRE Over IPv4
When the GRE ingress router tunnels an IPv4 payload over IPv4, and
the DF Bit in the payload header is set to 0 (May Fragment), by
default, the GRE ingress router MUST set the DF bit in the delivery
header to 1. However, implementations MAY include a configuration
option that allows the DF bit to be copied from the payload header to
the delivery header.
CMP: Wouldn't this be updating RFC 2003? It seems to me that a MUST is
CMP: too strong of a requirement. I can see providing a RECOMMENDED,
CMP: perhaps.
The GRE ingress router MUST NOT emit a delivery header in which the
MF bit is set to 1 (More Fragments).
CMP: Similarly, this MUST NOT seems too limiting (as per the explanation
CMP: above). It seems to me that the success of PMTUD with ICMP being
CMP: best effort delivery is not one to underpin this hard requirement.
5.1. IPv4 Payloads
If the DF bit in the payload header is set to 1 (Don't Fragment), the
GRE ingress router MUST discard the packet and sent an ICMPv4
[RFC0792] Destination Unreachable message to the payload source, with
type equal to 4 (fragmentation needed and DF set). The ICMP
Destination Unreachable message MUST contain an Next-hop MTU (as
specified by [RFC1191]) and the next-hop MTU MUST be equal to the
TMTU associated with the tunnel.
CMP: This is perfect, but for the case in which PMTUD and TMTUD are on.
CMP: This section should condition the requirements to that (because
CMP: it is assuming it is always on).
CMP: I do believe strongly that this is doing the right thing, BTW. I
CMP: am not sure, though, if we can always REQUIRE this.
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.
CMP: This is a most serious concern, because mandating PMTUD/TMTUD (
CMP: the MUST in Section 3.2, 5.1, etc.) without a way to fragment,
CMP: and without a way to signal to the source (e.g., ICMP PTB for IP),
CMP: since in the MPLS case there is no source with merging, then this
CMP: "MUST" effectively creates a permanent black-hole for MPLS over GRE.
CMP:
CMP: Also, I would change this to say something like: if it can be
CMP: reliably determined that the payload of the MPLS packet is IPv4,
CMP: then it can be prefragged and copy the MPLS header to all fragments,
CMP: quite efficiently.
7. Security Considerations
CMP: see comment about about the security consideration of ICMP spoofing.
CMP: This attack is such that makes it hard to justify a "MUST have PMTUD
CMP: enabled by default" in this document.
7.2. Attacks Against PMTU Discovery
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.
CMP: Lastly, in addition (and better sometimes) than just disable PMTUD,
CMP: a tunnel endpoint should provide the configuration option to set
CMP: the minimum TMTU that can be set as a result to ICMP PTB. This
CMP: is to protect against the case of an ICMP PTB with too small MTU.
More Editorial:
==============
Abstract
This memo documents a GRE fragmentation strategy upon which many
vendors have converged.
CMP: This is not "GRE fragmentation" (i.e., which strictly is having
CMP: things like "B" and "E" fragmentation bits in the GRE header.
CMP: THis is a nit, but just for clarity (given that this topic can be
CMP: confusing), I'd use something like "fragmentation in GRE point-to-
CMP: point tunnel scenarios".
1. Problem Statement
...
However, implementors and network operators have discovered that some
fragmentation strategies work better than others. A poorly chosen
fragmentation strategy can cause operational issues, including black-
holing, packet reassembly on GRE egress routers and unexpected
interactions with Path MTU Discovery [RFC1191] [RFC1981].
CMP: I would add here a pointer to the discussion in Section 4.1.4 of
CMP: RFC 3931 as part of the discussion there is applicable to other
CMP: p2p tunnels. This is an Informational pointer.
1.1. How To Use This Document
Section 4 defines procedures affecting generation of the GRE delivery
header. It is divided into two subsections. Section 4.1 is
applicable when GRE is tunneled over IPv4[RFC0791] and Section 4.2 is
applicable when GRE is tunneled over IPv6 [RFC2460].
CMP: Another nit, since the rest of the doc does such a good job at
CMP: being precise with terminology: GRE is not "tunneled" over IP. It
CMP: is "delivered".
1.2. Terminology
The following terms are specific to GRE and are taken from [RFC2784]:
o GRE delivery header - an IPv4 or IPv6 header whose source address
is that of the GRE tunnel ingress and whose destination address is
that of the GRE tunnel egress. The GRE delivery header
encapsulates a GRE header.
CMP: This, again, describes a p2p GRE tunnel. Multipoint flavors should
CMP: be explicitly out of scope.
o GRE payload - a network layer packet that is encapsulated by the
GRE header. The GRE payload can be IPv4, IPv6 or MPLS.
CMP: ... "or other. This document only covers IPv4, IPv6, and MPLS only."
Thanks!
-- Carlos.
On May 29, 2013, at 9:36 AM, Ronald Bonica <[email protected]> wrote:
> Folks,
>
> If you get a chance, please provide a sanity check on this document. It is
> very short, so it won't take much time to review.
>
> Ron
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]]
>> Sent: Wednesday, May 29, 2013 9:34 AM
>> To: Ronald Bonica
>> Subject: New Version Notification for draft-bonica-intarea-gre-mtu-
>> 00.txt
>>
>>
>> A new version of I-D, draft-bonica-intarea-gre-mtu-00.txt
>> has been successfully submitted by Ron Bonica and posted to the IETF
>> repository.
>>
>> Filename: draft-bonica-intarea-gre-mtu
>> Revision: 00
>> Title: Generic Routing Encapsulation (GRE) Fragmentation
>> Strategy
>> Creation date: 2013-05-29
>> Group: Individual Submission
>> Number of pages: 8
>> URL: http://www.ietf.org/internet-drafts/draft-bonica-
>> intarea-gre-mtu-00.txt
>> Status: http://datatracker.ietf.org/doc/draft-bonica-intarea-
>> gre-mtu
>> Htmlized: http://tools.ietf.org/html/draft-bonica-intarea-gre-
>> mtu-00
>>
>>
>> Abstract:
>> This memo documents a GRE fragmentation strategy upon which many
>> vendors have converged. Specifically, it defines procedures to be
>> executed by GRE ingress routers. It is published so that those
>> building new implementations will be aware of best common practice.
>> It is also published so that those building applications over GRE
>> will understand how GRE works.
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
>
> _______________________________________________
> Int-area mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/int-area
>
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
