Re: IPv6 Security Frequently Asked Questions (FAQ)
> On 8 Mar 2019, at 6:30 pm, Fernando Gont wrote: > > Hello, Mark, > > Thanks for your feedback! Please see in-line > > On 8/3/19 04:10, Mark Andrews wrote: >> "Generation of IPv6 fragments in response to ICMPv6 PTB messages has been >> deprecated in the revised IPv6 specification" >> >> IS INCORRECT >> >> generation of fragments is “discouraged". Discouraged and deprecated mean >> different thing. > > There is a writeo here. The text should have said "generation of IPv6 > atomic fragments", or, > > "Generation of IPv6 fragments in response to ICMPv6 PTB messages > advertising an MTU smaller than 1280" > > > The whole section refers to "atomic fragments" which might be generated > even for protocols that are not supposed to employ fragmentation. > > I will clarify this in the next rev. Thanks >> However, the use of such >> fragmentation is discouraged in any application that is able to >> adjust its packets to fit the measured path MTU (i.e., down to 1280 >> octets). >> >> the whole of 4.4 is very badly worded and states things as fact which don’t >> appear in RFC’s at all. > > Please let me know if, considering the writeo I referred to above, you > still feel the same. I think I’ll reserve judgement until I have seen the re-write. >> The adding of a fragmentation header for PTB <1280 has gone. Fragmentation >> down to 1280 is still supposed to happen in response to a PTB. Packets still >> have to flow through paths that narrow down to 1280. > > Agreed. > > This section is referred to this scenario: > > Say two nodes only mean to employ a TCP-based application (say two BGP > peers). Say they filter fragments directed to them, since the TCP > connections will avoid fragmentation. > > In such cases, what would seem as a "safe practice" may be not: if the > involved systems employ a legacy IPv6 implementation, then an attacker > can trigger the generation of IPv6 fragments (even for TCP conenctions) > by spoofing an ICMPv6 PTB claiming an MTU < 1280. > > This is what this section is about: If you are going to drop fragments, > make sure you also take care of ICMPv6 PTBs, since they may trigger > fragmentation even for protocols that you'd assume would never emply > fragmentation. > > Thanks! > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Security Frequently Asked Questions (FAQ)
Hello, Mark, Thanks for your feedback! Please see in-line On 8/3/19 04:10, Mark Andrews wrote: > "Generation of IPv6 fragments in response to ICMPv6 PTB messages has been > deprecated in the revised IPv6 specification" > > IS INCORRECT > > generation of fragments is “discouraged". Discouraged and deprecated mean > different thing. There is a writeo here. The text should have said "generation of IPv6 atomic fragments", or, "Generation of IPv6 fragments in response to ICMPv6 PTB messages advertising an MTU smaller than 1280" The whole section refers to "atomic fragments" which might be generated even for protocols that are not supposed to employ fragmentation. I will clarify this in the next rev. > > However, the use of such >fragmentation is discouraged in any application that is able to >adjust its packets to fit the measured path MTU (i.e., down to 1280 >octets). > > the whole of 4.4 is very badly worded and states things as fact which don’t > appear in RFC’s at all. Please let me know if, considering the writeo I referred to above, you still feel the same. > > The adding of a fragmentation header for PTB <1280 has gone. Fragmentation > down to 1280 is still supposed to happen in response to a PTB. Packets still > have to flow through paths that narrow down to 1280. Agreed. This section is referred to this scenario: Say two nodes only mean to employ a TCP-based application (say two BGP peers). Say they filter fragments directed to them, since the TCP connections will avoid fragmentation. In such cases, what would seem as a "safe practice" may be not: if the involved systems employ a legacy IPv6 implementation, then an attacker can trigger the generation of IPv6 fragments (even for TCP conenctions) by spoofing an ICMPv6 PTB claiming an MTU < 1280. This is what this section is about: If you are going to drop fragments, make sure you also take care of ICMPv6 PTBs, since they may trigger fragmentation even for protocols that you'd assume would never emply fragmentation. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: IPv6 Security Frequently Asked Questions (FAQ)
"Generation of IPv6 fragments in response to ICMPv6 PTB messages has been deprecated in the revised IPv6 specification" IS INCORRECT generation of fragments is “discouraged". Discouraged and deprecated mean different thing. However, the use of such fragmentation is discouraged in any application that is able to adjust its packets to fit the measured path MTU (i.e., down to 1280 octets). the whole of 4.4 is very badly worded and states things as fact which don’t appear in RFC’s at all. The adding of a fragmentation header for PTB <1280 has gone. Fragmentation down to 1280 is still supposed to happen in response to a PTB. Packets still have to flow through paths that narrow down to 1280. > On 8 Mar 2019, at 5:42 pm, Fernando Gont wrote: > > Folks, > > The Internet Society has posted the "IPv6 Security Frequently Asked > Questions (FAQ)" I authored. > > The document is available (in HTML, and also easy-to-print PDF) at: > > https://www.internetsociety.org/deploy360/ipv6/security/faq/ > > If you think there are other questions that should be added, or have > comments on the answers, please do let me know -- the document can > eventually be revised. > > Thanks! > > Cheers, > -- > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
