Subject: [NSIS] RE: nsis mobility interactions

From: "Hancock, Robert" <[email-masked]>
Date: Sun, 27 Oct 2002 23:35:23 -0000

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 29 Oct 2002 23:03:38 -0000

hi hemant,

see below:

> From: [email-masked] [mailto:[email-masked]]
> Sent: 29 October 2002 21:07
> To: Hancock, Robert; [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.

[reh] Broadly, I like the current flow label draft, having read it several times. However, I think it's specifically about the flow label scope issues, rather than trying to restrict possible flow classifiers. (Would we ban classifiers that included the DSCP, for example?) I'm certainly not in favour of using lots of higher layer fields, and I'd personally be happy for NSIS to restrict itself in this area.

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

[reh] This is based on conversations I have had with people who have implementation experience with MIP and RSVP. As I understand it (and I pre-emptively claim simple ignorance as a defence if I have got it wrong), an assumption that underlies several RSVP implementations is that the application on the host conveys its opinion on the packet classifier to some user space RSVP daemon which then uses them directly in RSVP protocol messages. (draft-shen-rsvp-mobileipv6-interop-00.txt described precisely this behaviour.) The filter spec in these messages then doesn't match MIP-processed packets.

So, what is needed instead is for the RSVP daemon to know *exactly* how user-space visible packets are going to be re-encapsulated as they go over virtual interfaces (MIP,IPsec,L2TP,...), which probably requires more knowledge of IP-layer internals than may be trivially available. The RSVP daemon can't just take the application's view of the flow identification, wrap it in some headers, and chuck it at the host IP stack.

OK, maybe it wasn't that interesting. But it seems worth keeping in mind. The framework alludes to these points (in 4.1 and 5.3.1, IIRC), but only briefly.

> Hemant  

cheers,

robert h.

> 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:
> 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?
> 
[snipped]

---

From: [email-masked]
Date: Wed, 30 Oct 2002 11:57:25 -0500

Hi Robert:

See below as [HMC]:

-----Original Message-----
From: ext Hancock, Robert [mailto:[email-masked]]
Sent: Tuesday, October 29, 2002 6:04 PM
To: Chaskar Hemant (NRC/Boston); [email-masked]
Subject: RE: [NSIS] RE: nsis mobility interactions

hi hemant,

So, what is needed instead is for the RSVP daemon to know *exactly* how user-space visible packets are going to be re-encapsulated as they go over virtual interfaces (MIP,IPsec,L2TP,...), which probably requires more knowledge of IP-layer internals than may be trivially available. 

[HMC] RSVP daemon has to be triggered when MN's point of attachment changes, in order to create reservations along the new path. The process that has the knowledge of change in point of attachment is Mobile IP (other than link layers of course). So, MIP process has to create trigger for RSVP daemon. In other words, in mobile environment, RSVP daemon cannot be receiving triggers only from applications, but has to receive them from IP stack as well. Hence, an API between IP and RSVP is needed anyway. What do you think?

The RSVP daemon can't just take the application's view of the flow identification, wrap it in some headers, and chuck it at the host IP stack.

cheers,

robert h.

[snipped]

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 30 Oct 2002 17:14:39 -0000

Mike,

> From: Michael Thomas [mailto:[email-masked]]
> Sent: 30 October 2002 16:20
> To: Hancock, Robert
> Cc: 'Sarantis Paskalis'; Hannes Tschofenig; [email-masked];
> [email-masked]
> Hancock, Robert writes:
>  > 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,
> 
> How is it done today? BCP 38 gives some guidence
> but is far from perfect. The Home Address Option,
> however, makes edge ingress filtering essentially
> impossible as BCP 38 counts on edge routers
> understanding their local topology such that they
> can perform RPF checks, etc. This cannot be done
> with the Home Address Option as the addresss...
> isn't necessarily topologically local.
> 
> Thus, it seems to me that expecting security
> properties to be enforced based on arbitrary home
> addresses is a hopeless task. However, I'm not
> convinced that that is even needed as the
> relationships in RSVP (and assumedly NSIS) are
> always hopwise, and given the desire for ingress
> filtering I'd expect that topologically correct
> CoA's to be the norm. 
> 
> This entire discussion is very reminiscent of 
> HIP discussions and RFC 2207 considerations.
> 
> 		Mike
> 

Exactly. I can't see any practical way of ensuring only legitimate packets are associated to the reservation that has been set up for them, other than topological address based checks, namely:
*) ingress filtering (weak assurance that the topological source address is valid)
*) the fact that routing works (means there is no point forging the topological destination address)
*) therefore, using the topological source and destination in a classifier is a Good Thing
*) you can add other identifiers (SPI, FL, ports...) if you want for finer grained signalling, but this is ok since they're interpreted within the scope of an (SA,DA) pair anyway.

It might be nice to use the HA, but it seems so impractical that I think a better question is: given that the packet classifiers are going to have to be updated on the unchanged path anyway, how can we make this as fast as possible (e.g. avoid re-authorisation, renegotiation of services and so on).

*In addition* in terms of overall latency, are we punishing ourselves for no gain trying to avoid this refresh on the common path, given that change-of-address signalling must be being used e2e anyway (after all, the correspondent didn't just guess the new CoA). If we can trigger the classifier update at the same time as this mobility-related signalling, we don't lose anything. (And, IIRC, this is precisely the sort of question that your seamoby draft considers. It makes my head hurt too.)

Cheers,

Robert H.