> -----Original Message----- > From: Jared Mauch [mailto:ja...@puck.nether.net] > Sent: Wednesday, January 04, 2012 4:23 AM > To: Dan Wing > Cc: 'Eric Vyncke (evyncke)'; ipv6@ietf.org > Subject: Re: Fragmentation-related security issues > > > On Jan 4, 2012, at 12:27 AM, Dan Wing wrote: > > >> -----Original Message----- > >> From: Jared Mauch [mailto:ja...@puck.nether.net] > >> Sent: Tuesday, January 03, 2012 6:15 PM > >> To: Dan Wing > >> Cc: Eric Vyncke (evyncke); ipv6@ietf.org > >> Subject: Re: Fragmentation-related security issues > >> > >> Broken and misconfigured network elements will always exist. We > needn't > >> create solutions for everyone's problems that should be addressed > >> otherwise. > > > > Ok. So what of the IPv6/IPv4 translators which are placed in front > > of existing, operational IPv4 networks. > > If the translator can't talk at some larger MSS, it can reduce that, > one does this on cisco with 'ip tcp adjust-mss' on the interface for > TCP. > I assume nobody forgot to create a comparable command for ipv6 :)
We can clamp TCP MSS on our various translator devices. (Oh, Cisco did forget to create a comparable command for IPv6, helpful for tunnels and what-not on IPv4 and IPv6 because ICMP is so often borked or filtered. That oversight is being fixed.) > For UDP, there are silent drops/blackholes today. Translation > technologies > are a bandaid and expected to have tradeoffs. This will be one of them > that may make going native more attractive. Unfortunately a broken network is just that: broken. It does not encourage users to move, just to demand a fix. -d > Expecting the ICMP messages that may be dropped already to be > propagated and > translated properly isn't ideal, but this is something that doesn't > need lots > of attention. > > - Jared > > > > > -d > > > > > >> Jared Mauch > >> > >> On Jan 3, 2012, at 8:23 PM, "Dan Wing" <dw...@cisco.com> wrote: > >> > >>>> -----Original Message----- > >>>> From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com] > >>>> Sent: Tuesday, January 03, 2012 1:53 PM > >>>> To: Dan Wing (dwing) > >>>> Cc: ipv6@ietf.org > >>>> Subject: RE: Fragmentation-related security issues > >>>> > >>>>> -----Original Message----- > >>>>> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On > >> Behalf > >>>> Of Dan > >>>>> Wing (dwing) > >>>> > >>>>> So, I don't think we can just wish away packet-too-big < 1280. > >>>> > >>>> Rather than dropping those ICMP PTB, let's accept them but let the > >> OS > >>>> decide which is the minimum size path MTU that it can > >>>> accept/tolerate... > >>>> - For a server, this min path MTU should be large (to avoid DoS) > >>>> - For a host, this min path MTU could be small > >>>> > >>>> Of course, if the path is symmetric, the path MTU will be the same > >> on > >>>> both direction (assuming everything is well configured). > >>>> > >>>> OTOH, as written by Jared, let's fail it hard so it is noticeable > by > >>>> the user is another technique... but with a dual-stack and happy > >> eye- > >>>> ball, the end-user will notice nothing and will stay happy with > >> IPv4. > >>> > >>> Happy Eyeballs, is spec'd and as implemented by Chrome and Firefox, > >>> and I think also as implemented by Apple, will _not_ fail nicely > >>> on Path MTU Discovery problems. It will only fail nicely if > >>> connectivity fails (that is, unable to establish the TCP > >>> connection). > >>> > >>> -d > >>> > >>> > >>> ------------------------------------------------------------------- > - > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> ------------------------------------------------------------------- > - -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
