Hi Simon, See inline.
Cheers, Ian >This part is still not OK: > >> 5.2.1. Changes to RFC2473 and RFC6333 Fragmentation Behaviour >> >> On receiving an encapsulated packet containing an IPv4 fragment, the >> lwB4 SHOULD wait until all other fragments have been received and de- >> capsulated. The original packet is then re-assembled before >> performing NAPT. This is necessary because layer-4 protocol >> information is only present in the first fragment. > >I'll repeat what I wrote on 2014-01-16: > >It's possible to do it correctly without waiting for all fragments >(e.g., what Cisco calls "virtual reassembly"). My suggestion would be to >steal the very carefully written text from RFC 6146, page 19. [ian] My apologies - I wasn¹t familiar with the Cisco feature that you mentioned, so researched it and all of the information that I¹ve found is the Cisco VFR (virtual fragment reassembly). I thought that I¹d captured this with the RFC4459 reference, but it looks like it¹s also covering the tiny fragment attacks described in RFC1858. What about: 5.2.1. Changes to RFC2473 and RFC6333 Fragmentation Behaviour On receiving an encapsulated packet containing an IPv4 fragment, the lwB4 SHOULD wait until all other fragments have been received and de- capsulated. The original packet is then re-assembled before performing NAPT. This is necessary because layer-4 protocol information is only present in the first fragment. However, as this provides potential security flaws (as discussed in [RFC1858] and [RFC4459] Section 5) it is RECOMMENDED that the lwB4 implements mechanisms to prevent against tiny fragment attacks and buffer memory exhaustion. Section 3.4 of [RFC6146] describes potential mitigations for these attacks which could be adapted for use here. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
