Carlos,
Thanks for this thoughtful review. All comments accepted. Expect an updated
version of the draft next week.
Ron
> -----Original Message-----
> From: Carlos Pignataro (cpignata) [mailto:[email protected]]
> Sent: Sunday, June 02, 2013 3:23 PM
> To: Ronald Bonica
> Cc: Internet Area
> Subject: Re: [Int-area] New Version Notification for draft-bonica-
> intarea-gre-mtu-00.txt
>
> 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
