Hi Vishwas, Hi *, Vishwas Manral <[EMAIL PROTECTED]> writes:
> Hi, > > Based on feedback from the group, we have written a draft for a new > routing header. The functionality is the same as the RH0. The draft > will soon be posted to the IETF site. > > The main differences are: > > 1. Maximum up to 4 addresses in the header. (the number is based on > the reply I got for the question about the usage scenarios in operator > environments). > 2. Only one header in each packet. > 3. Firewall policy reccomendation. > 4. RPF reccomendation. > > Please have a look and let us know your comments. 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. 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. > 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. > 4. Security Considerations > > The purpose of this document is to add a new type of Routing extension > header of IPv6. RH0 has been shown to have undesirable security > implications. > > Many of the attacks including the amplification attack cannot occur with > the RH4 header. All the addresses in the RH4 header need to be checked with > the firewall policy to make sure the firewall is able to trap packets meant > for addresses in the firewall policy and take relevent action. > > Whereever possible, including the administrative network edge, RPF check > needs to be done. "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 ? "Whereever possible, ...": this is a common statement. What's the precise purpose? What if it is not done (i.e. impact in that case)? 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. A general question I have on the topic is the following: is the ability to "bypass" anycast routing scheme considered a problem or is it ok? I'd like to hear on that point from people that use that kind of setup for protection against DoS in large scale deployment (DNS servers, 6to4 relay routers, ...). Regards, a+ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
