Hi Brian, > -----Original Message----- > From: Brian E Carpenter [mailto:[email protected]] > Sent: Wednesday, January 04, 2012 6:55 PM > To: Templin, Fred L > Cc: Fernando Gont; [email protected] > Subject: Re: Fragmentation-related security issues > > On 2012-01-05 11:50, Templin, Fred L wrote: > > > > > >> -----Original Message----- > >> From: Fernando Gont [mailto:[email protected]] > >> Sent: Wednesday, January 04, 2012 2:22 PM > >> To: Templin, Fred L > >> Cc: Brian E Carpenter; [email protected] > >> Subject: Re: Fragmentation-related security issues > >> > >> On 01/04/2012 07:06 PM, Templin, Fred L wrote: > >>>> I see no reason to expect that PMTUD will be more reliable for > >>>> IPv6 than for IPv4. > >>> I think a lot is now hinging on the assumption that > >>> PMTUD for IPv6 works. Unlike the situation for IPv4, > >>> I see no reason to expect that PMTUD for IPv6 will > >>> be unreliable. > >> It has been found to break, already -- as a result of firewalls > >> filtering ICMPv6 messages, are some intermediate systems with > >> inappropriate rate limiting for all ICMPv6 traffic. > > > > If IPv6 PMTUD breaks, it is due to violations of the specs. > > If IPv6 PMTUD breaks, then we are lost - time to give up > > and design a different protocol? > > The point is that paranoid firewalls will turn this into an > arms race - if they are paranoid enough to block ICMP PTB, > which apparently many are, why wouldn't they block any other > signalling mechanism - especially a new one?
SEAL provides a new signalling mechanism called "SCMP" which is intended to traverse firewalls that might block ICMP messages. SCMP messages include a message signature that the source node can use to determine whether the packet-in-error corresponds to a packet the node actually sent. Under what reasonable circumstances could even a paranoid firewall block that? > That's why RFC 4821 describes MTU probing hidden in the transport > layer, where hopefully firewalls would let it be. You will > probably look in vain for widely deployed versions of RFC 4821. Thanks for mentioning RFC4821 - it occurred to me last nite that I had mis-spoken and that RFC4821 is advisable even if the network is making a best effort to return ICMPs. I think this is fairly well captured in Section 5.6 of RFC6434. However, the use or non-use of RFC4821 does not excuse the network from making a best effort to return the required *CMPs. Fred [email protected] > Brian > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
