Subject: RE: [Seamoby] Issue 12: Inclusion of MN's nCoA in CTAR or CTD

From: Soliman Hesham <[email-masked]>
Date: Tue, 1 Jul 2003 00:08:51 -0400

> Soliman Hesham wrote:
 > 
 > > The MN's identifier should not be tied to its
 > > IP address or, as you correctly point out, its
 > > MAC address. If the MN needs to be identified,
 > > then a more abstract identifier should be used.
 > > For example, a NAI, IMSI, TMSI, FQDN (?) ...etc.
 > 
 > I don't think this is true.  I think that the means
 > by which the identification is carried out, should
 > be the same as the means used for the original
 > purpose of the particular protocol.  For instance,
 > if a security association is based on IP address,
 > then the identification ought to be by IP address.
 > If PAR knows the mobile node by its MAC address,
 > then that would be useful.  I think since we're in
 > the IETF, the IP address will be very handy.

=> Not sure what the last sentence means. But I
agree that the identifier depends on the context.
However, since every thing changes when you move
(IP address, MAC address potentially), these addresses
cannot be used in the general sense as identifiers.
E.g. what would you use to re-authenticate with AAA?

 > 
 > > Neither the IP address nor the MAC address are
 > > useful as generic identifiers.
 > 
 > All we have to do is identify the mobile node for
 > the purpose of context transfer, not for generic
 > purposes.  

=> Agreed. One concrete case is AAA. We certainly
need a more abstract identifier for that.

But I don't understand why this protocol needs
to pick an identifier anyway. Each context could
carry its own identifier if you want things to be
very generic.

Hesham

In fact, the word "identify" is tricky
 > enough.  Surely you won't suggest that every context
 > tranfer requires an identity verification with some
 > certificate authority...?
 > 
 > Regarding the question:
 > 
 > > Do we need to have a stable Session ID of some sort that is used?
 > 
 > I sincerely hope this approach is not taken.  It amounts
 > to excess baggage and almost a license for bloat (if not
 > a mandate for bloat).
 > 
 > Also, please remember that contexts come and go, but the
 > mobile node stays "the same".  Would you need a session
 > ID per context?  Yecch!  What, exactly, is the session?
 > 
 > Regards,
 > Charlie P.
 > 
 > 
 > 
 > >  > Hi James,
 > >  >
 > >  > > Issue 12 questions including the MN's nCoA in CTAR or CTD.
 > >  > If MN has not yet
 > >  > > completed DAD, then the address is not confirmed and it
 > >  > may not be if there
 > >  > > is a conflict (note however that exactly how to quickly
 > >  > confirm a nCoA is
 > >  > > currently a topic of heavy discussion on the MIP list, RFC
 > >  > 2462 DAD may not
 > >  > > be done). There seems to be an assumption built in that
 > >  > predictive handover
 > >  > > is occuring, and the MN will know its CoA prior to moving
 > >  > to the new link
 > >  > > or, if not predictive, then immediately on coming on link.
 > >  > >
 > >  > > Was this intended as an identifier for the MN on the new
 > >  > link? If so,
 > >  > > wouldn't a more stable identifier be the MN's link 
 > layer address?
 > >  > >
 > >  > > And what is the purpoe of old CoA?
 > >  >
 > >  > Thinking about this a bit more - this is a tricky issue.
 > >  > link layer address
 > >  > may not be good, in the case of vertical handovers.  Also,
 > >  > what to do with
 > >  > IPv4 & possibly NATed addresses?
 > >  >
 > >  > Do we need to have a stable Session ID of some sort 
 > that is used?
 > >  >
 > >  > John
 > >  >
 > >  > _______________________________________________
 > >  > Seamoby mailing list
 > >  > [email-masked]
 > >  > https://www1.ietf.org/mailman/listinfo/seamoby
 > >  >
 > > 
 > > _______________________________________________
 > > Seamoby mailing list
 > > [email-masked]
 > > https://www1.ietf.org/mailman/listinfo/seamoby
 > 

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby