RE: Next steps for draft-gont-6man-predictable-fragment-id

["Will Liu (Shucheng)" <[e-mail]>]

Firstly, I agree with Juan. Though this work proposed a mitigation to a known flaw,  the use of predictable fragment IDs, just as Tina said, such document can be really instructive to the IPv6 protocol implementation, especially when considering the longstanding slogan of IPv6, the security.

Secondly, if we look at the IPv4 history, the lack of similar work at this point results in the fragility of implementation and the possibility of generation fragment id by incorporating other flawed schemes. We should be enlightened to push forward such works, to avoid repeating the history of vulnerable IPv4.

In the end, a tiny comment: the author might consider to expand Appendix B to make this work more universal by including other implementations.

Regards,
Shucheng LIU (Will)

From: [e-mail] [mailto:[e-mail]] On Behalf Of Juan Antonio Matos
Sent: Friday, March 08, 2013 9:48 AM
To: [e-mail]
Subject: Re: Next steps for draft-gont-6man-predictable-fragment-id

Le 2013-02-28 20:51, Ole Troan a ?crit :
> - Is there interest in working on it in 6man?
>    (if yes, you must be willing to contribute, if no, then say why)

Yes,

Someone said: Why do a document for IPv6 for Things That Were Well Known in IPv4?

and i wonder:

Why not do it right in IPv6, even though we know it is a problem that has existed for IPv4?

IPv6 is a new protocol, and probably in a few years the new generation of internet professionals might hear about IPv4, as we hear today about IPX, (as History).

I understand that this is a known weakness, even so could affect some systems, so why not correct this?

I think this topic deserves further discussed

regards

Juan Antonio Matos
Dominican Civil Aviation Institute







   1. Re: 6MAN Agenda for IETF86 (Fernando Gont)
   2. Re: Next steps for draft-gont-6man-predictable-fragment-id
      (Simon Perreault)
   3. Re: Next steps for draft-gont-6man-predictable-fragment-id
      (Ole Troan)
   4. Re: Next steps for draft-gont-6man-predictable-fragment-id
      (Simon Perreault)
   5. Re: Next steps for draft-gont-6man-predictable-fragment-id
      (Fernando Gont)
   6. Re: Next steps for draft-gont-6man-predictable-fragment-id
      (Simon Perreault)
   7. Re: Next steps for draft-gont-6man-predictable-fragment-id
      (Ole Troan)


----------------------------------------------------------------------

Message: 1
Date: Thu, 07 Mar 2013 00:27:11 -0300
From: Fernando Gont <[e-mail]<mailto:[e-mail]>>
To: Bob Hinden <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: 6MAN Agenda for IETF86
Message-ID: <[e-mail]<mailto:[e-mail]>>
Content-Type: text/plain; charset=ISO-8859-1

Bob,

On 03/05/2013 07:42 PM, Bob Hinden wrote:
>
>> draft-gont-6man-ipv6-smurf-amplifier : 2 discussion on the list :
>> 15 mins
>
> This was the chairs call as we thought there would be interest in it.
> Given the discussion on the list, there appears to be more interest
> in <draft-liu-bonica-dhcpv6-slaac-problem-01.txt> and we propose to
> swap them.  There isn't time for everything.
>
> Comments?

I personally oppose to such idea. This is my reasoning:

* draft-gont-6man-ipv6-smurf-amplifier has already been in the position
of "this will be discussed if time permits" (and at the time, time
didn't permit). Hence it's time to allocate a slot to this I-D. The same
reasoning should apply to draft-liu-bonica-dhcpv6-slaac-problem-01.txt
for the next IETF meeting.

* draft-gont-6man-ipv6-smurf-amplifier is pretty much straight-forward
so that may be one reason for which you didn't see more discussion about
it. I'd expect that discussion during the 6man wg meeting will be brief,
and hence we'll be able to move forward to the next document even before
the allocated time is used.

* Changing agendas once published is, IMO, a bad idea (unless really
necessary).


FWIW, I should note that I do support
draft-liu-bonica-dhcpv6-slaac-problem-01.txt -- i.e., the reasoning
above doesn't have anything to do with the contents of
draft-liu-bonica-dhcpv6-slaac-problem-01.txt itself.

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: [e-mail]<mailto:[e-mail]>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492






------------------------------

Message: 2
Date: Thu, 07 Mar 2013 10:44:27 +0100
From: Simon Perreault <[e-mail]<mailto:[e-mail]>>
To: [e-mail]<mailto:[e-mail]>
Subject: Re: Next steps for draft-gont-6man-predictable-fragment-id
Message-ID: <[e-mail]<mailto:[e-mail]>>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Le 2013-02-28 20:51, Ole Troan a ?crit :
> - Is there interest in working on it in 6man?
>    (if yes, you must be willing to contribute, if no, then say why)

Yes.

I think the document is very useful. The fact that there are so many
popular implementations out there that get this kind of thing wrong
shows a need for good documentation. This draft explains the problem,
says clearly what needs to be done, and describes good and practical
algorithms. And there's a survey of current implementations as a bonus
in the appendix. This is exactly the kind of good quality information
that the IETF needs to provide.

Simon


------------------------------

Message: 3
Date: Thu, 7 Mar 2013 11:09:55 +0100
From: Ole Troan <[e-mail]<mailto:[e-mail]>>
To: Simon Perreault <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: Next steps for draft-gont-6man-predictable-fragment-id
Message-ID: <[e-mail]<mailto:[e-mail]>>
Content-Type: text/plain; charset=iso-8859-1

Simon,

>> - Is there interest in working on it in 6man?
>>   (if yes, you must be willing to contribute, if no, then say why)
>
> Yes.
>
> I think the document is very useful. The fact that there are so many popular implementations out there that get this kind of thing wrong shows a need for good documentation. This draft explains the problem, says clearly what needs to be done, and describes good and practical algorithms. And there's a survey of current implementations as a bonus in the appendix. This is exactly the kind of good quality information that the IETF needs to provide.

- are you willing to work on the document?
- do you think this should be done in 6man or elsewhere?

cheers,
Ole



------------------------------

Message: 4
Date: Thu, 07 Mar 2013 11:13:47 +0100
From: Simon Perreault <[e-mail]<mailto:[e-mail]>>
To: Ole Troan <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: Next steps for draft-gont-6man-predictable-fragment-id
Message-ID: <[e-mail]<mailto:[e-mail]>>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Le 2013-03-07 11:09, Ole Troan a ?crit :
> Simon,
>
>>> - Is there interest in working on it in 6man?
>>>    (if yes, you must be willing to contribute, if no, then say why)
>>
>> Yes.
>>
>> I think the document is very useful. The fact that there are so many popular implementations out there that get this kind of thing wrong shows a need for good documentation. This draft explains the problem, says clearly what needs to be done, and describes good and practical algorithms. And there's a survey of current implementations as a bonus in the appendix. This is exactly the kind of good quality information that the IETF needs to provide.
>
> - are you willing to work on the document?

Yes.

> - do you think this should be done in 6man or elsewhere?

6man

Simon


------------------------------

Message: 5
Date: Thu, 07 Mar 2013 07:28:24 -0300
From: Fernando Gont <[e-mail]<mailto:[e-mail]>>
To: Ole Troan <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: Next steps for draft-gont-6man-predictable-fragment-id
Message-ID: <[e-mail]<mailto:[e-mail]>>
Content-Type: text/plain; charset=ISO-8859-1

Ole,

On 03/07/2013 07:09 AM, Ole Troan wrote:
>
> - are you willing to work on the document?

I'm really curious about these questions.

What does "working on a document" mean? For instance, it's probably the
first time I see this question asked when polling the wg for support of
a document.



> - do you think this should be done in 6man or elsewhere?

That aside, this document aims to update RFC 2460. Where else should
that be done, if not in 6man??

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: [e-mail]<mailto:[e-mail]>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492






------------------------------

Message: 6
Date: Thu, 07 Mar 2013 11:44:08 +0100
From: Simon Perreault <[e-mail]<mailto:[e-mail]>>
To: Fernando Gont <[e-mail]<mailto:[e-mail]>>
Cc: Ole Troan <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]>
Subject: Re: Next steps for draft-gont-6man-predictable-fragment-id
Message-ID: <[e-mail]<mailto:[e-mail]>>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Le 2013-03-07 11:28, Fernando Gont a ?crit :
> What does "working on a document" mean? For instance, it's probably the
> first time I see this question asked when polling the wg for support of
> a document.

It's common. I understand it to mean reviewing the draft, providing
comments, etc.

> That aside, this document aims to update RFC 2460. Where else should
> that be done, if not in 6man??

That's a technicality. What's more important is that the relevant
expertise is in 6man.

Simon


------------------------------

Message: 7
Date: Thu, 7 Mar 2013 12:02:27 +0100
From: Ole Troan <[e-mail]<mailto:[e-mail]>>
To: Simon Perreault <[e-mail]<mailto:[e-mail]>>
Cc: Fernando Gont <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]>
Subject: Re: Next steps for draft-gont-6man-predictable-fragment-id
Message-ID: <[e-mail]<mailto:[e-mail]>>
Content-Type: text/plain; charset=iso-8859-1

Simon,

>> What does "working on a document" mean? For instance, it's probably the
>> first time I see this question asked when polling the wg for support of
>> a document.
>
> It's common. I understand it to mean reviewing the draft, providing comments, etc.

yes.

>> That aside, this document aims to update RFC 2460. Where else should
>> that be done, if not in 6man??
>
> That's a technicality. What's more important is that the relevant expertise is in 6man.

when this document was presented in 6man at IETF84, there were suggestions that a more generic
document could be written. e.g. in intarea.

I don't want us to end up with an RFC per field per protocol.

there isn't an equivalent document for IPv4, right?

there are other alternatives too, e.g. an errata to 2460, or an update to the nodes requirement document.

cheers,
Ole

------------------------------

_______________________________________________
ipv6 mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ipv6


End of ipv6 Digest, Vol 107, Issue 9
************************************