Apart from reserving the right to touch up the English, I have no trouble with Pekka's proposed additions.
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. Thanks Brian 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 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
