Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement

From: "Gary Kenward" <[email-masked]>
Date: Thu, 14 Jun 2001 23:01:48 -0400

Kulwinder:

  I don't agree with your observation. We did discuss how CT was to be
initiated, and agreed that there would be no explicit signalling from 
the MN (not at least as far as CT was concerned). 

  The definition of reactive CT (read the problem statement)has to do with
the order/timing of events, not with where the initiating event comes from.

Gary

> -----Original Message-----
> From: Kulwinder Atwal [mailto:[email-masked]]
> Sent: Thursday, June 14, 2001 6:30 PM
> To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Pat 
> Calhoun'; Phillip
> Neumiller
> Cc: 'seamoby'; [email-masked]
> Subject: RE: [seamoby] RE: Authentication & Authorization 
> "in-the-large"
> w as Re: [seamob y] ct problem statement
> 
> 
> 
> 
> > -----Original Message-----
> > From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> > Sent: Thursday, June 14, 2001 6:02 PM
> > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat 
> > Calhoun'; Phillip
> > Neumiller
> > Cc: 'seamoby'; [email-masked]
> > Subject: RE: [seamoby] RE: Authentication & Authorization 
> > "in-the-large"
> > w as Re: [seamob y] ct problem statement
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Kulwinder Atwal [mailto:[email-masked]]
> > Sent: Thursday, June 14, 2001 4:46 PM
> > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip Neumiller
> > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby';
> > [email-masked]
> > Subject: RE: [seamoby] RE: Authentication & Authorization 
> > "in-the-large"
> > w as Re: [seamob y] ct problem statement
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Nakhjiri Madjid-MNAKHJI1 
> [mailto:[email-masked]]
> > > Sent: Thursday, June 14, 2001 5:09 PM
> > > To: 'Pat Calhoun'; Phillip Neumiller
> > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; 
> > Kulwinder
> > > Atwal; 'seamoby'; [email-masked]
> > > Subject: RE: [seamoby] RE: Authentication & Authorization 
> > > "in-the-large"
> > > w as Re: [seamob y] ct problem statement
> > > 
> > > 
> > > 
> > > 
> > > -----Original Message-----
> > > From: Pat Calhoun [mailto:[email-masked]]
> > > Sent: Wednesday, June 13, 2001 8:29 AM
> > > To: Phillip Neumiller
> > > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie
> > > Perkins; Kulwinder Atwal; 'seamoby';
> > > [email-masked]
> > > Subject: Re: [seamoby] RE: Authentication & Authorization 
> > > "in-the-large"
> > > w as Re: [seamob y] ct problem statement
> > > 
> > > 
> > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller wrote:
> > > > There are companies that build products (WRQ's reflection comes
> > > > to mind) that freeze the state of the IP stack (gracefully in
> > > > the application sense), until the flow of IP traffic can resume.
> > > > This is sort of an ultra-slow handover.  I see no 
> reason why THIS
> > > > can not be made seamless with CT.  Why should CT not be capable
> > > > of accomodating this Pat?
> > > 
> > > Sure, they could, but what is seamless in this sense? The user has
> > > no service for some time, so what is an extra couple of 
> > seconds while
> > > signalling occurs over the air to update the local ARs state?? The
> > > user would probably not even notice.
> > > 
> > > Actually, you seem to imply something that I am not sure that I've
> > > been thinking about that much, which is the mobile updating the
> > > AR's state. This, btw, can be problematic, since the 
> mobile doesn't
> > > necessarily share an SA with the AR (hence DoS attacks), and a
> > > malicious mobile could send bogus (mal-formed) CT packets in an 
> > > attempt to crash (or cause mis-behaving) ARs.
> > > 
> > > Something to think about in the DoS space.
> > > 
> > > MN>> Yes, involving the MN is CT is definitely a whole other
> > > ball of wax. As I said earlier the assumption was that the 
> > CT happens
> > > AR to AR and I was exploring the DoSs for that case.
> > 
> > 
> > > The MN is not authenticated to the newAR, so all kinds of security
> > > problems exists until the MN is "properly introduced" to 
> the newAR.
> > 
> > What do you mean "properly introduced" to the newAR.  The MN 
> > can certainly
> > authenticate to the newAR.  The MN can just show up at the 
> new AR and
> > introduce itself.  It called "Reactive" Context Transfer.
> > 
> > MN>>> Kulwinder, by "properly introduced", I meant to skip 
> > the security
> > details between MN and newAR. Yes, MN can authenticate itself 
> > to newAR but
> > not as part of CT, and for sure not before CT completition, 
> > especially, if
> > the intention of CT was to transfer MN's 
> > for-AAA-Security-needed context.
> > 
> > I don't think reactive context transfer was meant to be 
> > initiated by MN and
> > definitely not after "MN's introduction itself to newAR".
> 
> Of course it was intended.  Read the Archive.  If the MN is switching
> between wireless and wired, _as_stated_in_our_charter_, there 
> is no other
> way other than MN initiated CT. 
> 
> What do you expect will happen when an MN loses connectivity 
> between ARs and
> just shows up at the newAR?  Do you _really_ expect the 
> End-User to drive
> back during Rush Hour to the oldAR and try again?
>  
> > What does this
> > introduction mean in context of "context transfer" anyway. If 
> > CT is supposed
> > to happen between ARs, where does this introduction come in? 
> > Unless you are
> > talking about an L2 connectivity signal or even an L2 
> > authentication (which
> > is not very fast!!!). 
> > The scenario is an AR-AR CT, then an MN-newAR authentication (proper
> > introduction)
> > based on transferred credential after CT is complete.
> 
> How does the newAR even know that the MN has arrived if the 
> MN does not
> annouce itself?  Why should the newAR waste time doing a CT 
> for an MN that
> is not authorized?  Sounds like an opportunity for a DOS 
> attack.  Authorize
> first.  Then do CT.  Especially for an MN that has arrived 
> unannouced at the
> newAR due to a service disruption will moving between ARs.
> 
> - Kulwinder.
> 
> > 
> > The preferred case, of course, is when the oldAR transfers 
> > trust to the
> > newAR. 
> > 
> > MN>> Of course. That is why I mentioned "properly introduced"
> > 
> > But, certainly we must consider the case of an MN just 
> > showing up at the
> > newAR.  The newAR is then faced with finding out where the 
> MN was last
> > attached and invalidating the oldSA.  The MN has to present a 
> > credential to
> > the newAR that the oldAR will accept as valid. 
> > 
> > MN>> Yes, but that is not where CT helps, you are out of the
> > CT-is-an-optimization
> > territory. MN does a lot of negotiations for establishing 
> the context
> > anyway.
> > 
> > BTW, I just noticed that my initials and acronym for Mobile 
> > Node are the
> > same :(
> > "MN>> means I am talking :)
> > 
> > Madjid
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > > 
> > > Madjid 
> > > 
> > > PatC
> > > 
> > 
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 15 Jun 2001 10:01:02 -0700

Hello Gary,

> Gary Kenward wrote:

>        .......                   We did discuss how CT was to be

I would consider this as wholly unacceptable, except that in your

> the order/timing of events, not with where the initiating event comes from.

So then I started to wonder about how one might define "reactive" to
make the previous sentence come true.  But, the word "reactive" does
not occur in draft-ietf-seamoby-context-transfer-problem-stat-01.txt.
No help there.  I did find some redefinition of "reactive" in
draft-hamid-seamoby-ct-fwk-00.txt, but that document was, I believe,
not the result of design team discussions.  In fact, I have some
other comments on the latter document, but for now I would just like
to suggest that it should not be taken as relevant to the current
discussion about reactive context transfers.

That puts me back to square one.  From that standpoint, I would like
to suggest that the context transfer problem statement needs to
very clearly define the following concepts:

- Network-initiated context transfer, for which the access network
  tells the mobile where to go

- Mobile-initiated context transfer, for which the mobile tells the
  network where it wants to go

- Predictive context transfer, for which either the mobile or the
  network initiates context transfer BEFORE leaving the previous
  access router

- Reactive context transfer, for which either the mobile or the network
  initiates context transfer AFTER the mobile arrives (establishes
  a link) at the new access router.

I like the word "predictive" for several reasons:

- It has exactly the right meaning, and even connotes that caution
  is necessary because not all predictions come true

- In contrast to some other alternatives one often hears, it is
  a word that one can find in the dictionary.

Regards,
Charlie P.

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 15 Jun 2001 10:30:19 -0700

Hello Gary,

> the MN (not at least as far as CT was concerned).

Rajeev: I don't believe that we ever said there would be no explicit
signaling from the MN!
In fact, requirement 4.8 (which BTW, must be at least a SHOULD), gives
the option to the MN to indicate how the feature contexts be handled.

I would have strong objection to this.

> the order/timing of events, not with where the initiating event comes

Rajeev: I don't remember going through reactive CT or proactive CT
during problem statement phase at all. Nevertheless, where is the
definition of reactive CT that says a MN cannot initiate signaling ?

Regards,

-Rajeev