Subject: RE: [netlmm] MN-Id overspecification

From: "Alper Yegin" <[email-masked]>
Date: Mon, 1 Oct 2007 12:00:42 +0300

Sri,

> > The problem is, RFC 4285 does not accommodate that. It expects the
> > identifier be in "MN-NAI mobility option as defined in
> > [RFC4283]". If PMIP6
> > spec uses a suboption type other than type 1 (MN-NAI) then it works.
> > Otherwise this breaks RFC 4285.
> >
> 
> If you use Auth Option in PBU/PBA's, you will break PMIP6.
> The options are not defined for PBU/PBA's. 

So, any use of options that are not defined in the base spec would break the
spec? Of course not... This is basic extensibility. Options can be added
later without having to change the base spec. Isn't this what we did for
MIP6 anyways?

> No guidance on
> how LMA interpret that option. If you use MN-NAI, it will
> break 4285. Either case, to use 4285, you will have to
> break one of them. On a lighter note, I'd say, you should
> break 4285. It is broken any ways.

One's view on this RFC does not really justify prohibiting use of it with
the base spec we are developing in NETLMM WG.

No spec has to be broken if we don't force all messages to include "MN-id".
Given that it is not necessary, I don't understand why there is push to keep
it that way.

Alper

> I really think what Federico/Ahmad suggesting is ok. Small
> deviation from 4285.
> 
> Sri

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

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 1 Oct 2007 12:14:55 +0300

> > >> The sequence would be as follows for your scenario (assuming your
> > >> scenario is to allocate HNP during access authentication)
> > >>
> > >> - MN does access authentication
> > >> - AAA server sends the HNP for the MN to the MAG
> > >> - MAG sends a proxy BU with the MN-ID and the HNP to the LMA
> > >> - LMA checks if the MN-ID is authorized for the HNP (with
> > AAA's help)
> > >
> > > Yes.
> >
> > If you agree with the above, it means the LMA needs to have
> > the MN-ID when the proxy BU is processed. Does this not mean,
> > it is carried in the proxy BU.

The ID in the 3rd step does not have to be "MN-ID". It can be MAG ID as I
have been saying.

> 
> [Ahmad]
> In case that LMA needs to contact AAA server for this authorization
> which is very much expected during initial registration, how the LMA
> would know which AAA server it needs to forward the RADIUS or DIAMETER
> request if P-BU ONLY has the HNP?

In case the ID is the MAG ID (assuming we are using per-MAG-LMA SA, instead
of per-MN SA for RFC 4285), the SA lookup is based on the MAG ID (e.g., FQDN
of the NAS), not on the HNP.

> Is there a mechanism which allows the LMA to identify the MN home AAA
> server based on HNP?

That's not necessary for authentication/authorization with
per-MAG-LMA-SA-based RFC 4285 security.

Alper

> 
> Regards,
> Ahmad
> 
> >
> > >> Note that I completely disagree with the AAA server assigning the
> > >> HNP. I would like HNP assignment always coming from the LMA.
> > >
> > > If you prefer that in your deployments, fine by me. But if
> > you somehow
> > > want to force any IETF spec to limit deployments in that
> > way, we need
> > > to discuss that.
> >
> > You can of course disagree.
> >
> > >>>> Alper, frankly I think you need to show why including
> > the MN-ID in
> > >>>> the proxy BU is a bad idea. If there is no issue, lets move on.
> > >>> Frankly, I did show it on the ML twice already. And yet
> > to see why
> > >>> it is useful (other than for the HNP assignment case).
> > >> With 4285? That was hardly convincing. Sorry.
> > >
> > > Do you have any technical feedback, or is it just that you
> > don't feel
> > > like being convinced?
> >
> > Hard to give technical feedback on something that is not
> > technically convincing. :)
> >
> > Vijay
> >
> >
> >