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

From: [email-masked]
Date: Tue, 29 Oct 2002 16:06:44 -0500

Hi:

The "draft-ietf-ipv6-flow-label-03.txt" recommends classification based on triplet (src adr, dest adr, flow label). We should not deviate from it unless it is essential.

Also, what are those interesting implications on host implementations that you were referring to?

Hemant  

-----Original Message-----
From: ext Hancock, Robert [mailto:[email-masked]]
Sent: Sunday, October 27, 2002 6:35 PM
To: PIECHOCINSKI, MACIEJ; [email-masked]
Subject: [NSIS] RE: nsis mobility interactions

hi all,

i discussed these issues with Charles (Shen) at Yokohama. He (& colleagues) have produced newer drafts:
draft-shen-nsis-rsvp-mobileipv6-00.txt
draft-shen-nsis-mobility-fw-00.txt
which I think change some of the previous conclusions or at least emphasis.

since this is now effectively a framework discussion, i can recommend the second of these, as well as (I hope) section 5.3 of draft-ietf-nsis-fw-00.txt.

with the momentum behind the discussion, i'd like to highlight some of the more general questions:
*) can we agree the assumption that flow identification should be based on 'normal' header fields (i.e. not the HA e.g. in HAO). Note: this has some interesting implications for host implementations.
*) is the HA a suitable value to use as the basis of a reservation identifier (basically, does the way it gets secured provide sufficient protection from the point of view of devices which aren't the MN & CN)?
*) should we restrict the scope of NSIS considerations to MIP, or consider other mobility scenarios (e.g. SIP-based mobility solutions, or stuff as in draft-westberg-rmd-cellular-issues-01.txt) - where there wouldn't be a constant HA anyway?
*) actually, what are the re-authentication/re-authorisation requirements in such mobility scenarios? how much authority can be devolved to the interior nodes in the network?

plenty of others, of course...

cheers,

robert h.

> -----Original Message-----
> From: PIECHOCINSKI, MACIEJ [mailto:[email-masked]]
> Sent: 25 October 2002 18:33
> To: [email-masked]
> Subject: Re: nsis mobility interactions (was: RE: [NSIS] Some 
> commentson
> draft-ietf-nsis-req-04.txt)
> 
> 
> draft-shen-rsvp-mobileipv6-interop-00.txt addressed some of the issues
> with RSVP & MIP:
> -using Home Address as a constant flow/reservation identification
> -localizing reservation updates
> -explicit teardown of old path after handoff
> 
> Maciej
> 
> Bob Braden wrote:
> > 
> >   *>
> >   *> Whenever i think about this, i have to admit i get 
> confused. (One of
> >   *> the reasons i like the thomas seamoby draft is the 
> abstract, which
> >   *> starts "IP Mobility along with RSVP makes my head hurt".)
> >   *>
> >   *> But in the hard handover (break-before-make 
> situation), the sort of
> >   *> reasoning is:  *) if you send the tear before the 
> handover, you will
> >   *> lose the whole e2e path (can't find the crossover point without
> >   *> signaling via the new router); *) if you wait until 
> after the handover,
> >   *> you no longer have the ability to signal via the old 
> router and you
> >   *> can't tear the dead branch down.  So, what would be 
> nice is if you
> >   *> could send some message after the handover which had a 
> reference to the
> >   *> old reservation in a way which allowed the dead branch 
> to be removed.
> >   *> (NB this path tear problem is only one of the 
> problems, of course. the
> >   *> analysis documents contain several others.)
> > 
> > Robert,
> > 
> > OK, you win, now my head hurts too ;-)  The problem, I 
> guess, is that
> > mobile IP breaks the Internet architecture in a fundamental 
> way, so to
> > understand how QoS signaling will work you have to look at 
> the details
> > of how mobile IP works.  That's just philosophy, but it does suggest
> > that we need to put the bandage where the wound is -- we probably
> > need a solution that is local to the mobile region, not E2E.
> > 
> > Bob
> > 
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
_______________________________________________
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 08:57:56 +0100

hi hemant!

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.

ciao
hannes

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Tuesday, October 29, 2002 10:07 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [NSIS] RE: nsis mobility interactions
>
>
> Hi:
>
> The "draft-ietf-ipv6-flow-label-03.txt" recommends classification
> based on triplet (src adr, dest adr, flow label). We should not
> deviate from it unless it is essential.
>
> Also, what are those interesting implications on host
> implementations that you were referring to?
>
> Hemant
>
> since this is now effectively a framework discussion, i can
> recommend the second of these, as well as (I hope) section 5.3 of
> draft-ietf-nsis-fw-00.txt.
>
> *) can we agree the assumption that flow identification should be
> based on 'normal' header fields (i.e. not the HA e.g. in HAO).
> Note: this has some interesting implications for host implementations.
> *) is the HA a suitable value to use as the basis of a
> reservation identifier (basically, does the way it gets secured
> provide sufficient protection from the point of view of devices
> which aren't the MN & CN)?
> *) should we restrict the scope of NSIS considerations to MIP, or
> consider other mobility scenarios (e.g. SIP-based mobility
> solutions, or stuff as in
> draft-westberg-rmd-cellular-issues-01.txt) - where there wouldn't
> be a constant HA anyway?
> *) actually, what are the re-authentication/re-authorisation
> requirements in such mobility scenarios? how much authority can
> be devolved to the interior nodes in the network?
>

---

From: Sarantis Paskalis <[email-masked]>
Date: Wed, 30 Oct 2002 13:01:17 +0200

Hi all,

> 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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Oct 2002 08:08:25 -0800 (PST)

> require an update after the src address changed due to mobility.

   This is not at all clear. Fishing out the home address
   option for flow classification is onerous. Nor is it
   always available as it could be invisible due to 
   encryption. I'm not offering a solution here, just
   pointing out that this is not obvious.

		Mike

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 30 Oct 2002 17:50:53 +0100

hi mike!

>    This is not at all clear.

there are two cases for flow classification and mobility (in this context):
a) home address is not used for flow classification

if you roam and obtain a new care-of address then your new packets leaving
your host do not receive qos treatment because
- you have no reservation from your host to the cross-over router
- your installed flow classifiers contain the wrong addresses (i.e. old
care-of address - not the new one)

you have to make a new reservation from up to the cross-over router.
unfortunately you cannot stop there since the rest of the nodes along the
path still need a flow classifier update (old coa -> new coa).

b) home address is used

packet classification is established for your home address.

a new reservation needs to be created along the path up to the cross-over
router. the flow classifier for the path after the cross-over router might
already contain the home address and does not require an update.

what do you think?

i am not proposing that one should change the definition of the flow label.
my intention was only to point to some issues. the flow label might be for
example useful as a replacement of the 5-tuple.

> Fishing out the home address
>    option for flow classification is onerous.

that might be true. however, there are however some implications if you do
not use it.
it would be great if someone could provide performance figures (performance
penalty compared to other flow identifiers)

> Nor is it
>    encryption.
this is always true. if you have tunnels somewhere along the path,
end-to-end ipsec, nested ipsec tunnels then your flow classification has to
respect it.

> I'm not offering a solution here, just
thanks for pointing to it. there are definitely some issued which deserve
further consideration.

ciao
hannes