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

From: Kulwinder Atwal <[email-masked]>
Date: Fri, 15 Jun 2001 13:50:04 -0400

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: Kulwinder Atwal <[email-masked]>
Date: Fri, 15 Jun 2001 15:25:53 -0400

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, June 15, 2001 2:59 PM
To: 'Rajeev Koodli'
Cc: 'seamoby'
Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication &
Authorization ...

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). 

With an inter-technology Context Transfer it will most likely be the MN that
is aware of which ARs are:

- Nearby

- Of a compatible technology type (wired LAN, wireless, ...)

- Preferred

and, are likey to permit authorization.

The MN (End-User) needs a way to send a packet to the current AR to initiate
CT.  

Consider a device used as a cordless phone at home and as a cell outside of
the home.

-Kulwinder.

  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 

> From: Rajeev Koodli [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> To: Kenward, Gary [WDLN2:AN10:EXCH] 
> Cc: 'seamoby' 
> > > From: Kulwinder Atwal [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > > From: Kulwinder Atwal [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > > > From: Pat Calhoun [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: Kulwinder Atwal <[email-masked]>
Date: Mon, 18 Jun 2001 15:09:25 -0400

> Sent: Monday, June 18, 2001 2:48 PM
> To: Pat Calhoun
> Cc: Singh Ajoy-ASINGH1; 'James Kempf'; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Reactive CT definition: Was Re: [seamoby] RE:
> Authentication & Authorization ...
> 
> 
> Pat Calhoun wrote:
> 
> > On Mon, Jun 18, 2001 at 11:34:20AM -0700, Rajeev Koodli wrote:
> > >
> > > 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.
> >
> > 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?
> >
> 
> Rajeev: We have to provide this message, since we allow for 
> the MN to request CT.

I strongly agree.  The request message can be identical to the one from the
newAR, when the newAR recieves the MN without the currentAR's knowledge (MN
just shows up at newAR after a loss in connectivity).

The important thing is to seperate the signalling messages from the actual
transfer of context.

- Kulwinder.

> 
> Regards,
> 
> -Rajeev
> 
> 
> >
> > PatC
> > >
> > > Regards,
> > >
> > > -Rajeev
> > >
> > >
> > > Singh Ajoy-ASINGH1 wrote:
> > >
> > > > 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
> > > > >
> > >
>

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 18 Jun 2001 16:56:13 -0400

Rajeev:

  The current requirements in no way prohibit signalling from the MN.
Myself and others have re-iterated this many times on the list.

  o the trigger arrives at an AR at L3; the source is not specified,
    and considered out of scope for CT.

  o CT must provide the mechanisms to allow per microflow enable/disable;
    the control protocols are not specified and considered out of scope for
CT.

  Nothing you have said contradicts the above requirements. The only issue
seems to be that you and others want an explicit requirement so that the
design
task for these protocols are explicitly part of CT. This would mean not only
that
we will have to add MN signalling, but also signalling from other sources,
including
L2 (?). Sounds like a lot of effort to me, and the solutions could
unnecessarily 
constrain CT. 

Gary

> Sent: Monday, June 18, 2001 2:32 PM
> To: James Kempf
> Cc: [email-masked]; [email-masked]; Kenward, Gary
> [WDLN2:AN10:EXCH]; [email-masked]
> Hello James,
> James Kempf wrote:
> > Rajeev,
> > I don't think we can require L3 triggering in all cases. We need
> >
> 
> Rajeev: Unfortunately, I think we cannot require that the MN 
> do L2 triggering
> in all cases as well.
> 
> > to make sure that an MN not need to do L3 triggering, otherwise,
> > as Gary points out, performance will suffer.
> 
> Rajeev: yes in some links, may be (or no impact) in others.
> 
> 
> > If there's an L2 trigger,
> > it should be used preferentially.
> 
> Rajeev: certainly. It is one thing to say that if there is a 
> L2 trigger, it
> should be used preferentially, but another thing to say that 
> we disallow using
> L3 messages to trigger CT. We should have the possibility of 
> MN requesting CT.
> 
> Regards,
> 
> -Rajeev
> 
> 
> >
> >
> >                 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]>
> > >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
> > >
> > >
> > >> 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
> > >>
> 
> [snip, snip]
> 
>

---

From: Kulwinder Atwal <[email-masked]>
Date: Tue, 19 Jun 2001 00:15:11 -0400

> Sent: Monday, June 18, 2001 4:52 PM
> To: Gary Kenward
> Cc: 'seamoby'
> I believe I've already asked for this, but let me try again.
> 
> Could you please provide me with an example of when this would be
> necessary? Some justification would be useful in my mind.

1. NewAR requests that MN Context be transferred because MN has arrived at
newAR unannouced.
2. An Entity in the Network wishes to balance the network load between a
group of ARs.
3. An MN requests a change in access technology.

The same set of messages can be used for all three cases.

- Kulwinder.

> 
> PatC
> On Mon, Jun 18, 2001 at 04:56:13PM -0400, Gary Kenward wrote:
> > Rajeev:
> >

---

From: "Hamid Syed" <[email-masked]>
Date: Thu, 21 Jun 2001 09:05:06 -0400

Rajeev, 

I would suggest you to look at the issue # 2 and the proposed changes by
Kulwinder. The text and requirements proposed sounds good to me.

cheers 

-Hamid
> From:	Rajeev Koodli [SMTP:[email-masked]]
> Sent:	Wednesday, June 20, 2001 8:37 PM
> Rajeev: why would we have to add L2 signaling ? An IP message to initiate
> CT would be needed for the MN and is perhaps useful for other entities. I
> think
> it is doable.
> 
> -Rajeev
> 
> 
> >
> > Gary
> >