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

Hi Ron,

> -----Original Message-----
> From: Ronald Bonica [mailto:rbonica@juniper.net]
> Sent: Tuesday, February 24, 2015 9:10 AM
> To: Templin, Fred L; int-area@ietf.org
> Subject: RE: draft-ietf-intarea-gre-ipv6
> 
> Fred,
> 
> Regarding you first comment, the approach taken by RFC 2473 is similar, but not identical to the approach taken by draft-ietf-intarea-
> gre-ipv6. Please compare the text in RFC 2473, Section 7.1.b to the corresponding text in Section 3.1 of draft-ietf-intarea-gre-ipv6.
> 
> Even though the approaches diverge slightly, draft-ietf-intarea-gre-ipv6 should not UPDATE RFC 2473. draft-ietf-intarea-gre-ipv6
> UPDATES GRE encapsulation procedures, that are defined in RFC 2784. . Therefore, draft-ietf-intarea-gre-ipv6 UPDATES RFC 2784. It
> does not UPDATE IP-in-IP encapsulation procedures, that are defined in RFC 2473. Therefore, it shouldn't UPDATE RFC 2473.
> 
> Regarding your second comment, I think that we can safely ignore the issue of loss or forgery of ICMP PTB. That problem is inherent to
> IPv6 fragmentation, and is not specific to tunnels.
> 
> However, we must address the problem that occurs when the tunnel ingress receives an ICMP PTB with an MTU < X. First, the tunnel
> ingress must decide whether to update its estimate of the PMTU. This decision is beyond the scope of this document, as it is not
> unique to encapsulation. Every IPv6 node has to make this decision, regardless of whether it is a tunnel endpoint.
> 
> Assuming that the tunnel endpoint updates its estimate of the PMTU, and the resulting GMTU is lower than 1280, the tunnel endpoint
> has another decision to make. When it receives a packet with size > GMTU, it can either:
> 
> - discard the packet and send an ICMP PTB, or
> - Fragment the delivery header

AFAICT, this is the only difference between what you are saying in your document and
what RFC2473 already says. Your document is saying that it is permissible to return a
PTB that reports a size smaller than 1280. But, that is currently reserved for IPv6/IPv4
translators.  Or, if you want to extend this feature to also apply to tunnels, you need
to also update RFC2473.

Either way, however, you are still not addressing the loss of PTB messages nor the
PTB forgery attack vector.

Thanks - Fred
fred.l.templin@boeing.com

> The current draft specifies a configuration option that governs this decision.
> 
>                                                                                                   Ron
> 
> 
> > -----Original Message-----
> > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
> > Sent: Tuesday, February 24, 2015 10:49 AM
> > To: Ronald Bonica; int-area@ietf.org
> > Subject: RE: draft-ietf-intarea-gre-ipv6
> >
> > Hi Ron,
> >
> > > -----Original Message-----
> > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Ronald
> > > Bonica
> > > Sent: Tuesday, February 24, 2015 6:22 AM
> > > To: int-area@ietf.org
> > > Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6
> > >
> > > Hi Fred,
> > >
> > > Inline.......
> > >
> > > >
> > > > Message: 1
> > > > Date: Mon, 23 Feb 2015 16:50:27 +0000
> > > > From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
> > > > To: "int-area@ietf.org" <int-area@ietf.org>
> > > > Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6
> > > > Message-ID:
> > > > 	<2134F8430051B64F815C691A62D9831832DFB25B@XCH-BLV-
> > > > 504.nw.nos.boeing.com>
> > > >
> > > > Content-Type: text/plain; charset="us-ascii"
> > > >
> > > > 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?
> > > >
> > > [RPB]
> > >
> > > RFC 2473 addresses the same problem for IP-in-IP encapsulation. It stands
> > to reason that the two approaches would be similar.
> >
> > Not similar - identical.
> >
> > > However, the text in RFC 2473 is a proper subset of the text in
> > > Section 3.1 of draft-ietf-intarea-gre-ipv6. Since much of the text in
> > > draft-ietf-intarea-gre-ipv6 is new, for the sake of readability, it makes
> > sense to restate the part that is also presented in RFC 2473.
> >
> > I disagree. RFC2473 is an already-published standard that specifies MTU and
> > fragmentation considerations that apply also to this document. This
> > document should therefore cite the RFC2473 text normatively.
> >
> > If you think there is something new to be said in this document, then that
> > should also update RFC2473. But, I don't see where this document is saying
> > anything new.
> >
> > > > 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
> > > >
> > > [RPB]
> > > Isn't loss or forgery of PTB messages a well-known issue for IPv6,
> > regardless of whether any tunnels are involved?
> >
> > Tunnels can address these issues by ignoring ICMP PTB messages that report
> > a size smaller than 1500 bytes.
> >
> > > > 2) ICMP PTB messages may be lost on the  return path from the tunnel
> > > >     ingress to the original source
> > > [RPB]
> > > Same comment as above
> >
> > What is missing is a recommendation for original sources to use RFC4821.
> >
> > > > 3) Even in environments where 1) and 2) are not a matter of concern, the
> > > >     original source could see an MTU smaller than 1500.
> > > [RPB]
> > > This is addressed in Sections 4.1 of draft-ietf-intarea-gre-ipv6.
> >
> > What I mean is, if the tunnel does not support a guaranteed minimum MTU
> > of 1500 bytes then a PTB message reporting a size less than 1500 bytes would
> > need to be returned to the sender. If that PTB message is lost, the result is a
> > black hole.
> >
> > So, what I am saying is that tunnels should support a guaranteed minimum
> > MTU of 1500 bytes as in 'draft-templin-aerolink'. This is not addressed in your
> > document.
> >
> > Thanks - Fred
> > fred.l.templin@boeing.com
> >
> > >                                              Ron
> > >
> > > >
> > > > 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
> > > > fred.l.templin@boeing.com
> > > >
> > >
> > > _______________________________________________
> > > Int-area mailing list
> > > Int-area@ietf.org
> > > https://www.ietf.org/mailman/listinfo/int-area