On Fri, 14 Mar 2003, Brian E Carpenter wrote: > But what more is needed about ingress filtering? That seems > to me to be a generic issue, with very little specificity > to flow label attacks.
What I meant is that there is some overlap with the text and some wordsmithing might be useful. No new text is needed, AFAICS. > Pekka Savola wrote: > > > > Hello, > > > > Following up from the last call and the issues I raised, I'll try to > > propose something to start with to make the security considerations more > > in line with certain imporant issues. > > > > Note: I'm assuming that the sentence: > > > > A source node MUST ensure that it does not reuse Flow Label values it > > is currently using or has recently used when creating new flows. > > > > will be changed, at least to "unintentionally reuse". > > > > Now, to the security considerations. > > > > 5.1 Theft and Denial of Service > > > > The goal of the Flow Label is to allow different levels of service to > > be provided for traffic streams on a common network infrastructure. A > > variety of techniques may be used to achieve this, but the end result > > will be that some packets receive different (e.g., better or worse) > > service than others. The mapping of network traffic to the flow- > > specific treatment is triggered by the IP addresses and Flow Label > > value of the IPv6 header, and hence an adversary may be able to > > obtain better service by modifying the IPv6 header or by injecting > > packets with false addresses and labels. Taken to its limits, such > > ^^^ > > > > ==> false addresses _or_ labels. > > > > theft-of-service becomes a denial-of-service attack when the modified > > or injected traffic depletes the resources available to forward it > > and other traffic streams. > > > > ==> after this, add a new paragraph: > > > > Note that there is no guarantee that flow labels used in a node are > > not used in any manner the node wants to, even reusing flow labels. > > This is a feature: as nodes are typically untrusted, it cannot be > > assumed that they would in fact implement or adhere to any restrictions > > if such would be set -- and therefore any assumptions made by the > > network on nodes' behaviour should be very limited except in > > cases where the nodes are explicitly trusted. > > > > ==> and after the "Since flows.." paragraph, add paragraphs: > > > > There are two issues with different properties: > > spoofing of only Flow Label, and spoofing of the whole 3-tuple, > > including Source and Destination Address. > > > > The former can be done inside a node which is using the correct source > > address. Being able to spoof Flow Label typically requires being in > > position to also forge an address -- but in many cases, spoofing the > > address may not be the interesting, especially if the spoofer's goal > > is theft of service, not denial of service. > > > > The latter can be done by a host which is not subject to ingress > > filtering [INGR] or an intermediate router. Due to its properties, > > such is typically useful only for denial of service. > > > > ==> TODO: consider whether changes are needed (on ingress filtering) in > > the second-last paragraph. > > > > Perhaps this should get one started. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
