Hi Arnaud, > It seems the draft intends to update RFC 2460. Does it imply that RH4 > would be mandatory to implement in all IPv6 stacks? It's probably me but > I don't see the point in adding complexity to IPv6 stacks (_all_ > implementations shipped), especially when the functionality has already > been proven to have an almost null usefulness. Yes, the intent is to update RFC2460 and implies its a mandatory to implement functionality. I had thought the same too, but if you see a past thread, I did get use cases for the RH4 functionality.
> Below are commented quotes from the draft : > > > The RH4 header has format and functionality similar to the RH0 header > > without having the major vulnerabilities of the "Routing Header". > > Efforts to get a new RH type defined will certainly require more than > having only major vulnerabilities removed compared to RH0. Having _all_ > vulnerabilities mitigated would be more respectful of past discussions > regarding RH0 and time already spent on it. I agree. Well in my view, we have to see what is practically possible, and can be done without overloading the router CPU. We intend to go as far as we can with this. In my view this is the initial version of the draft and we do intend to update the draft as we move forward. > > A Routing header is not examined or processed until it reaches the > > node identified in the Destination Address field of the IPv6 header. > > There can be at most one RH4 header in any packet. A packet with more > > than one RH4 header is discarded. This functionality can be > > implemented in a firewall or any other IPv6 node. > > First part of that paragraph states that packets are not checked > en-route but the second part states the opposite (you clearly need to > examine the RH to get the type). The sentence "A packet ... is > discarded" is to vague. Next sentence too. I guess the point I am trying to make is the algorithm given below should only be implemented by the destination node, however the discarding of malicious packets can be done by a firewall. I will clarify the text for the same. > > "Many of the attacks ... ": unlike in the IPv6 specification, the > security assessment of the mechanism (threats, impacts, mitigation) > should be done to describe what remains. > > "All the addresses need ...": what does it mean precisely ? I mean the IPv6 addresses included in the routing header - RH4. > "Whereever possible, ...": this is a common statement. What's the > precise purpose? What if it is not done (i.e. impact in that case)? Well the idea is RPF check cannot be done, in all scenarios. The simple case is that routing over the internet is asymmetric, and RPF checks cannot be applied. However such checks can be made at the edge of the networks. > After a first reading of the draft, my main feeling is that the > functionality is not precisely defined because the intended use is not > clearly stated: the purpose does not seem to be the addition of something > which would serve some categories of users. It's more oriented towards > the limited reduction of the level of threat associated with RH0 in > order to make it "acceptable". It's adding complexity without > considering the real need (if any). > > The problem of the processing (by nodes, routers, both, default policy) > is not clearly covered. This was a problem in 2460. Who should implement > that? Will your IPv6-enabled Mobile phone have that "feature"? > > Ability to source-route a packet is basically the ability to "coerce" a > remote node to send traffic towards a specific destination. In MIPv6, > final destination in RH2 (HoA) is always locally available on the > targeted node (the one the packet is sent to using the CoA). And before > a node even sends traffic to a CoA, the proof of ownership of the > address by the peer has always been made, i.e. to be able to have > someone follow you in that direction, you have to prove your ownership > of the targeted address, which is precisely your ability to _both_ > receive/emit traffic at/from that address. > > Having intermediate waypoints (i.e. 4 addresses) while keeping the same > level of protection as the one provided by RH2 for the Internet > infrastructure is IMHO not so easily feasible. > > IMHO, you should: > > - assess the real use of your new RH (context, scope, purpose) > - see the needs in term of checks, limitation, filtering > - define the mechanism based on generic RH > - check against all previously described threats (available in > reference documents) > - see what remains in terms of threats and impacts against the IPv6 > infrastructure and if it is worth the trouble. I agree. Infact if you see the mails from me on the list that is the direction I have taken. I have asked questions on what are real use scenarios for the same. I will update the draft based on comments from you. this draft is there to spur a discussion on the subject. Thanks a lot for your comments, Vishwas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
