Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ...

From: "Gary Kenward" <[email-masked]>
Date: Fri, 15 Jun 2001 14:59:07 -0400

How can I clarify this: the decision was not to "exclude"
MN triggering, the decision was to exclude layer 3 signalling
from the MN as part of CTP.

There needs to be a trigger event (this I believe we all also
agreed upon). Some of us believe that the most effective source
for this trigger event is from the link layer (this is the only
way you can actually be proactive, as far as I know). However,
there should not be any design restriction in CTP preventing this 
trigger event from being generated from a different source, and 
signalled via IP.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: Friday, June 15, 2001 1:30 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'
> Subject: Reactive CT definition: Was Re: [seamoby] RE: 
> Authentication &
> Authorization ...
> 
> 
> 
> Hello Gary,
> 
> 
> Gary Kenward wrote:
> 
> >
> >
> > 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).
> >
> 
> 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 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.
> 
> 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
> 
> 
> >
> >
> > 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: Rajeev Koodli <[email-masked]>
Date: Mon, 18 Jun 2001 13:49:25 -0700

For what it is worth..

> from the MN as part of CTP.

Rajeev: That's the point. The MN may request CT using an IP message.

> trigger event from being generated from a different source, and

Rajeev: When the link layer trigger is there, it should be used.
Assuming that it will always be there is parochial.
At the IP layer, we should provide this message.

Regards,

-Rajeev

---

From: Youngjune Lee Gwon <[email-masked]>
Date: Mon, 18 Jun 2001 14:46:46 -0700 (PDT)

Rajeev,

I feel as if this L2/L3 and triggering business is still in mysterious 
clouds.

I'm also in the favor of providing some sort of L3 triggering being
necessary. I agree that the L2 is extremely handy in terms of speed and
efficiency, the L2 is only effective upon its availability.

I'm not sure if it is a desired approach to assume the L2 triggering is 
present and available all the time, neither can it be universally
specified considering it is like a flood of air-interface standards
available. 

Is it sufficient for the L2 to successfully encapsulate all the L3
context?

Anyhow, I'm currently preparing a draft which in some cases may be related
to this discussion. It regards handoff triggering and L2/L3 interaction -
movement detection/prediction, candidate agent/router discovery, and 
signaling issues.   

Youngjune