Hi Fernando, Thanks for reading through the draft. > I had a quick look at your document. Here are some quick and dirty comments: > > * Your documents talk about specifying a minimum size for non-last > fragments. Actually, I think one should be concerned only about the *first* > fragment. That's the one that's used to create state at firewalls, etc. This is the more liberal approach you adopt to achieve the same thing. by having a more conservative approach we reduce the attack vectors further.
> * I don't think imposing such a requirement will, by itself, help to ensure > that you have in the first packet all the information you need to apply > firewalls rules. It would be trivial for an attacker to comply with such a > requirement, but still do not provide all the relevant information that > would be needed by the firewall to apply its rules. The attacker could just > add one or several extension headers, with lots of PadN options. Thus, it > would comply with your requirement, but still avoid sending e.g. the TCP > source and destination ports. Fernando, that is correct. However we intend to put limitations separately on that. Suresh probably had a draft regarding the same. Thanks, Vishwas On Mon, Jun 23, 2008 at 1:18 PM, Fernando Gont <[EMAIL PROTECTED]> wrote: > At 08:22 a.m. 22/06/2008, Vishwas Manral wrote: > >> Though this may not be exactly what you are looking for, you may want >> to look at some of the issues we identified a long while back with >> IPv6 Tiny Fragments. >> >> http://tools.ietf.org/html/draft-manral-v6ops-tiny-fragments-issues-02 > > I had a quick look at your document. Here are some quick and dirty comments: > > * Your documents talk about specifying a minimum size for non-last > fragments. Actually, I think one should be concerned only about the *first* > fragment. That's the one that's used to create state at firewalls, etc. > > * I don't think imposing such a requirement will, by itself, help to ensure > that you have in the first packet all the information you need to apply > firewalls rules. It would be trivial for an attacker to comply with such a > requirement, but still do not provide all the relevant information that > would be needed by the firewall to apply its rules. The attacker could just > add one or several extension headers, with lots of PadN options. Thus, it > would comply with your requirement, but still avoid sending e.g. the TCP > source and destination ports. > > Kind regards, > > -- > Fernando Gont > e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED] > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
