All,
The latest version of this document addresses all comments
received during the last call. Unless there is an objection, I will
begin the advancement of this draft to the IESG.
Regards,
Brian
Brian Haberman wrote:
All,
This message starts a 2-week 6MAN Working Group Last Call
Hi Thomas,
On 28/05/09 04:06 PM, Thomas Narten wrote:
Except now it can be read to apply to devices that shouldn't be
required to do this, i.e., those that are not attempting to reassemble
anything...
How about something like:
When reassembling an IPv6 datagram, if one or more its
On May 27, 2009, Suresh Krishnan wrote:
Firewalls may or may not reassemble fragments, and I am not sure
what to
put in here. If you can suggest some text to put in this paragraph, I
will be glad to add it to the document.
Suresh -
My suggestion is not about fragment reassembly in
Hi Chritian,
The draft already contains the below:
IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT
create overlapping fragments. IPv6 nodes that receive a fragment
that overlaps with a previously received fragment MUST cease the
reassembly process and MUST
On May 28, 2009, Vishwas Manral wrote:
The draft already contains the below:
IPv6 nodes transmitting datagrams that need to be fragmented MUST
NOT
create overlapping fragments. IPv6 nodes that receive a fragment
that overlaps with a previously received fragment MUST cease the
Hi Christian,
Ok. I think to make it more generic we can call it a middlebox instead
of a firewall alone.
The text could be :
IPv6 nodes or middleboxes that receive a fragment that overlaps with
a previously received fragment MUST cease the reassembly process and
MUST discard the previously
Looks very good, Vishwas.
You may consider softening this from a MUST to a SHOULD, though,
given that hosts are at this stage not guaranteed to always produce
non-overlapping fragments.
- Christian
On May 28, 2009, Vishwas Manral wrote:
Hi Christian,
Ok. I think to make it more generic we
Vishwas Manral vishwas.i...@gmail.com writes:
Hi Christian,
Ok. I think to make it more generic we can call it a middlebox instead
of a firewall alone.
The text could be :
IPv6 nodes or middleboxes that receive a fragment that overlaps with
a previously received fragment MUST cease the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
Thomas Narten wrote:
How about something like:
When reassembling an IPv6 datagram, if one or more its constituent
fragments is determined to be an overlapping fragment, the entire
datagram (and any constituent fragments --
Hi Christian,
On 26/05/09 01:40 PM, Christian Vogt wrote:
Yes, the document should contain more explicit guidance for firewall
builders on how the document affects their products. Given the apparent
absence of overlapping fragment for legitimate traffic, it would be
safe, and even recommended,
Hi Suresh,
Sounds good to me.
Thanks,
Vishwas
On Wed, May 27, 2009 at 3:45 PM, Suresh Krishnan
suresh.krish...@ericsson.com wrote:
Hi Vishwas,
Thanks for your comments. Please find responses inline.
On 26/05/09 12:09 PM, Vishwas Manral wrote:
Hi,
The document version now is 02 and not
Hi,
The document version now is 02 and not 01. I support the document.
That said I think the below could be clarified further about what
needs to be done to the current fragment (it does talk about all
previous fragments):
IPv6 nodes that receive a fragment
that overlaps with a previously
Suresh -
As far as I know, there are no legitimate applications for overlapping
fragments (please send in a note if you see any). I am not aware of
any
stack that generates these either under normal conditions either.
In addition, there doesn't seem to be a reason, other than malicious,
Hi Arnaud,
Thanks for your comments. Please find responses inline.
On 20/05/09 03:31 PM, Arnaud Ebalard wrote:
The TCP header has the following values of the flags S(YN)=1 and
A(CK)=1. This makes an inspecting stateful firewall think that it is
I would say This may make. If the
Hi Christian,
Thanks for your comments. Please find responses inline.
On 22/05/09 08:30 PM, Christian Vogt wrote:
Suresh and all -
I have read the document and support it being progressed as a Proposed
Standard. The document identifies a security vulnerability that ought
to be mitigated,
Suresh and all -
I have read the document and support it being progressed as a Proposed
Standard. The document identifies a security vulnerability that ought
to be mitigated, and this document is a necessary step in doing so.
One comment: Is there data on how common overlapping fragments are
All,
This Last Call concluded with exactly one public comment. We
cannot advance this document without support of the working group.
Please review this draft and state whether you support or disagree with
advancing it.
Regards,
Brian
Brian Haberman wrote:
All,
This message
Hi Remi,
Thanks you for catching this.
On 02/03/09 10:16 AM, Rémi Denis-Courmont wrote:
Overall, I think this document should go forward.
Great.
However, the recommendation part should perhaps be a bit more explicit. I
assume the recipient node should not trash packets with a matching
All,
This message starts a 2-week 6MAN Working Group Last Call on
advancing:
Title : Handling of overlapping IPv6 fragments
Author(s) : S. Krishnan
Filename : draft-ietf-6man-overlap-fragment-01.txt
Pages : 7
Date : 2008-11-4
as a
On Mon, 02 Mar 2009 09:32:33 -0500, Brian Haberman
br...@innovationslab.net wrote:
All,
This message starts a 2-week 6MAN Working Group Last Call on
advancing:
Title : Handling of overlapping IPv6 fragments
Author(s) : S. Krishnan
Filename :
20 matches
Mail list logo
