Pekka, Echoing Brian's message, I am comfortable with the authors working on fitting in the draft, after some wordsmithing, the text that you have proposed for the Security Section.
Regards, Alex Brian E Carpenter wrote: > > Oh, OK. Wordsmithing I can manage! > > I doubt if we can do any more on this before the IETF. I only have 15 hours > before I must be on a train to the airport, and 14.9 of them are reserved. > > Brian > > Pekka Savola wrote: > > > > 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] > --------------------------------------------------------------------
smime.p7s
Description: S/MIME Cryptographic Signature
