Hi Brian, Apologies for the delay in responding. Snipping parts that I agree with.
On Apr 22, 2010, at 15:40 MDT, Brian E Carpenter wrote: <snip> > b) >> Declare that the flow-label is _mutable_ by each >> administrative domain. Therefore, I _MAY_ not trust an >> incoming IPv6 flow-label from another administrative domain. >> However, in thinking about this a bit more, this has problems >> of it's own, namely: a) the dependency of intermediate >> routers to (re)calculate a "good" flow-label based off the 3- >> or 5-tuple in the IPv6 header (possible, but not guaranteed); >> and, b) it could unintentionally overwrite "good" >> flow-labels, particularly those of inter-domain IP-in-IPv6 >> tunnels (cf: draft-carpenter-flow-ecmp), where the outer IPv6 >> header may have a "good" flow-label based on the inner IP >> header's 5-tuple -- which is bad. > > However, consider that the flow label is a forgeable field, not > protected by any checksum (including IPSEC). So you can't trust > it and an attacker could always attack your ECMP or LAG by > giving all packets the same label. It may be that the only safe > way is to recalculate the label at a trusted border. (Good luck > doing that at 100 Gb/s.) > > So maybe mutability is in fact the only way to make it safe to > use across domain boundaries? That seems like a reasonable conclusion. Given the packet inspection capabilities on most newer PE devices have to be pretty good, (in order to perform the usual classification on, say, the 5-tuple to either forward/drop the packet for security reasons or to set/reset the IP Traffic Class field), it doesn't seem too unreasonable to expect them to (re-)calculate a flow-label as a packet enters a domain. Although, in the one case of Inter-Domain IP-in-IPv6 encapsulation it /might/ be challenging in the near term for intermediate routers, at a border entrance, to grab enough of the inner L4 + L3 headers + outer packet headers to form a 'decent' outer header flow-label. Regardless, this doesn't [currently] comprise a substantial portion of the Inter-Domain traffic to be of short-term concern. In addition, the end-result of this work should bring awareness of the issue of tunneled packets to SP's and equipment vendors so that, eventually, equipment can support it properly, which is the best we can do. Finally, to ameliorate some of the concerns of having PE's (a.k.a. intermediate routers), with high-speed interfaces, identify "flows" as packets enter the domain, it would be beneficial to have [much] simpler IPv6 Extension Headers, as James Woodyatt mentioned a couple of weeks ago in a different thread on this list: http://www.ietf.org/mail-archive/web/ipv6/current/msg11566.html ... thus, I would support that effort, as well, given the benefits to not only application writers, but also intermediate routers, middleboxes, etc. (eventually). Of course, work on draft-krishnan can proceed in parallel and there shouldn't be any contingency on moving the flow-label work forward. (If anything, the flow-label work can help make a better case for draft-krishnan). -shane -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
