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

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 15 Jun 2001 17:44:12 -0500

After going through some of emails exchanged by different
people, I also think latency of L3 message may be too high.
Possibly this can bit the purpose of context transfer. Perhaps 
we should prefer layer 2 trigger over any layer 3 message. 
regards,
ajoy 

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Friday, June 15, 2001 4:38 PM
To: Ajoy Singh-ASINGH1; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: Reactive CT definition: Was Re: [seamoby] RE:
Authentication & Authorization ...

Rajeev,

I don't think we can require L3 triggering in all cases. We need
to make sure that an MN not need to do L3 triggering, otherwise,
as Gary points out, performance will suffer. If there's an L2 trigger,
it should be used preferentially.

		jak
		
>Delivered-To: [email-masked]
>X-mProtect: Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon Valley Messaging 
Protection
>Date: Fri, 15 Jun 2001 11:59:37 -0700
>From: Rajeev Koodli <[email-masked]>
>To: Singh Ajoy-ASINGH1 <[email-masked]>
>CC: "'Kulwinder Atwal'" <[email-masked]>, Gary Kenward 
<[email-masked]>, "'seamoby'" <[email-masked]>
>Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication &   
Authorization ...
>
>
>Hello Ajoy,
>
>whereas use of link-layer triggers is very useful, it is not something we
>can rely upon to be present everywhere (as you correctly point out for
>Inter-technology handovers). I don't think we ever said we disallow link
>layer triggers. We must not say that that's our solution. At the IP layer,
>we need to define IP messages. I think we pretty much agree.
>
>Regards,
>
>-Rajeev
>
>
>Singh Ajoy-ASINGH1 wrote:
>
>> I think it is possible to receive link layer trigger at the new
>> access router which can be used to initiate context transfer.
>> This will be mostly useful in case of some intra-technology
>> handovers. In case MN moves across different technologies, yes
>> some sort of MN trigger is useful. Having said that is it a
>> good idea to limit the scope of CT protocol? I think we
>> should allow both the options.
>> regards,
>> ajoy
>>
>> -----Original Message-----
>> From: Kulwinder Atwal [mailto:[email-masked]]
>> Sent: Friday, June 15, 2001 12:50 PM
>> To: 'Rajeev Koodli'; Gary Kenward
>> Cc: 'seamoby'
>> Subject: RE: Reactive CT definition: Was Re: [seamoby] RE:
>> Authentication & Authorization ...
>>
>> I would strongly object as well.
>>
>> No MN involvement is technology specific and implementation specific.
>>
>> The End-User needs the ability to decide when to switch between different
>> link-layers: wireless and wired.  There is NO way for the network to know
>> this is about to happen.
>>
>> Infact, there was much dicussion in support of this as a requirement.  We
>> need to add some new text.
>>
>> - Kulwinder.
>>
>> > -----Original Message-----
>> > From: Rajeev Koodli [mailto:[email-masked]]
>> > Sent: Friday, June 15, 2001 1:30 PM
>> > To: Gary Kenward
>> > 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 11:34:20 -0700

I think we are close to agreement. If L2 triggers exist, they should be used
preferably. That does not mean that we don't define IP message from MN to
request CT.

Regards,

-Rajeev

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 18 Jun 2001 11:25:01 -0700

> preferably. That does not mean that we don't define IP message from MN to

I think that the question is what is the L3 message? Does CT have to provide
such a message, or is this out of scope of CT?

PatC

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 18 Jun 2001 11:47:40 -0700

> such a message, or is this out of scope of CT?

Rajeev: We have to provide this message, since we allow for the MN to request CT.

Regards,

-Rajeev