RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt

> >> Hmm sorry for being unclear, the technical part looked okay as far as > >> I could tell, but as the quoted words from you, it will probably be > >> more confusing to have two documents where the last one update/change > >> the first one. Would be much better to have just one > >> replacing/upd

Fragment ID generation and Flow Label generation (was: Re: Fragmentation-related security issues)

On 01/27/2012 06:08 PM, Philip Homburg wrote: >>> So any system that is too busy to keep destination cache entries for a long >>> time will effectively send fragments with a random number. >> >> There are always tradeoffs in the IP-ID generation algorithms. If you >> don't like any of the forementi

Re: Fragmentation-related security issues

In your letter dated Fri, 27 Jan 2012 16:18:28 -0300 you wrote: >Hi, Philip, > >On 01/27/2012 02:36 PM, Philip Homburg wrote: >>> (For IPv6, I suggest that you talk with davem@, which noted that we >>> would not even want such a scheme for the IPv6 (i.e., 32-bit long) >>> fragment ID). >> >> For a

Re: Fragmentation-related security issues

Hi, Philip, On 01/27/2012 02:36 PM, Philip Homburg wrote: >> (For IPv6, I suggest that you talk with davem@, which noted that we >> would not even want such a scheme for the IPv6 (i.e., 32-bit long) >> fragment ID). > > For avoiding collissions, a single global counter is optimal. To avoid traffi

Re: Fragmentation-related security issues

In your letter dated Fri, 27 Jan 2012 13:19:24 -0300 you wrote: >On 01/27/2012 08:13 AM, Philip Homburg wrote: >> Given the current trends, just a random number would be good enough. But the >> old RFCs assumed that a sequence number was used to maintain uniqueness. > >May I ask what the "current t

Re: Fragmentation-related security issues

On 01/27/2012 08:13 AM, Philip Homburg wrote: > Given the current trends, just a random number would be good enough. But the > old RFCs assumed that a sequence number was used to maintain uniqueness. May I ask what the "current trends" are? And no, just a random number is not good enough, particul

Re: Fragmentation-related security issues

Florian, On 01/27/2012 09:14 AM, Florian Weimer wrote: >> On 01/27/2012 08:36 AM, Florian Weimer wrote: >>> And I see no functional difference between the gateway and the host >>> generating the fragment ID, except that the latter approach seems to >>> require network-wide software updates current

Re: Reassembly of atomic fragments (was: Re: Consensus call on adopting: draft-gont-6man-ipv6-atomic-fragments)

Thanks. It is clear now. .as On 26 Jan 2012, at 12:00, Fernando Gont wrote: > [Subject changed so that this doesn't "mix" with the poll] > > Hi, Arturo, > > On 01/26/2012 09:59 AM, Arturo Servin wrote: >> When you say "Namely, they try to perform IPv6 reassembly with the >> "atomic fr

Re: Fragmentation-related security issues

* Philip Homburg: > In your letter dated Fri, 27 Jan 2012 09:01:46 -0300 you wrote: >>In any, please note the difference between *accepting* atomic fragments, >>generating ICMPv6 PTB when the MTU of the constricting link is < 1280, >>and reacting to ICMPv6 PTB by generating atomic fragments. > > M

Re: Fragmentation-related security issues

In your letter dated Fri, 27 Jan 2012 09:01:46 -0300 you wrote: >In any, please note the difference between *accepting* atomic fragments, >generating ICMPv6 PTB when the MTU of the constricting link is < 1280, >and reacting to ICMPv6 PTB by generating atomic fragments. My strong preference would b

Re: Fragmentation-related security issues

* Fernando Gont: > On 01/27/2012 08:36 AM, Florian Weimer wrote: >> And I see no functional difference between the gateway and the host >> generating the fragment ID, except that the latter approach seems to >> require network-wide software updates currently. > > Namely, are you saying that Linux

Re: New revision of draft-gont-6man-flowlabel-security

On 01/27/2012 07:49 AM, Florian Weimer wrote: >> I have just posted a revision of the aforementioned I-D. It is available >> at: >> >> Any comments will be appreciated. > > Destination-specific counters introduce state keeping re

Re: Fragmentation-related security issues

On 01/27/2012 08:36 AM, Florian Weimer wrote: > And I see no functional difference between the gateway and the host > generating the fragment ID, except that the latter approach seems to > require network-wide software updates currently. Namely, are you saying that Linux won't react to an ICMPv6 P

Re: Fragmentation-related security issues

* Philip Homburg: >>This is contrary to the IPv6 design because the network is not supposed >>to fragment. > > The original use case was slightly different. It was about IPv6/IPv4 > translators. The translator tries to forward an IPv6 packet or fragment over > IPv4 where it requires fragmentatio

Re: Fragmentation-related security issues

In your letter dated Fri, 27 Jan 2012 10:27:06 + you wrote: >I'm still extremely bothered by atomic fragments. Their use case seems >to be something like this: > > (1) A router receives a sufficiently large IPv6 packet for a > destination which lies behind a link with a sub-1280 MTU. > >

Re: New revision of draft-gont-6man-flowlabel-security

* Fernando Gont: > I have just posted a revision of the aforementioned I-D. It is available > at: > > Any comments will be appreciated. Destination-specific counters introduce state keeping requirements and concurrency bottlenec

Re: Fragmentation-related security issues

* Florian Weimer: > Actually, atomic fragments aren't the problem, but the technology that > serves as a justification for them. [...] This argument turns out to be entirely wrong. Sorry about that. I'm still extremely bothered by atomic fragments. Their use case seems to be something like thi