Hi Fernando, > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On > Behalf Of Fernando Gont > Sent: Thursday, December 15, 2011 6:25 AM > To: ipv6@ietf.org > Subject: Fragmentation-related security issues > > Folks, > > We have published two new IETF I-Ds about fragmentation > related security > issues. > > The first I-D is entitled "Security Implications of > Predictable Fragment > Identification Values" > (http://tools.ietf.org/id/draft-gont-6man-predictable-fragment > -id-00.txt). > Its abstract is: > > ---- cut here ---- > IPv6 specifies the Fragment Header, which is employed for the > fragmentation and reassembly mechanisms. The Fragment Header > contains an "Identification" field which, together with the IPv6 > Source Address and the IPv6 Destination Address of the packet, > identifies fragments that correspond to the same original datagram, > such that they can be reassembled together at the receiving host. > The only requirement for setting the "Identification" value is that > it must be different than that of any other fragmented packet sent > recently with the same Source Address and Destination > Address. Some > implementations simply use a global counter for setting > the Fragment > Identification field, thus leading to predictable values. This > document analyzes the security implications of predictable > Identification values, and updates RFC 2460 specifying additional > requirements for setting the Fragment Identification, such that the > aforementioned security implications are mitigated. > ---- cut here ----
IPsec AH/ESP provide a monotonically-incrementing per-packet sequence number. However, each packet also includes a digital signature that is used to reject spoofed packets. The same is also true of SEAL: http://tools.ietf.org/html/draft-templin-intarea-seal-42 The IPv6 Identification value could similarly be run in a monotonically-incrementing fashion also if each packet includes a digital signature. So, outer IPv6 fragmentation when IPsec or SEAL encapsulation is used should have no problems with a monotonically-incrementing Identification. Thanks - Fred fred.l.temp...@boeing.com > > The second I-D is entitled 'Processing of IPv6 "atomic" fragments' > (http://tools.ietf.org/id/draft-gont-6man-ipv6-atomic-fragment > s-00.txt). > Its abstract is: > > ---- cut here ---- > IPv6 allows packets to contain a Fragment Header, without > the packet > being actually fragmented into multiple pieces. Such packets > typically result from hosts that have received an ICMPv6 > "Packet Too > Big" error message that advertises a "Next-Hop MTU" > smaller than 1280 > bytes, and are currently processed by hosts as "fragmented > traffic". > By forging ICMPv6 "Packet Too Big" error messages an attacker can > cause hosts to employ "atomic fragments", and the launch any > fragmentation-based attacks against such traffic. This document > discusses the generation of the aforementioned "atomic fragments", > the corresponding security implications, and formally updates RFC > 2460 and RFC 5722 such that the attack vector based on "atomic > fragments" is completely eliminated. > ---- cut here ---- > > Any feedback will be very appreciated. > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
