Hello, Le 29 mai 07 à 17:08, JINMEI Tatuya / 神明達哉 a écrit :
> At Mon, 28 May 2007 17:03:47 -0400, > Joe Abley <[EMAIL PROTECTED]> wrote: > >> I have made some edits. Note that I am hoping to reach consensus on >> the changes to -00 which will produce -01 so that once -01 is >> submitted, it is ready for working group last call. First, typos : second paragraph of section 5 : "summarised" instead of "summarized" second paragraph of subsection 5.2 : "relating" should be replaced by "related"? Second, content (on Jinmei's comments): > IPv6 implementations are no longer required to implement RH0 in any > way. > > I don't understand why we bother to say this. Isn't it enough to > state "IPv6 nodes MUST NOT originate IPv6 packets containing RH0."? AFAIC, better explicit than implicit. Furthermore, it does not cost anything. > I also pointed out the following sentence could be still ambiguous: > > IPv6 nodes MUST NOT process RH0 in packets addressed to them. > > I suggest modifying this sentence to: > > IPv6 nodes MUST NOT process RH0 in packets whose destination address > in the IPv6 header is an address assigned to them. I agree on that one. Again, better explicit than implicit. > - section 5 > > IMO, this section contains too many details that are not directly > related to the deprecation action, make the document unfocused, and > could even make it misleading (even though I respect authors' effort > of writing up the summary). I suggest we take more focused approach > as this version took for the abstract and introduction. I > specifically propose the following revised text for a replacement of > the entire section (+ subsections): > > ========================= from here ========================= > [ ... good text ...] > ========================== to here ========================== IMHO, keeping the document shorter and in sync with its goal (deprecation) is better. Having another _longer_ document with technical considerations on source routing (LSRR, SSRR, RH0), history of things (IPv4/IPv6), threats and considerations for implementers would be better than providing half the information here. > If we adopt this proposal I'd not have to care about other details of > this section, but here are a couple of specific comments to the text > itself in case my proposal is rejected: > > - I think we should exclude the second paragraph of section 5.3 (about > the 'capacitive effect'). The effectiveness of this attack is not > so clear as the simple oscillation attack to me; the attacker would > have to control the timing of the packets (by either or both of the > transmission rate and the number of intermediate waypoints in RH0) > so that all the packets flow between the "capacitor" exit and the > target node at the same timing. As far as I know this attack is not > proved to be possible on real traffic unlike the simpler oscillation > and that's why the draft states it has been "postulated" rather than > "demonstrated". Describing the possibility of the attack is > interesting in a research paper, but IMO we should discuss things in > a normative protocol specification based on threats that are proved > to be possible. True. I just sent to Jinmei an explanation on the computation (PDF numeric version of a handwritten detailed figure). When we agree on the theoretical aspects, i'll make it a LaTeX document and put the PDF available somewhere. Probably this WE. > - the following part of the third paragraph of section 5.3 is not > really technically correct: > > The use of such tunnels can result in IPv6 paths which include a > small number of routers apparently connected by very high latency > circuits (tunnels). Such paths provide opportunities to keep > packets in- flight for longer, with corresponding increases in > amplification potential. > > Even though the cansecwest paper may indicate so, the circuit > latency is actually irrelevant to the amplification factor (I > discussed this with the authors and they admitted that). True. Slides have been modified just after CanSecWest with your comments (see history section). The latency only impact the "load", i.e. the amount of traffic stored on the path, not the factor of the amplification (the simulated number of people with the same bandwidth as you have) which is directly related with the number of waypoints in the RH0. > The only > relevant point in this context is that it may be possible to attack > a longer path more effectively because the two consecutive waypoints > may effectively contain multiple (IPv4) links and the IPv6 hoplimit > is decreased only by one between them. exactly. Cheers, a+ -- Arnaud Ebalard EADS Innovation Works - IT Sec Research Engineer PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
