Subject: RE: [netlmm] getting the identity of the mobile node

From: "Jari Arkko" <[email-masked]>
Date: Fri, 3 Aug 2007 13:44:54 +0300

Kuntal,

Netlmm cannot create information from thin air. Since we assume no host changes, the identity comes either from l2 or from aaa. If they don't give you the info, you have no way to associate two seemingly different mns to each other.

Jari

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

---

From: Julien Laganier <[email-masked]>
Date: Mon, 6 Aug 2007 15:58:10 +0200

On Monday 06 August 2007, you wrote:
> Hi Julien,

Hi Kuntal,

> > 2) remains stable across handovers,...
>
> I think this should be a requirement in general (not
> 3GPP, 3GPP2 specific). Otherwise, we have to deal
> with changing MN IDs for an ongoing PMIP6 session.
>
> Do you agree?

Yes.

--julien

> > -----Original Message-----
> > From: Julien Laganier
> > [mailto:[email-masked]] Sent: Monday,
> > August 06, 2007 8:31 AM
> > To: [email-masked]; Jari Arkko
> > Subject: Re: [netlmm] getting the identity of the
> > mobile node
> >
> > On Thursday 02 August 2007, Jari Arkko wrote:
> > > Agreed that there are non-eap accesses, and that
> > > open access is a possibility.
> > >
> > > Regarding allowing multiple schemes: yes, we
> > > have to do that. However, for truth in
> > > advertising reasons and for convincing ourselves
> > > of the correctness of our design, leaving this
> > > completely out of scope would be bad, too. I
> > > would suggest documenting the SEND and AAA
> > > schemes, at least on the level I outlined in the
> > > previous mail.
> >
> > Jari,
> >
> > Thanks for the comments, I agree completely since
> > I had came across the issues you're mentioning
> > when designing a complete mechanism for MN
> > identification based on network access
> > authentication.
> >
> > At that time I concluded that something else was
> > needed in addition to network access
> > authentication, and thought that was better left
> > out of scope of the document since there were
> > multiple ways to realize the missing part (such
> > as, as you suggest, relying on, e.g. an
> > L2-specific identity, or a RADIUS
> > Chargeable-User-Identifier attribute).
> >
> > I think it is reasonable to document as much as we
> > can what's needed for proof or correctness of the
> > design.
> >
> > Regarding open-access system, the current document
> > describes the use of a SEND-based mechanism that
> > handles secure identification of the MN based on
> > its SEND public key.
> >
> > Regarding a AAA scheme, the document could specify
> > the use of a RADIUS Chargeable-User-Identifier
> > attribute to carry to the MAG an identifier to be
> > used as a MN ID which remains constant during the
> > presence of the MN in a given NETLMM domain. It is
> > unclear to me what would be the DIAMETER
> > counterpart to RADIUS CUI.
> >
> > Finally, for others systems (e.g. 3GPP, 3GPP2,
> > etc.) we could state that the MAGs of a NETLMM
> > domain requires knowledge of MN ID that is 1)
> > securely bound to the MN, and 2) remains stable
> > across handovers, and perhaps suggest couple of
> > such identifiers...
> >
> > Thoughts?
> >
> > --julien