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]
--------------------------------------------------------------------

Reply via email to