Subject: RE: [NSIS] RE: nsis mobility interactions

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 30 Oct 2002 12:44:25 -0000

hi,

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: 30 October 2002 12:19
> To: Hancock, Robert; 'Sarantis Paskalis'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [NSIS] RE: nsis mobility interactions
> 
> 
> hi robert
> 
> the mobile ipv6 address ownership problem (establishing 
> end-to-end security
> associations between two arbitrary hosts) is independent from 
> the session
> ownership issues in nsis. i think that an nsis protocol does not care
> whether it has to install/update a flow identitifer with a 
> care-of address
> or something different (home address, flow label).

quite right. in other words:
*) mobile ip only protects ownership at the endpoints;
*) nsis doesn't care what the identifiers are.
so, to have my packets benefit from the reservation (qos treatment, f/w pinhole, etc) that another [mobile] user has set up, all i need to to is incorporate their HA options in my packet header and ignore them at the endpoints. is that a good idea?

(IIRC, the HA options don't otherwise affect packet treatment within the network, so the sort of return routability checking that MIP uses to protect the endpoints can't be applied. but i'd defer to a MIP expert on this.)

> 
> the performance aspect is worth a consideration. however, i 
> do not have
> performance numbers. does someone else know something?

i think you would even struggle to find a classifier prepared to recognise the option fields (certainly a hardware one).

> 
> ciao
> hannes
> 
> 
> > -----Original Message-----
> > From: Hancock, Robert [mailto:[email-masked]]
> > Sent: Wednesday, October 30, 2002 12:15 PM
> > To: 'Sarantis Paskalis'; Hannes Tschofenig
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [NSIS] RE: nsis mobility interactions
> >
> >
> > hi all,
> >
> > will someone explain to me how the security (validation of HA
> > ownership in the network interior) and performance (required
> > complexity of packet classifier) issues with this approach would
> > be addressed? (no pun intended.)
> >
> > robert h.
> >
> > > -----Original Message-----
> > > From: Sarantis Paskalis [mailto:[email-masked]]
> > > Sent: 30 October 2002 11:01
> > > To: Hannes Tschofenig
> > > Cc: [email-masked]; Hancock, Robert; [email-masked]
> > > Subject: Re: [NSIS] RE: nsis mobility interactions
> > >
> > >
> > > Hi all,
> > >
> > > On Wed, Oct 30, 2002 at 08:57:56AM +0100, Hannes Tschofenig wrote:
> > > > i saw that "draft-ietf-ipv6-flow-label-03.txt" recommends
> > > classification
> > > > based on triplet (src adr, dest adr, flow label). in case
> > > of mobility it
> > > > would be much better to use the home address instead of the
> > > source address.
> > > > with a source address as part of the classifier all nodes
> > > along the path
> > > > require an update after the src address changed due to mobility.
> > >
> > > Or better Home Addresses, since both the source and the
> > > destination may
> > > be mobile nodes.  Home Addresses remain constant at least 
> throughout a
> > > session, so they can be used to identify the same flow.
> > >
> > > -- Sarantis
> > >
> >
> >
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 30 Oct 2002 14:59:42 +0100

hi robert.

> *) nsis doesn't care what the identifiers are.

sounds ok to me. but to avoid confusion, nsis cares about identifiers but
should not care about what particular identifier is used.
for example: if you do not use mip then obviously it would not be a good
idea to have nsis only to support a home address based identifier.

> so, to have my packets benefit from the reservation (qos
> treatment, f/w pinhole, etc) that another [mobile] user has set
> up, all i need to to is incorporate their HA options in my packet
> header and ignore them at the endpoints. is that a good idea?
unfortunately this is true. this threat is also described in the threat
document.
if you would have an identifier which is independent of addresses then there
would be a clear advantage from a mobility perspective but unfortunately a
security "disadvantage".

>
> (IIRC, the HA options don't otherwise affect packet treatment
> within the network, so the sort of return routability checking
> that MIP uses to protect the endpoints can't be applied. but i'd
> defer to a MIP expert on this.)
true. it this does not seem to be possible or from a performance perspective
advisable.

the same is true for an spi:
an spi does not cause packet treatment within the network as well. still it
has to be used as a packet classfier for qos (if the ip traffic is ipsec
protected). only the end-points use the security association. verification
is done only at end points.

> i think you would even struggle to find a classifier prepared to
> recognise the option fields (certainly a hardware one).
true. there is certainly room for improvement.

ciao
hannes

---

From: Sarantis Paskalis <[email-masked]>
Date: Wed, 30 Oct 2002 16:40:03 +0200

Hi all,

On Wed, Oct 30, 2002 at 02:59:42PM +0100, Hannes Tschofenig wrote:

<snip confirmation about possible theft of service>

To summarize the thread, the following alternatives exist for the flow
identifier (in my understanding):

+ Use the Home Address option (or spi field or any other unique identifier)
  -Pros:  Supports mobility (change of endpoint IP address)
  -Cons:  Possible theft of service (the authentication of the HA or spi 
          happens only at the endpoints), suboptimal classifying performance

+ Use src and dest addresses (combined with flow labels)
  -Pros:  Performance tuned, qos allocations are for the actual flow (no
          theft of service).
  -Cons:  The classification filter must change after a mobile IP handoff
          (end point address modification).  The filter modification must
          happen throughout the path, not only in the locally affected area.

Is there any other alternative?

-- Sarantis