Oy, Le 10 mai 07 à 09:00, Pekka Savola a écrit : > In order to kickstart some discussion, here are two comments:
Good idea. > 3. Implementation > > Compliant IPv6 hosts and routers MUST NOT transmit IPv6 datagrams > containing RH0. > > ==> does 'transmit' include both 'originate' and 'forward' or just the > former? I hope it is 'originate' (resulting from processing of a routing header addressed to the router). > I'd be interested in seeing comments from router vendors on the > feasibility of the blocking forwarding for type 0 routing headers (but > not other types). Me too, but just for fun. This would imply possible processing of the whole extension headers chain. Even if it was possible from a performance standpoint, does anyone want that kind of filtering in the core ? > Would that include packets where the routing header wouldn't be the > immediate next-header (e.g., you'd put a hop-by-hop header or > something like that first, only then routing headers)? That's even > more difficult as the implementation would need to skip through all of > them, possibly with a 'lookup depth' of the maximum packet size. > > AFAIK, usually the amount of bytes of the header available to ACLs is > limited, unless you punt the whole packet to the control processor > which is probably a treatment worse than the disease. And this goes against one of the aim of IPv6 : limiting the work performed by routers. The sentence could be modified in : "Compliant IPv6 hosts and routers MUST NOT process RH0 in packets addressed to them. Those packets MUST be dropped without further processing. In particular, the value of the Segments Left field MUST not be considered." Some comments on that : - This prevents routers and host to automatically process packets with RH0 and forward traffic to another waypoints. - This prevents blindly source-routed packets to be processed by the final destination (null value for Segments Left field), i.e. this prevents an attacker to target an instance of a service after having escaped the natural path (DMZ concern, Anycast service). - This part is an obvious update to Section 4.4 of RFC 2460: IMHO, final destination should only accept source-routed traffic when the associated RH type is configured, activated and guarantied to have no impact. The sentence is in sync with MIPv6. - This also prevents the packet to be "locally" forwarded, between the addresses of the host/router. - IMHO, emission of ICMPv6 message should not be done (this is implicit in the 'no further processing'). This could be added in an explicit fashion at the end of the paragraph, if unclear. RH0 being deprecated in the context of the draft, I think it's fair that this kind of traffic is not worth a reply. Comments welcome ! > 4. Operations > > Compliant IPv6 hosts and routers which receive IPv6 datagrams > containing RH0 MUST silently discard those datagrams without > further processing. > > ==> is this really 'Operations' or is it really implementation? I.e., > are you requiring the network or host operators to do something or the > implementations? "receive" is unclear, like "transmit" in previous section. I think what is implied here is covered by my previous proposal. 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 --------------------------------------------------------------------
