Subject: RE: [netlmm] I-D Submission: draft-sgundave-mip6-proxymip6-01.txt

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Mon, 15 Jan 2007 10:32:16 -0500

In PMIP6, there is no indication sent to the MN that the network is
actually running a mobility management protocol to provide IP service to
the MN. 

The choice of CMIP vs. PMIP can be a provisioned policy in the MN's
network dialer software if there is any and if the MN has CMIP
capability. This seems to be an implementation detail.

-Kuntal

> -----Original Message-----
> From: Haris Zisimopoulos [mailto:[email-masked]]
> Sent: Monday, January 15, 2007 12:13 PM
> To: Sri Gundavelli; netlmm
> Subject: RE: [netlmm] I-D Submission:
draft-sgundave-mip6-proxymip6-01.txt
> 
> Hello,
> 
> I have read this I-D it is really well written and comprehensive.
> 
> I have one basic question that I could not answer by reading the
draft.
> Given that co-existence of host and proxy modes is one of the goals,
> what are the procedures of handling MN roaming to domains that the AR
> does not support the PMA function? IOW section 6.9 handles the
> procedures from PMA's point of view but is nowhere stated how the MN
> will "understand" when it moves to a domain where the PMA function is
> not supported (ie PMIP not supported)? Maybe some flag in RA is
required
> to indicate that PMIP is enabled?  Is this simply implementation
> specific maybe even such a statement would help.
> 
> Any ideas?
> 
> Best regards,
> Haris
> 
> > -----Original Message-----
> > From: Sri Gundavelli [mailto:[email-masked]]
> > Sent: 09 January 2007 17:14
> > To: netlmm
> > Subject: [netlmm] I-D Submission:
draft-sgundave-mip6-proxymip6-01.txt
> >
> > FYI.
> >
> >
> >
> >
> >
> > A New Internet-Draft is available from the on-line
> > Internet-Drafts directories.
> >
> >
> >          Title : Proxy Mobile IPv6
> >          Author(s) : S. Gundavelli, et al.
> >          Filename : draft-sgundave-mip6-proxymip6-01.txt
> >          Pages : 39
> >          Date : 2007-1-5
> >
> > This specification describes a network-based mobility management
> >     protocol.  It is called Proxy Mobile IPv6 (PMIPv6) and is based
on
> >     Mobile IPv6.  This protocol is for providing mobility
> > support to any
> >     IPv6 host within a restricted and topologically localized
> > portion of
> >     the network and with out requiring the participation of
> > the host in
> >     any mobility related signaling.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-sgundave-mip6-proxym
> > ip6-01.txt
> >
> > To remove yourself from the I-D Announcement list, send a
> > message to i-d-announce-request@... with the word unsubscribe
> > in the body of the message.
> > You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> > Internet-Drafts are also available by anonymous FTP. Login
> > with the username "anonymous" and a password of your e-mail
> > address. After logging in, type "cd internet-drafts" and then
> > "get draft-sgundave-mip6-proxymip6-01.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> >
> > _______________________________________________
> > netlmm mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/netlmm
> >
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 15 Jan 2007 17:12:13 +0100

Chowdhury, Kuntal wrote:
> actually running a mobility management protocol to provide IP service
> to the MN.
> 

What's CMIP?

The document doesn't say what CMIP is.  It uses however the word
'client' extensively.

Is the CMIP term the same that WiMax uses?

Alex

> 
> -Kuntal
> 
> 
>> -----Original Message----- From: Haris Zisimopoulos
>> [mailto:[email-masked]] Sent: Monday, January 15,
>> 2007 12:13 PM To: Sri Gundavelli; netlmm Subject: RE: [netlmm] I-D
>> Submission:
>> Given that co-existence of host and proxy modes is one of the
>> goals, what are the procedures of handling MN roaming to domains
>> that the AR does not support the PMA function? IOW section 6.9
>> handles the procedures from PMA's point of view but is nowhere
>> stated how the MN will "understand" when it moves to a domain where
>> the PMA function is not supported (ie PMIP not supported)? Maybe
>> some flag in RA is
> required
>> Best regards, Haris
>>> -----Original Message----- From: Sri Gundavelli
>>> [mailto:[email-masked]] Sent: 09 January 2007 17:14 To:
>>> netlmm Subject: [netlmm] I-D Submission:
>>> Title : Proxy Mobile IPv6 Author(s) : S. Gundavelli, et al. 
>>> Filename : draft-sgundave-mip6-proxymip6-01.txt Pages : 39 Date :
>>> 2007-1-5
>>> 
>>> Mobile IPv6.  This protocol is for providing mobility support to
>>> any IPv6 host within a restricted and topologically localized 
>>> portion of the network and with out requiring the participation
>>> of the host in any mobility related signaling.
>>> 
>>> To remove yourself from the I-D Announcement list, send a message
>>> to i-d-announce-request@... with the word unsubscribe in the body
>>> of the message. You can also visit
>>> Internet-Drafts are also available by anonymous FTP. Login with
>>> the username "anonymous" and a password of your e-mail address.
>>> After logging in, type "cd internet-drafts" and then "get
>>> draft-sgundave-mip6-proxymip6-01.txt".
>>> 
>>> _______________________________________________ netlmm mailing
>>> list [email-masked] 
>> _______________________________________________ netlmm mailing list
>>  [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
> 
> _______________________________________________ netlmm mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 15 Jan 2007 08:31:30 -0800 (PST)

Hi Alex,

On Mon, 15 Jan 2007, Alexandru Petrescu wrote:

>>  network dialer software if there is any and if the MN has CMIP capability.
>>  This seems to be an implementation detail.
>
> What's CMIP?
>

A Mobile Node operating as a Mobile IPv6 client [Per RFC-3775]

> The document doesn't say what CMIP is.  It uses however the word

Ok. We will fix any ambiguity. Mobile/Mobile Node/Client all refer
to a mobile node.

> Is the CMIP term the same that WiMax uses?

Its a general term, used in many places.

Thanks
Sri

---

From: "Tsirtsis, George" <[email-masked]>
Date: Mon, 15 Jan 2007 08:31:54 -0800

Hi Harri/Kuntal,

Configuration is always possible, but I hope that, if implementations
behave :-), such configuration should not be necessary. Here is how I
view PMIP/CMIP interactions:

Mobiles that support client-mobility i.e., they support a MobileIP
client, need to be able to function in the presence of PMIP domains.

Assuming I understand draft-sgundave, network mobility domains are
supposed to appear to the Client-MobileIP stack as single links. Indeed,
while in a PMIP domain, a mobile node should believe that it is directly
connected to its home link. Note that "home link" here refers to the
link to which the IP address assigned by the PMIP domain to the mobile
belongs to. 

>From the mobile node perspective, an interface connected to a PMIP
domain looks like a single link i.e., Link Layer attachment changes are
not visible and the IP address assigned to the interface does not change
while the interface is connected to the same PMIP domain.

Now, if the PMIP domain is truly the mobile node's "home", in the Mobile
IP sense of the word then, while the mobile node is connected in the
PMIP domain, the MobileIP client is not registered to the HA i.e., the
mobile should behave according to RFC 2473 for mobiles connected to home
link.

If the PMIP domain is not the mobile node's "home" then, the Mobile IP
client can use the address assigned to the interface by the PMIP domain
as a CoA and thus, it should be able to perform a MIP registration to
its HA.

Also note, that mobiles that do not support client-mobility, work
exactly as above but, since they do not have a MobileIP client, they can
not use the address assigned by the PMIP domain as a CoA. In other words
if such a mobile moves out of the range of the PMIP domain, the "link"
will change and a new IP address will be assigned.

Does this make sense or did I miss something?

Best regards
George

> From: Chowdhury, Kuntal [mailto:[email-masked]]
> Sent: Monday, January 15, 2007 10:32 AM
> To: Haris Zisimopoulos; Sri Gundavelli; netlmm
> actually running a mobility management protocol to provide IP service
to

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 15 Jan 2007 08:45:30 -0800 (PST)

Hi George,

> link to which the IP address assigned by the PMIP domain to the mobile

Yes.

> mobile should behave according to RFC 2473 for mobiles connected to home

Yes

> as a CoA and thus, it should be able to perform a MIP registration to

Yes. The detection logic that the mip clients use for detecting home/roam
network should just work in PMIP domain.

> will change and a new IP address will be assigned.

Yes. In that case, the host looses mobility. Using any of the address 
configuration procedures, it would end up with a new address and not
with its home address.

---

From: Julien Laganier <[email-masked]>
Date: Mon, 15 Jan 2007 17:51:48 +0100

Hi Georges,

I share entirely your views on how PMIP will interact 
with host-based MIP (or CMIP.)

Best,

--julien

On Monday 15 January 2007 17:31, Tsirtsis, George 
wrote:
> Hi Harri/Kuntal,
>
> Configuration is always possible, but I hope that,
> if implementations behave :-), such configuration
> should not be necessary. Here is how I view
> PMIP/CMIP interactions:
>
> Mobiles that support client-mobility i.e., they
> support a MobileIP client, need to be able to
> function in the presence of PMIP domains.
>
> Assuming I understand draft-sgundave, network
> mobility domains are supposed to appear to the
> Client-MobileIP stack as single links. Indeed, while
> in a PMIP domain, a mobile node should believe that
> it is directly connected to its home link. Note that
> "home link" here refers to the link to which the IP
> address assigned by the PMIP domain to the mobile
> belongs to.
>
> domain looks like a single link i.e., Link Layer
> attachment changes are not visible and the IP
> address assigned to the interface does not change
> Now, if the PMIP domain is truly the mobile node's
> "home", in the Mobile IP sense of the word then,
> while the mobile node is connected in the PMIP
> domain, the MobileIP client is not registered to the
> HA i.e., the mobile should behave according to RFC
> 2473 for mobiles connected to home link.
>
> If the PMIP domain is not the mobile node's "home"
> then, the Mobile IP client can use the address
> assigned to the interface by the PMIP domain as a
> CoA and thus, it should be able to perform a MIP
> registration to its HA.
>
> Also note, that mobiles that do not support
> client-mobility, work exactly as above but, since
> they do not have a MobileIP client, they can not use
> the address assigned by the PMIP domain as a CoA. In
> other words if such a mobile moves out of the range
> of the PMIP domain, the "link" will change and a new
> IP address will be assigned.
>
> > From: Chowdhury, Kuntal
> > [mailto:[email-masked]] Sent:
> > Monday, January 15, 2007 10:32 AM
> > In PMIP6, there is no indication sent to the MN
> > that the network is actually running a mobility
> > management protocol to provide IP service
>
> to
>
> > the MN.
> >
> > The choice of CMIP vs. PMIP can be a provisioned
> > policy in the MN's network dialer software if
> > there is any and if the MN has CMIP capability.
> > > From: Haris Zisimopoulos
> > > [mailto:[email-masked]] Sent:
> > > Monday, January 15, 2007 12:13 PM To: Sri
> > > Gundavelli; netlmm
> > > Given that co-existence of host and proxy modes
> > > is one of the goals, what are the procedures of
> > > handling MN roaming to domains that the
>
> AR
>
> > > does not support the PMA function? IOW section
> > > 6.9 handles the procedures from PMA's point of
> > > view but is nowhere stated how the MN will
> > > "understand" when it moves to a domain where the
> > > PMA function
>
> is
>
> > > to indicate that PMIP is enabled?  Is this
> > > simply implementation specific maybe even such a
> > > statement would help.
> > >
> > > Any ideas?
> > >
> > > Best regards,
> > > Haris
> > >
> > > > From: Sri Gundavelli
> > > > [mailto:[email-masked]] Sent: 09 January
> > > > 2007 17:14
> > > > To: netlmm
> > > > A New Internet-Draft is available from the
> > > > on-line Internet-Drafts directories.
> > > >
> > > >
> > > >          Filename :
> > > > draft-sgundave-mip6-proxymip6-01.txt Pages :
> > > > 39
> > > >          Date : 2007-1-5
> > > >
> > > > This specification describes a network-based
> > > > mobility management protocol.  It is called
> > > > Proxy Mobile IPv6 (PMIPv6) and is
>
> based
>
> > on
> >
> > > >     Mobile IPv6.  This protocol is for
> > > > providing mobility support to any
> > > >     IPv6 host within a restricted and
> > > > topologically localized portion of
> > > >     the network and with out requiring the
> > > > participation of the host in
> > > > http://www.ietf.org/internet-drafts/draft-sgun
> > > >dave-mip6-proxym ip6-01.txt
> > > >
> > > > To remove yourself from the I-D Announcement
> > > > list, send a message to
> > > > i-d-announce-request@... with the word
> > > > unsubscribe in the body of the message.
> > > > You can also visit
> >
> > > > Internet-Drafts are also available by
> > > > anonymous FTP. Login with the username
> > > > "anonymous" and a password of your e-mail
> > > > address. After logging in, type "cd
> > > > internet-drafts" and then "get
> > > > A list of Internet-Drafts directories can be
> > > > found in http://www.ietf.org/shadow.html or

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Mon, 15 Jan 2007 18:06:06 +0100

Hi George and Sri,

I agree with your considerations. I have one question though.

> > mobile should behave according to RFC 2473 for mobiles connected to home

What about if, after this movement from the PMIP "home" domain to an
external access network, the MN then returns home (i.e. to the PMIP
domain)?

Based on RFC3775 it sends a de-registration BU. But at the same time
the PMA will send a proxy BU in order to update the HA.

Comments?

--Gerardo

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 15 Jan 2007 09:15:41 -0800 (PST)

Hi Gerardo,

> the PMA will send a proxy BU in order to update the HA.

A mobile after being a CMIP node roams to a PMIP domain, the proxy
mobile agent will send a PBU and the home agent after accepting
that registration request will update the BCE with the new proxy
operation flag and the new COA etc. This will remove the prev.
HA-MN tunnel and a new path will be setup. At this point the
mobile will detect its home and send a dereg and that message will
be tunneled back to the home via the proxy tunnel. The home agent,
in this scenario, needs to accept dereg from the pmip tunnel and
should acknowledge back.

Sri

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Mon, 15 Jan 2007 18:21:06 +0100

Hi Sri,

> operation flag and the new COA etc.

So the HA will accept a PBU for a binding cache entry created by the
MN via RFC 3775 signaling? It does seem a big depart from RFC 3775
security model.

> This will remove the prev.
> HA-MN tunnel and a new path will be setup.

So at this point the HA has a binding cache entry with HoA -> CoA (CoA
is the address of the PMA). Right?

> At this point the

But when the HA processes this new BU, doesn't it remove the binding
cache entry mentioned above (i.e. the CoA of the PMA)?

--Gerardo

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 15 Jan 2007 09:28:34 -0800 (PST)

Hi Gerardo,

> MN via RFC 3775 signaling? It does seem a big depart from RFC 3775

We dont really see such integrated PMIP/CMIP depolyments. But, it
can certainly work that way. If the requirement is to support proxy
and client registrations at the same time, the trust model has to
be in equal terms. HA-PMA trust equal to HA-MN trust. That's needed
for coexistence.

Yes.

> cache entry mentioned above (i.e. the CoA of the PMA)?

Good point. If the dereg comes from a PMA-HA tunnel, it just needs to
update the tunnel or delete the prev tunnel, if it has not done so.

Thanks
Sri

---

From: "Tsirtsis, George" <[email-masked]>
Date: Mon, 15 Jan 2007 09:28:34 -0800

I think things work reasonably well if one assumes that the same HA
supports PMIP and Client-MIP (CMIP).

There is also the case where on the *same* link there is a CMIP-HA and a
separate PMIP-HA. Is such configuration allowed? I think this would
introduce additional issues.

George

> From: Gerardo Giaretta [mailto:[email-masked]]
> Sent: Monday, January 15, 2007 12:21 PM
> To: Sri Gundavelli
> Cc: Tsirtsis, George; netlmm
> Subject: Re: [netlmm] I-D Submission:
> 
> Hi Sri,
> 
> > >> >  Now, if the PMIP domain is truly the mobile node's "home", in
the
> Mobile
> > >> >  IP sense of the word then, while the mobile node is connected
in
> the
> > >> >  PMIP domain, the MobileIP client is not registered to the HA
i.e.,
> the
> > >> >  mobile should behave according to RFC 2473 for mobiles
connected
> to home
> > >> >  behave :-), such configuration should not be necessary. Here
is
> how I
> > >> >  supposed to appear to the Client-MobileIP stack as single
links.
> Indeed,
> > >> >  while in a PMIP domain, a mobile node should believe that it
is
> directly
> > >> >  connected to its home link. Note that "home link" here refers
to
> the
> > >> >  link to which the IP address assigned by the PMIP domain to
the
> mobile
> > >> >  not visible and the IP address assigned to the interface does
not
> change
> > >> >  Now, if the PMIP domain is truly the mobile node's "home", in
the
> Mobile
> > >> >  IP sense of the word then, while the mobile node is connected
in
> the
> > >> >  PMIP domain, the MobileIP client is not registered to the HA
i.e.,
> the
> > >> >  mobile should behave according to RFC 2473 for mobiles
connected
> to home
> > >> >  client can use the address assigned to the interface by the
PMIP
> domain
> > >> >  as a CoA and thus, it should be able to perform a MIP
registration
> > >> >  exactly as above but, since they do not have a MobileIP
client,
> they can
> > >> >  not use the address assigned by the PMIP domain as a CoA. In
other
> words
> > >> >  if such a mobile moves out of the range of the PMIP domain,
the
> "link"
[mailto:[email-masked]]
> > >> > >  In PMIP6, there is no indication sent to the MN that the
network
> is
> > >> > >  actually running a mobility management protocol to provide
IP
> service
> > >> >  to
> > >> > >  the MN.
> > >> > >
> > >> > >  The choice of CMIP vs. PMIP can be a provisioned policy in
the
> MN's
[mailto:[email-masked]]
> > >> > > >  I have one basic question that I could not answer by
reading
> the
> goals,
> > >> > > >  what are the procedures of handling MN roaming to domains
that
> the
> > >> > > >  procedures from PMA's point of view but is nowhere stated
how
> the MN
> > >> > > >  will "understand" when it moves to a domain where the PMA
> function
> > >> >  is
> > >> > > >  not supported (ie PMIP not supported)? Maybe some flag in
RA
> > >> > > > >      protocol.  It is called Proxy Mobile IPv6 (PMIPv6)
and

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 15 Jan 2007 11:33:03 -0600

Sri,

> operation flag and the new COA etc.

If an MS is a CMIP6 node, what do you mean when it roams into a PMIP domain?
Why would a CMIP6 node not operate as a standard CMIP6 host in any domain?

PMIP6 is applicable only when the host does not have client MIP capability.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 15 Jan 2007 09:38:34 -0800 (PST)

Hi Raj,

> PMIP6 is applicable only when the host does not have client MIP capability.

It would operate the same way in both the domains. When I say, "after
being a CMIP node", I mean after having established a binding with its
home agent, now if it roams to a PMIP domain ...

I think this matrix of PMIP/CMIP scenario's is theoritically possible,
but I dont see deployments hapenning this way.

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 15 Jan 2007 11:49:07 -0600

Hi Sri,

To a CMIP6 host an access network that provides IPv6 connectivity is all the
same. The fact that it is capable of providing PMIP6 support for non-CMIP6
hosts is irrelevant to the CMIP6 host.

Hence the term PMIP6 domain should be applicable only to hosts that do not
have client MIP6 capability.

The other question is regarding a CMIP6 host attaching to a network that is
defined as "PMIP6 domain". If the CMIP6 host ha yet to send a BU, does the
PMIP6 domain already send the PBU? The CMIP6 host may delay (for whatever
reason) the sending of the BU to the HA. In such a scenario you would not
want the Proxy in the PIP domain sending a PBU on the MS' behalf. How is
this handled?

-Raj

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Mon, 15 Jan 2007 18:47:53 +0100

Hi Sri,

actually this is something being discussed and proposed by some
companies in 3GPP SAE. So I think there are deployments looking at it,
this is why I raised the issue.

--Gerardo

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 15 Jan 2007 10:03:07 -0800 (PST)

Hi Raj,

> want the Proxy in the PIP domain sending a PBU on the MS' behalf. How is

In a PMIP6 domain on a link that is supported by a proxy mobile agent,
when the mobile attaches to that link, the proxy mobile agent after
the access authentication knows the mobile's profile and sends a BU on
its behalf. Now, if the mobile sends a Router solicitation message,
it would receive a Router Advertisement containing its home prefix and
thus with out having the need to send a BU. So, the proxy mobile agent
ensures, the mobile's home link is emulated on that link. However, after
the access authentication, if the network determines that the attached
node does not require PMIP service, it send an advertisement containing
the visitor network prefix and the mobile can kick start the MIP client
functionality. But, it is not possible for the network to offer both
visitor and home network prefixes, for allowing the mobile to make that
choice. The fact that the mobile attaches to a PMIP link and the fact
that the network policy states that the mobile is provisioned for PMIP
service, will dictate the type of mobility it gets.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 15 Jan 2007 10:03:41 -0800 (PST)

Hi Gerardo,

> this is why I raised the issue.

Ok. Coexistence, should be possible. We dont see any issues.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 15 Jan 2007 19:13:06 +0100

Gerardo, Sri, can I please interfere here since you brought up the 
subject... basically I don't think PMIP security is figured out 
completely but neither does the draft I think, because they refer to a 
potentially new AAA method.

Gerardo Giaretta wrote:
>> the Mobile
>> i.e., the
>>> What about if, after this movement from the PMIP "home" domain to
>>> an external access network, the MN then returns home (i.e. to the
>>> PMIP domain)?
>>> 
>>> Based on RFC3775 it sends a de-registration BU. But at the same
>>> time the PMA will send a proxy BU in order to update the HA.
>>> 
>> 

I agree.  More specifically

draft:
> In the examples shown below, the identity of the proxy mobile agent 
> is assumed to be pma_1, the address of the proxy mobile agent is 
> assumed to be pma_address_1, and the IPv6 address of the Home Agent 
> is assumed to be home_agent_1.
> 
>       mobile node SPD-S:
>         - IF local_address = pma_address_1 &
>              remote_address = home_agent_1 &
>              proto = MH & local_mh_type = BU & remote_mh_type = BAck
>           Then use SA ESP transport mode
>           Initiate using IDi = pma_1 to address home_agent_1

Who allows PMA (Proxy Mobile Agent) to have an entry in its SPD about 
mobile node's IP address?   How can this be built dynamically, is this 
entry present at all PMAs in the domain, for each MN, scalable, etc.  Is 
this an important part of the PMIP protocol, what do you think?

draft:
> IKEv2 is used to setup security associations between the proxy mobile
>  agent and the home agent to protect the Proxy Binding Update and 
> Proxy Binding Acknowledgment messages.  The proxy mobile agent and 
> the home agent can use any of the authentication mechanisms, as 
> specified in IKEv2, for mutual authentication.

Yes, I agree PMA and HA can develop their SAs dynamically with IKEv2. 
But that'll concern only them two, not the other party which is MN.  No?

draft:
> The actual mechanism by which the home agent verifies if a proxy 
> mobile agent is authorized to send Proxy Binding Updates on behalf of
>  a mobile node is out of scope for this document.  One possible 
> solution is for the home agent to check with the AAA infrastructure 
> if a particular proxy mobile agent is authorized to send Proxy 
> Binding Updates on behalf of a mobile node.

I think this mechanism is needed.  I think without a clear method to 
have Proxy Mobile Agent verified about its PBUs the whole PMIP system 
may be insecure.

I think currently there's no specified method for HA to query AAA about 
a third entity that would be authorized to send BUs on behalf of a 
fourth (read: 4).  The solution would be an enhancement to AAA normal 
operation whereby a node queries a server about a third node (read: 3).

What do you think?

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 15 Jan 2007 10:20:54 -0800 (PST)

Alex,

There are two typos in the last rev. We realized that after we
sent. Please treat "Mobile node's SPD's" as "Proxy Mobile Agent's SPD's".

Now, the security in PMIP is from a normal IPSec peer relation between
the HA and the Proxy Mobile Agent. PMA is a special entity in the PMIP
network that has privileges send proxy registrations. Now, what is
missing here. There is no other "AAA" special interaction.

Sri

On Mon, 15 Jan 2007, Alexandru Petrescu wrote:

> Gerardo, Sri, can I please interfere here since you brought up the subject... 
> basically I don't think PMIP security is figured out completely but neither 
> does the draft I think, because they refer to a potentially new AAA method.
>
> Gerardo Giaretta wrote:
>>  Hi Sri,
>> 
>> >  mobile agent will send a PBU and the home agent after accepting that 
>> >  registration request will update the BCE with the new proxy operation 
>> >  flag and the new COA etc.
>>
>>  So the HA will accept a PBU for a binding cache entry created by the MN
>>  via RFC 3775 signaling? It does seem a big depart from RFC 3775 security
>>  model.
>
>>  In the examples shown below, the identity of the proxy mobile agent is
>>  assumed to be pma_1, the address of the proxy mobile agent is assumed to
>>  be pma_address_1, and the IPv6 address of the Home Agent is assumed to be
>>  home_agent_1.
>>
>>        mobile node SPD-S:
> Who allows PMA (Proxy Mobile Agent) to have an entry in its SPD about mobile 
> node's IP address?   How can this be built dynamically, is this entry present 
> at all PMAs in the domain, for each MN, scalable, etc.  Is this an important 
> part of the PMIP protocol, what do you think?
>
> draft:
>>  agent and the home agent to protect the Proxy Binding Update and Proxy
>>  Binding Acknowledgment messages.  The proxy mobile agent and the home
>>  agent can use any of the authentication mechanisms, as specified in IKEv2,
>>  for mutual authentication.
>
> Yes, I agree PMA and HA can develop their SAs dynamically with IKEv2. But 
> that'll concern only them two, not the other party which is MN.  No?
>
> draft:
>>  The actual mechanism by which the home agent verifies if a proxy mobile
>>  agent is authorized to send Proxy Binding Updates on behalf of
>>  a mobile node is out of scope for this document.  One possible solution is
>>  for the home agent to check with the AAA infrastructure if a particular
>>  proxy mobile agent is authorized to send Proxy Binding Updates on behalf
>>  of a mobile node.
>
> I think this mechanism is needed.  I think without a clear method to have 
> Proxy Mobile Agent verified about its PBUs the whole PMIP system may be 
> insecure.
>
> I think currently there's no specified method for HA to query AAA about a 
> third entity that would be authorized to send BUs on behalf of a fourth 
> (read: 4).  The solution would be an enhancement to AAA normal operation 
> whereby a node queries a server about a third node (read: 3).
>
> What do you think?
>
> Alex
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 15 Jan 2007 19:29:58 +0100

> sent. Please treat "Mobile node's SPD's" as "Proxy Mobile Agent's SPD's".

Ok, sorry.

> missing here.

How is HA sure that the PMA didn't lie about MN in its P-BU?  The draft 
suggests HA to check with AAA.

Alex

  There is no other "AAA" special interaction.
>>> > > > >  A mobile after being a CMIP node roams to a PMIP domain, the 
>>> proxy >  mobile agent will send a PBU and the home agent after 
>>> accepting that >  registration request will update the BCE with the 
>>> new proxy operation >  flag and the new COA etc.
>>>
>> entry present at all PMAs in the domain, for each MN, scalable, etc.  
>> Is this an important part of the PMIP protocol, what do you think?
>>
>> draft:
>>> solution is
>> I think currently there's no specified method for HA to query AAA 
>> about a third entity that would be authorized to send BUs on behalf of 
>> a fourth (read: 4).  The solution would be an enhancement to AAA 
>> normal operation whereby a node queries a server about a third node 
>> (read: 3).
>>
>> What do you think?
>>
>> Alex
>>
>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 15 Jan 2007 10:42:08 -0800 (PST)

Hi Alex,

> How is HA sure that the PMA didn't lie about MN in its P-BU?

This solution requires an established trust between the home agent
and the proxy mobile agent. That is the stated assumption.
In any proxy model, there is a 3rd entity and that needs to be trusted,
that is the nature of the solution.

Lets for a second, talk about RFC-3963. The mobile sends a BU with
the MNP option containing the prefix that belongs to some other MR.
How does the HA authorise this ? There could be 100's of LFN's on
those prefixes and if the trust between the HA-MR is compromised,
all those nodes connectivity is in question. Same thing here, we
require proper security state between the HA and the PMA's. There
needs to be IPSec's configured statically or through IKEv2 for this
to work.

Sri

The draft 
> suggests HA to check with AAA.

The draft suggest the use of AAA as a policy store. All or most
service provider networks use this for all the policy data. PMIP
suggests the use for the same. However, it is optional. If the
home agent can use LDAP or local policy store, there is no need
for AAA.

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 15 Jan 2007 10:50:54 -0800

> Its a general term, used in many places.

I think you mean other SDOs. It is not a term used in the IETF and I'd
recommend not using this term in the document, as it may be confusing in
the IETF context. The document as such should focus on defining PMIP -
the design should allow for MNs running MIP6 to work on the same
network, but, I don't think this document should be discussing that
interaction. 

Vidya

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 15 Jan 2007 10:59:55 -0800 (PST)

> network, but, I don't think this document should be discussing that

We need some terminology to distinguish between a mobile node that
is not capable of sending any MIPv6 signalling messages to the one
that can do so. We did not have this section on this interaction in
the previous revision of the document, on some comments in the last
WG meet, we have added them. The text we covered is w.r.t the proxy
mobile agent's behaviour when it detects a mobile node that is
configured in its policy store to a any other node. It has a bearning
on its operation and the RA's it sends. We had to cover that to that
extent.

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 15 Jan 2007 12:24:27 -0800

All,
While we all believe that PMIPv6 must not preclude the use of MIP6 in
the same network, I would encourage everyone to focus on the design of
PMIPv6 itself, rather than on the interactions between the two protocols
in the protocol document. In part, the terminology being all MIP6-based
in this draft seems to be causing some confusion. For instance, there
seems to be some confusion on the binding cache of MIP6 and PMIP6 -
these are independent and the two protocols have different security
models. 

I agree with almost all the points made here by George. However, there
is more than one way of using MIP6 and PMIP6 in conjunction in a given
network and that is an architectural issue that is not really within the
scope of the protocol document. 

For the purpose of PMIPv6, I would suggest this - the PMIP binding MUST
NOT disallow any MIP6 bindings in accordance with RFC3775. In
particular, I would expect the PMIP bindings to be specifically noted as
PMIP and hence not expect the PMIP6 and MIP6 BUs to be modifying the
same binding cache entry. 

Vidya

> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Monday, January 15, 2007 8:52 AM
> To: [email-masked]
> Subject: PMIP/CMIP interactions (Was: [netlmm] I-D 
> Submission:draft-sgundave-mip6-proxymip6-01.txt)
> 
> Hi Georges,
> 
> I share entirely your views on how PMIP will interact with 
> host-based MIP (or CMIP.)
> 
> Best,
> 
> --julien
> 
> > supposed to appear to the Client-MobileIP stack as single links. 
> > Indeed, while in a PMIP domain, a mobile node should 
> believe that it 
> > is directly connected to its home link. Note that "home link" here 
> > refers to the link to which the IP address assigned by the 
> PMIP domain 
> > to the mobile belongs to.
> >
> > domain looks like a single link i.e., Link Layer attachment changes 
> > are not visible and the IP address assigned to the 
> interface does not 
> > change while the interface is connected to the same PMIP domain.
> >
> > Now, if the PMIP domain is truly the mobile node's "home", in the 
> > Mobile IP sense of the word then, while the mobile node is 
> connected 
> > in the PMIP domain, the MobileIP client is not registered to the HA 
> > i.e., the mobile should behave according to RFC
> > then, the Mobile IP client can use the address assigned to the 
> > interface by the PMIP domain as a CoA and thus, it should 
> be able to 
> > perform a MIP registration to its HA.
> >
> client, they 
> > can not use the address assigned by the PMIP domain as a 
> CoA. In other 
> > words if such a mobile moves out of the range of the PMIP 
> domain, the 
> > "link" will change and a new IP address will be assigned.
> >
> network is 
> > > capability.
> > > > Monday, January 15, 2007 12:13 PM To: Sri Gundavelli; netlmm
> > > > that the
> > > > 6.9 handles the procedures from PMA's point of view but 
> is nowhere 
> > > > stated how the MN will "understand" when it moves to a domain 
> > > > where the PMA function
> >
> > is
> >
> > > > > protocol.  It is called Proxy Mobile IPv6 (PMIPv6) and is
> >
> > based
> >
> > > on
> > >
> > > > > message to i-d-announce-request@... with the word 
> unsubscribe in 
> > > > > the body of the message.
> > > > > You can also visit
> > >

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 15 Jan 2007 12:38:57 -0800

> > recommend not using this term in the document, as it may be 
> confusing 
> > in the IETF context. The document as such should focus on defining 
> > PMIP - the design should allow for MNs running MIP6 to work on the 
> > same network, but, I don't think this document should be discussing 
> > that interaction.
> >
> 
> We need some terminology to distinguish between a mobile node 
> that is not capable of sending any MIPv6 signalling messages 
> to the one that can do so. We did not have this section on 
> this interaction in the previous revision of the document, on 
> some comments in the last WG meet, we have added them. The 
> text we covered is w.r.t the proxy mobile agent's behaviour 
> when it detects a mobile node that is configured in its 
> policy store to a any other node. It has a bearning on its 
> operation and the RA's it sends. We had to cover that to that extent.
> 

If needed, we can use something to the effect of "MIP6 MN" and "PMIP6
MN" - however, I do believe that the text on MIP6 is not needed in the
draft. The operation of the AR and how it sends an RA only needs to be
covered for PMIP6 in the document though. I don't expect this document
to define the RAs and AR behavior for other protocols. 

Vidya

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 15 Jan 2007 12:41:11 -0800 (PST)

Hi Vidya,

> same binding cache entry.

The question is, do we expect the address that is assigned by
a Proxy Mobile IPv6 network to a mobile node is the same as that
of its Home Address, Per-3775. If it is yes, its makes sense to
have one BCE. There needs to be one route for that addres either
over HA-MN or HA-PMA tunnel and so the HA needs to maintain one
BCE entry for that address.

We do have the flags in the BCE for indicating that its a PMIP6
binding.

Thanks
Sri

---

From: "Mohamed Khalil" <[email-masked]>
Date: Mon, 15 Jan 2007 14:51:04 -0600

I believe we should keep one BCE for both PMIP and CMIP.

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Monday, January 15, 2007 2:24 PM
To: Julien Laganier; [email-masked]
Subject: [netlmm] Role of MIP6 in PMIPv6 document (was RE: PMIP/CMIP
interactions)

All,

Vidya

> > > > Sent: Monday, January 15, 2007 12:13 PM To: Sri Gundavelli; 
> > > > netlmm
> > > > >          Filename : draft-sgundave-mip6-proxymip6-01.txt Pages

> > > > > : 39

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 15 Jan 2007 14:06:28 -0800

FWIW, I found George's message to be the best clarification
I have seen so far on the subject of PMIP/CMIP interactions.
Enumerating various use-cases is good, but so is keeping
things simple. 

Fred
[email-masked]

> Sent: Monday, January 15, 2007 12:24 PM
> Subject: [netlmm] Role of MIP6 in PMIPv6 document (was RE: 
> PMIP/CMIPinteractions)
> 
> All,
> attachment changes 
> reading the

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Jan 2007 12:20:27 +0100

Sri Gundavelli wrote:
> 
> Hi Alex,
> 
> 
>>> Now, the security in PMIP is from a normal IPSec peer relation 
>>> between the HA and the Proxy Mobile Agent. PMA is a special 
>>> entity in the PMIP network that has privileges send proxy 
>>> registrations. Now, what is missing here.
>> 
> and the proxy mobile agent. That is the stated assumption. In any 
> proxy model, there is a 3rd entity and that needs to be trusted, that
>  is the nature of the solution.

I agree HA and PMAs (Proxy Mobile Agent) have trust relationships
between them, and that is deployable.  Either static SAs or dynamically
developped SAs between them is feasible, in a small system.

However, this concerns their own addresses (HA and PMAs) and it's not
about the address of the Mobile Nodes.

It may be considered that PMA will never cheat about another the address
it sends in a P-BU.  But at that point one should suggest how the PMA
authorizes a MN in first place.  This is not described.  What is
described is how the HA authorizes a PMA about a MN.

> How does the HA authorise this ?

The Prefix Table of rfc3963?

> There could be 100's of LFN's on those prefixes and if the trust 
> between the HA-MR is compromised, all those nodes connectivity is in 
> question. Same thing here, we require proper security state between 
> the HA and the PMA's. There needs to be IPSec's configured statically
> or through IKEv2 for this to work.

The nemo problem is about authorizing addresses within a prefix.  I
agree that HA authorizes the entire prefix (all LFNs in that mnp) at
once, without knowing which LFN is nice and which not.

The netlmm problem is about authorizing one address with respect to
another (not an address in a prefix), it's much like the RO solution
with RR testing HoA related to CoA.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Jan 2007 13:36:05 +0100

Narayanan, Vidya wrote:
> All, While we all believe that PMIPv6 must not preclude the use of 
> MIP6 in the same network, I would encourage everyone to focus on the 
> design of PMIPv6 itself, rather than on the interactions between the 
> two protocols in the protocol document.

Check Goal #7 - MIP6 MN must work in a netlmm domain.

> In part, the terminology being all MIP6-based in this draft seems to 
> be causing some confusion. For instance, there seems to be some 
> confusion on the binding cache of MIP6 and PMIP6 - these are 
> independent and the two protocols have different security models.

I agree PMIP6 and MIP6 have completely different security models.

> I agree with almost all the points made here by George. However, 
> there is more than one way of using MIP6 and PMIP6 in conjunction in 
> a given network and that is an architectural issue that is not really
>  within the scope of the protocol document.

But we have a clear goal to be able to use MIP6 on the mobile (goal #7).
I agree though document treats protocol, not architecture.  And protocol
should work even if MN uses MIP6.

We could refine the goal further and decide the following:

-should the HA accept BU from its MN when it is away from the netlmm
  domain?
-should PMA send de-registering P-BUs when MN comes home into the netlmm
  domain?  Or when MN left domain?

These and many other issues have already received answers in
draft-sgundave, but I think they need discussion.

> For the purpose of PMIPv6, I would suggest this - the PMIP binding 
> MUST NOT disallow any MIP6 bindings in accordance with RFC3775.

How can one implement a binding to not disallow (or allow) another binding?

I agree more with the suggestion that binding cache conceptual structure
should be the same between MIP6 and PMIP.  This is implementable.

Alex

---

From: "Osvaldo Gonsa" <[email-masked]>
Date: Tue, 16 Jan 2007 14:40:24 +0100

Hi Sri,

Just one question

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Monday, January 15, 2007 7:03 PM
To: Basavaraj Patil
Cc: netlmm
Subject: Re: [netlmm] I-D Submission:

>>snip..
>> However, after the access authentication, if the network determines
that the attached >>node does not require PMIP service, it send an
advertisement containing the visitor 
>>network prefix and the mobile can kick start the MIP client
functionality.

How is this supposed to happen? What are you infering here about that
the network determines that the node doesn't need PMIP service?.  Are
you saying that the AAA profile of the "user" will have anything about
the terminal capabilities?

Regards
Osvaldo

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 16 Jan 2007 09:11:17 -0800 (PST)

Hi Osvaldo,

> the terminal capabilities?

That is one way to achieve that. But, I do realize the importance of
keeping that logic in the mobile. For this, we need some kind of
capability exchange messages between the HA and a MIP6 MN. Currently,
the proxy projects the mobile's home prefix or the local vistor network
prefix. To do this based on the mobile's capability is bit tricky. We
can probably add an option to Router Solicitation and Router Advertisement
messages.

Its a desirable feature. But, typically in a managed network, operators
like to control this aspect and if the network offers the mobility, what
is the point in enabling the mobile to use mobility service from the
same home agent ? Any deployment value ?

We will think a bit more on this.

Thanks
Sri

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Tue, 16 Jan 2007 19:37:51 +0100

Hi Sri,

On 1/15/07, Sri Gundavelli <[email-masked]> wrote:
> and the proxy mobile agent.

This is true also for HA and AAA in MIP6 bootstrapping, but a similar
discussion was held in DIME meeting in SD.

Basically, in Diameter MIPv6 application the current assumption is
that authentication and authorization are performed by different AAA
servers: this means that a AAA server may receive a MIP6 authorization
request for a specific MN from a trusted HA. However, some folks in
DIME WG raised the issue that the AAA server does not have any state
about the authentication of the MN and therefore the AAA server should
not trust the HA for that particular MN.

The discussion is still open in DIME, but I think the same comment
applies here. The HA trusts the PMA but does not have any specific
information about the MN authentication/authorization. Are we all fine
with this model? Just raising the issue, I still want to think about
it and continue the discussion in DIME.

--Gerardo

> That is the stated assumption.

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 16 Jan 2007 11:07:03 -0800 (PST)

Hi Gerardo,

> it and continue the discussion in DIME.

Proxy Mobile IPv6 is targetted for operator managed networks. Its
under a single administrative control that all these core services
Home Agent, Proxy Mobile Agents are deployed. The network provisions
the identify of the mobile nodes and their corresponding home
address/prefix, that are entitled for this proxy service. When
the mobile attaches to any access link, access authentication ensures
a mobile with the right credentials and identity is accessing the
network. Further, the core parameters for the mobility service, such
as its anchored home agent or optionally home prefix/etc are all
derived from the configured mobile's policy profile. This information
is required for the proxy mobile agent to signal the home agent and
create the routing state at both the ends. So, there is a chain of
trust that we cannot ignore. There are some special services such as
proxy mobile agent and home agent that every one needs to trust. 
For the given deployment, the trust model is sufficient and just
perfect. In today's SP/Enterprise deployments, many services have
special privileges and there is nothing wrong with that model, IMHO.

Regards
Sri

---

From: "Mohamed Khalil" <[email-masked]>
Date: Tue, 16 Jan 2007 13:31:35 -0600

The security model should take in account that the PMA could be
compromised and should take in consideration the following:
1- checking that the PMA is authorized to do the authentication on
behalf of the MN.
2- Authenticating the MN.

-----Original Message-----
From: Gerardo Giaretta [mailto:[email-masked]] 
Sent: Tuesday, January 16, 2007 12:38 PM
To: Sri Gundavelli
Cc: netlmm
Subject: Re: security... [netlmm] I-D Submission:

Hi Sri,

On 1/15/07, Sri Gundavelli <[email-masked]> wrote:
> >> between  the HA and the Proxy Mobile Agent. PMA is a special entity

> >> in the PMIP  network that has privileges send proxy registrations. 
> >> Now, what is  missing here.
> >
> This solution requires an established trust between the home agent and

> the proxy mobile agent.

Basically, in Diameter MIPv6 application the current assumption is that
authentication and authorization are performed by different AAA
servers: this means that a AAA server may receive a MIP6 authorization
request for a specific MN from a trusted HA. However, some folks in DIME
WG raised the issue that the AAA server does not have any state about
the authentication of the MN and therefore the AAA server should not
trust the HA for that particular MN.

The discussion is still open in DIME, but I think the same comment
applies here. The HA trusts the PMA but does not have any specific
information about the MN authentication/authorization. Are we all fine
with this model? Just raising the issue, I still want to think about it
and continue the discussion in DIME.

--Gerardo

> In any proxy model, there is a 3rd entity and that needs to be 
> trusted, that is the nature of the solution.
>
> Lets for a second, talk about RFC-3963. The mobile sends a BU with the

> MNP option containing the prefix that belongs to some other MR. How 
> does the HA authorise this ? There could be 100's of LFN's on those 
> prefixes and if the trust between the HA-MR is compromised, all those 
> nodes connectivity is in question. Same thing here, we require proper 
> security state between the HA and the PMA's. There needs to be IPSec's

> configured statically or through IKEv2 for this to work.
>
> Sri
>
>
>
>
> The draft
> suggests the use for the same. However, it is optional. If the home 
> agent can use LDAP or local policy store, there is no need for AAA.
>
>
> Sri
>
>

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Tue, 16 Jan 2007 19:14:28 -0500

Hi, Vidya,

Please let me make few comments. Please see inline. 

Regards,
Ajoy  

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Monday, January 15, 2007 2:24 PM
To: Julien Laganier; [email-masked]
Subject: [netlmm] Role of MIP6 in PMIPv6 document (was RE:
PMIP/CMIPinteractions)

All,
While we all believe that PMIPv6 must not preclude the use of MIP6 in
the same network, I would encourage everyone to focus on the design of
PMIPv6 itself, rather than on the interactions between the two protocols
in the protocol document. 

Ajoy-> Agree. We should first focus on PMIPv6 protocol design. I would
suggest that we should also look into the 
architectural concept such as separations of control plane and bearer
plane. These are useful concepts are  
SDO's are moving in this direction as well. For example, WIMAX has
defined DP (decision point) and EP (enforcement point). Similarly, 3GPP
has defined MME and UPE entity that differentiates bearer and control
plane processing. If the protocol is defined to provide separation
between 
BP and CP, it will be simpler to map to the split architecture.    

In part, the terminology being all MIP6-based in this draft seems to be
causing some confusion. For instance, there seems to be some confusion
on the binding cache of MIP6 and PMIP6 - these are independent and the
two protocols have different security models. 

Vidya

> I share entirely your views on how PMIP will interact with host-based 
> MIP (or CMIP.)
> 
> Best,
> 
> --julien
>

---

From: "Osvaldo Gonsa" <[email-masked]>
Date: Wed, 17 Jan 2007 09:43:48 +0100

Hello Sri, and thanks for you reply, below are some more comments

Regards
Osvaldo 

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Tuesday, January 16, 2007 6:11 PM
To: Osvaldo Gonsa
Cc: netlmm
Subject: RE: security... [netlmm] I-D
Submission:draft-sgundave-mip6-proxymip6-01.txt

Hi Osvaldo,

That is one way to achieve that. But, I do realize the importance of
keeping that logic in the mobile. For this, we need some kind of
capability exchange messages between the HA and a MIP6 MN. 

OG>> I think that this capability exchange between the HA and MIP6 MN
must be part of the basic protocol. If my memory doesn't fails me, one
of the objectives of the netlmm protocol should be to accommodate
terminals irrespective of whether they are MIP6 capable or not and to
proceed accordingly the network must know the terminal capabilities.
However putting this information into a AAA is not helpful since as I
said before, this information only cover Users parameters and not
terminals. Also you cannot rely on lower levels mechanisms (like SBC-REQ
and SBC-RESP in 802.16e), so I will be interested into know how this is
tackled.

Currently, the proxy projects the mobile's home prefix or the local
vistor network prefix. To do this based on the mobile's capability is
bit tricky. We can probably add an option to Router Solicitation and
Router Advertisement messages.

OG>> For this type of approach then the network will depend on the
terminal to respond to an advertised PMIP domain identifier and the
terminal will suppress MIP6 messages!? IMHO this is not feasible and is
a risky proposition since then you will require that the terminals
stacks are changed to accommodate PMIP...

OG>> Reduced signalling between PMIP entities and the HA comes to my
mind and in shared networks that might be a desired feature.

OG>> Thanks, please keep us posted
Best regards

Osvaldo

Thanks
Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Jan 2007 14:53:16 +0100

Sri Gundavelli wrote:
>>> This solution requires an established trust between the home 
>>> agent and the proxy mobile agent.
>> 
>> This is true also for HA and AAA in MIP6 bootstrapping, but a 
>> similar discussion was held in DIME meeting in SD.
>> 
>>  that authentication and authorization are performed by different 
>> AAA servers: this means that a AAA server may receive a MIP6 
>> authorization request for a specific MN from a trusted HA. However,
>>  some folks in DIME WG raised the issue that the AAA server does 
>> not have any state about the authentication of the MN and therefore
>>  the AAA server should not trust the HA for that particular MN.
>> 
>>  information about the MN authentication/authorization. Are we all
>>  fine with this model? Just raising the issue, I still want to
>> think about it and continue the discussion in DIME.
>> 
> 
> 
> address/prefix, that are entitled for this proxy service. When the 
> mobile attaches to any access link, access authentication ensures a 
> mobile with the right credentials and identity is accessing the 
>  proxy mobile agent and home agent that every one needs to trust. For
>  the given deployment, the trust model is sufficient and just

Sri, I agree with the above paragraph completely _iff_ the draft is
informational scope.

It is very true that in _some_ contexts access authentication and
mobility deployment is controlled by a single entity, with equipment
from a single vendor.

It is also very true that in _some_ contexts access authentication
happens with a AAA-based method (EAP+Diameter, or PANA+Diameter).

However, in the context of a STandards Track netlmm solution, it may
very well be that the access auth and mobility management are performed
by different entities, with strong interoperability needs.  It is also
one of this group's goals to accommodate several types of access links,
specifically those who don't use EAP+Diameter for access auth are included.

I really don't see any reason to specify a netlmm solution if there's no
interoperability need for its entities.  If an operator needs a PMIPv6
solution and a vendor sells it then so be it, I agree with it - a very
good win-win situation between a customer and a provider.  But not to
rubber stamp that solution as the IETF solution.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Jan 2007 14:53:51 +0100

> 2- Authenticating the MN.

I agree.

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 17 Jan 2007 08:19:48 -0800 (PST)

Hi Alex,

On Wed, 17 Jan 2007, Alexandru Petrescu wrote:

>>  Proxy Mobile IPv6 is targetted for operator managed networks. Its under a
>>  single administrative control that all these core services Home Agent,
>>  Proxy Mobile Agents are deployed. The network provisions
>>  address/prefix, that are entitled for this proxy service. When the mobile
>>  attaches to any access link, access authentication ensures a mobile with
>>  the right credentials and identity is accessing the network. Further, the
>>  core parameters for the mobility service, such
>>  as its anchored home agent or optionally home prefix/etc are all derived
>>  from the configured mobile's policy profile. This information

Alex, this is not about interoperability. Its about trusting one
entity by the other entity.  When the Proxy Mobile IP agent sends
a BU with a specific NAI, should the Home Agent permit this request.
Its a policy check. Its a simple trust relation betweek two entities.
We cannot look at these core service providing entities as just another
set of mobile nodes. These have higher privileges. PMIP deployment
is not about mobility from starbucks. This is for a managed operator
network.

Other way to look at this. The mobile in PMIP network is a simple IPv6
host, it is not involved in MIP signalling. It does not even know it
moved from its home LAN. Given this, why should the mobile's security
key be involved ? It did not ask for mobility ? The network is doing
the mobility, by the way of managing routes. Like a MAR provides a
route for a LFN in its MNP, there is no trust relation between the
LFN and the home agent.

We cannot mix every thing and say, there is no security. Access
Authentication ensures that. Every thing is driven from there.
There is a chain of trust and security is built on that. There
is MN-AR trust relation and there is AR-HA trust relation and
a model of transitive trust is present in this solution.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 31 Jan 2007 10:23:18 -0800

catching up with some old emails....

Gerardo Giaretta wrote:

> MN via RFC 3775 signaling? 

Very much. The binding cache entry can be updated either
using a binding update from the mobile node or a proxy
binding update from a PMA. IMO, this should be supported.

> It does seem a big depart from RFC 3775
> security model.

As long as the HA sees the PMA as being authorized to
send proxy binding updates for the mobile node's home
address, we don't break the security model assumed in
RFC 3775.

> cache entry mentioned above (i.e. the CoA of the PMA)?

No. Once the binding cache entry has been updated using
a proxy BU, and if the home agent receives a
de-registration BU from the mobile node after that, it
should just send a binding ack back to the mobile node
with the success status '0'.

And yes, we need a some more detail on the home agent
which describes how it should process proxy binding
updates and binding updates that update the same binding
cache entry.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 31 Jan 2007 16:03:58 -0800

Hello,

I agree with George here. It should work.

However, an explicit indication to the mobile node to not
use CMIP when PMIP is available would be a good idea. But
there are many ways of doing this. A flag in the router
advertisement would work. Link specific mechanisms
specified in the respective SDOs (whoever adopts PMIPv6)
would work too.

Vijay