Subject: [netlmm] Some comments on draft-ietf-netlmm-proxymip6-00

From: "Julien Bournelle" <[email-masked]>
Date: Tue, 15 May 2007 10:26:37 +0200

Hi all,

 I read the draft and I have some minor comments and need some
clarifications:

 * First of all, there are some editorial nits but I guess this is due to the
fact that it is a -00 version.

 * In the introduction, it is written: "There also numerous
specifications enhancing
   Mobile IPv6 that can be re-used. ". What do you have in mind ?

 * You often refer to a "PMIP6 domain", "address that is obtained in
the local domain" etc. With the recent discussions on LMA, I'm a
little confused by what is exactly a PMIP6 domain. It would be good to
clarify this for the next version.

 * Section 3., it is written: "Once a Mobile Node enters its PMIP6
domain". I think you meant:
 "Once a mobile node enters a PMIP6 domain".

 * You refer in the draft both to MAG and PMA. From the terminology
section, MAG seems to be an entity whereas PMA is the function that
resides in the MAG but in the draft there are sometimes some
inconstencies. For example, in the section 3, it is written: "The
Proxy Mobile IPv6 scheme introduces a new function, the Mobile access
gateway".

 * You also have some text on IPv4, I think you should remove it since
the WG has decided
to move on with a companion document.

 * In section 3, it is written that a MAG acts as a default router on
the link. For my clarifications, I was wondering if it was a
requirement.

 * Section 4, I don't understand the following sentence: "The security
   association of the specific mobile node for which the signaling
   message is initiated is not required for protecting these messages."

 * Section 5.5, you mention NTP to synchronise clocks in a PMIP6
domain. I was wondering if PMA and MAG clocks should be synchronized
or if we only need to synchronize MAGs clocks.

 * Section 6. It is written: "This specification does not support
split links." As you mentionned just before "shared links", it may be
better to write "shared links".

 * Section 7. "This identity has a binding to a cryptograpic state".
Maybe, you should precise what do you mean by "cryptographic state"
here.

 and that's all for the moment,

 Best regards,

 -- Julien

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 15 May 2007 09:03:18 -0700

Hi Julien:

Thanks for the comments. Most of these editorial comments
have been addressed in the -01 rev that we have been working
on. Any case, please see inline.

Regards
Sri

> -----Original Message-----
> From: Julien Bournelle [mailto:[email-masked]] 
> Sent: Tuesday, May 15, 2007 1:27 AM
> To: [email-masked]
> Subject: [netlmm] Some comments on draft-ietf-netlmm-proxymip6-00
> 
> Hi all,
> 

We took care of this.

>    Mobile IPv6 that can be re-used. ". What do you have in mind ?

All the extensions to the base Mobile IPv6 specification, such as
DSMIP. We tried to justify the use of a Mobile IPv6 based solution
for NETLMM solution.

> clarify this for the next version.

This was the comment from Alice too. PMIP6 domain is a NETLMM domain
where the network-based solution is based on Proxy Mobile IPv6. We
used the phrase "PMIP6 domain" for referring to a NETLMM domain. Ok.
We will clarify it.

>  "Once a mobile node enters a PMIP6 domain".

ok.

> Proxy Mobile IPv6 scheme introduces a new function, the Mobile access

True. Need to fix it.

> to move on with a companion document.

We may have to have some references to IPv4, where ever its relevant.
The solution is certainly not in this document and we will make sure,
there is no ambiguity there.

> the link. For my clarifications, I was wondering if it was a

We have two options here, MAG acting as the default-router and the LMA
acting as the default-router. Note that the mobile node's home prefix
is hosted on the access link and so certainly the MAG can be the default
router. If we make the LMA as the default router, we may have to add
Proxy ND mechanisms. We think, making the MAG act as a default-router 
is a cleaner solution.

>    message is initiated is not required for protecting these 

The context was on the usage of MAG's Security Associations for protecting
the signaling messages, as supposed using a Per-MN SA. We need to rephrase
this.

> or if we only need to synchronize MAGs clocks.

All the entities in a NETLMM domain, the clocks for all the LMA's and
MAG's must be synchronized. The entities exchanging the signaling messages
must have their clocks synchronized.

> better to write "shared links".

Ok. But, there is a difference between shared links vs split links ?
Any ways, we dont support this and so we can change it.

> Maybe, you should precise what do you mean by "cryptographic state"

Ok.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 23 May 2007 19:32:28 +0200

Hi,

I have also some comments/questions. Sorry if some comments/questions
have been already raised.

*** New section with "Assumptions/Topics out of scope" ***
It would be helpful for the others SDOs, wanting to deploy PMIPv6 in
their architecture, or to know the topics which are treated in others
IETF proposals, to have quickly such a list.
As far as I have correctly read the proposal, here is a quick list:
o Assumptions
- Access authentication infrastructure/database used
- Implementation of the MN NAI Identifier option in the MIPv6 MN code
- Point to Point technology
- Per-MN-Prefix addressing model
o Out of scope
- Interaction between the AAA infrastructure and the MAG to get the MN's profile
- Authorization for MAG to send PBU on behalf a MN
- LMA discovery
- Sequence Number synchronization between MAGs
- PMIPv6/IPv6 mobility protocols (e.g. MIPv6, FMIPv6, HMIPv6, NEMO, ...)
- Route Optimization
- Detection mechanism of the loss of a visiting MN for the MAG

So, you should clearly remove the text concerning these points in the proposal.

*** p13, section 5 ***
"Typically, the local mobility anchor is provisioned with the list of
mobile access gateways authorized to send proxy registrations."
This is already done with the LMA's SPD where all the MAG are listed, isn't it?
If I am not wrong, this sentence should be replaced by:
"The local mobility anchor has the list of mobile access gateways
authorized to send proxy registrations in its SPD."

"When the local mobility anchor receives a Proxy Binding Update
message from a mobile access gateway, the message is protected using
the IPSec Security Association established between the local mobility
anchor and the mobile access gateway."
s/IPSec/IPsec :)

"This distinction is important for using the right security
association for validating the Binding Update and this is achieved by
relaxing the MUST requirement for having the Home Address Option
presence in Destination Options header and by introducing a new flag
in the Binding Update message."
To avoid reflecting attacks from a compromised MAG, it would be useful
to add this requirement:
"If an Alternate Care-of Address option is used in the PBU, the LMA
must check that the address in this option is the same as the one in
the source address field in the IPv6 Header (i.e. the PCoA)"

"The local mobility anchor as a traditional IPSec peer can use the SPI
in the IPSec header [RFC-4306] of the received packet for locating the
correct security association and for processing the Proxy Binding
Update message in the context of the Proxy Mobile IPv6 scheme."
s/IPSec peer can use the SPI in the IPSec header [RFC-4306]/IPsec peer
can use the SPI in the IPsec header [RFC-4301]

*** section 5 ***
It would be useful to have a figure of the PBU and the PBA like for
the BU and the BA in the RFC 4877 to know what options are used and
what is there inside.

BTW, it is not clear whether or not the MN's HoA is in the PBU.
Is it just the MN's NAI?
Is there the MN's HoA too (i.e. included in the Home Network Prefix Option)?

*** p14, section 5.1 ***
Is the Binding Cache still indexed by the MN's HoA?

"A flag indicating if IPv6 HoA mobility is accepted.  If this flag is
set, the relevant IPv6 HoA fields in this data structure have to be
set to the configured values.  If this flag."
I didn't understand what is the functionality of this flag.
BTW, the last sentence is not finished ;)

"This MN-Identifier is obtained from the NAI Option present in the
Proxy Binding Update request [RFC-4285]."
s/[RFC-4285]/[RFC-4283]

"The IPv6 home network prefix of the mobile node."
If you have the HoA and the home network prefix length of the MN, you
don't need to store the home network prefix.

"Tentative Binding Cache Entry"
I didn't understand whether the fields defined in the proposal have to
be add just for this entry or for a classical MIPv6 entry too.
What is the relationship between a MIPv6 Binding Cache entry and a
Tentative Binding Cache entry in a LMA? Clarifications are needed I
think.

*** p24, section 6.4 ***
"If the access link connecting the mobile access gateway and the
mobile node is a shared-link, the mobile access gateway MUST ensure
that each of the mobile node that is attached to that link receives
Router Advertisements with its respective home network prefix as the
on-link prefix.  For this to happen, the mobile access gateway MUST
unicast the Router Advertisement to the mobile node.  The destination
field of the link-layer header in the Router Advertisement MUST be the
mobile's node's interface physical/MAC address and however, the
destination field in the IPv6 header set to the all-nodes-multicast
address."
Given the "Point-to-Point" assumption, this text should be removed

*** p25, section 6.5 ***
"However, if the link between the mobile node and the mobile access
gateway is a shared link and if a DNAv6 capable mobile node moves from
one access link to the other, the mobile node may not detect a link
change due to the optimizations from DNAv6 and hence there is a
possibility of the link-local address collision on the connected
access link, One of the work around for this issue to the set
following flag on the mobile node, DNASameLinkDADFlag to TRUE and that
will force the mobile node to redo DAD operation even when DNAv6
detects no link change."
Given the "Point-to-Point" assumption, this text should be removed.

Best regards.

JMC.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 24 May 2007 00:15:16 -0700

Hi Jean-Michel,

Thanks for the detailed review comments. 
Please see inline.

Regards
Sri 

> From: Jean-Michel Combes [mailto:[email-masked]] 
> Sent: Wednesday, May 23, 2007 10:32 AM
> To: Sri Gundavelli
> Cc: Julien Bournelle; [email-masked]
> Subject: Re: [netlmm] Some comments on draft-ietf-netlmm-proxymip6-00
> 
> Hi,
> 

> - Per-MN-Prefix addressing model

Yes.

> - Authorization for MAG to send PBU on behalf a MN

Yes.
The LMA may be configured with list of MAG's that are allowed to
send proxy BU messages. This translates to authorization to some
extent. But, not of the form where the MAG is requiring authorization
from the MN to send PBU. 

> So, you should clearly remove the text concerning these 

Yes. Sure, will see this in the -01 version. We are getting some good
feed back from the current discussions and we are waiting for some
threads to close.

> authorized to send proxy registrations in its SPD."

The SPD entries generally identify the MIP signaling messages for
protection and are not very granular enough. So, this authorization
needs to be done at the application level.

Ok. 

Ok. 

Ok.

> the BU and the BA in the RFC 4877 to know what options are used and

Yes. As we did in the IPv4 support draft, we will do the same for this
draft. I've written it down. Good point.

> Is there the MN's HoA too (i.e. included in the Home Network 

This is a popular issue, raised by JinHyeock. There are two cases and
we will spell it out the PBU contents and the flows for each case.

> Is the Binding Cache still indexed by the MN's HoA?

It should be NAI. HNP is relevant as we support Per-MN-Prefix model.
HoA may not be relevant for this draft.

> BTW, the last sentence is not finished ;)

We support the mobiles operating in IPv4-only, IPv6-only or dual-stack
mode. These flags identify what is enabled. Per Jari's review comments,
we will not have this, as these should be part of DSMIP6 draft, it
enabled the BCE to support both IPv4 and IPv6 protocols. 

> Proxy Binding Update request [RFC-4285]."

Yes. Good catch.

> don't need to store the home network prefix.

Overload HoA for both ? May be too much of computation each time the
HNP is used. Since, we support per-mn-prefix model, we can just have
both the prefix and the length fields.

> Tentative Binding Cache entry in a LMA? Clarifications are needed I

This will not be there in the draft. This is for supporting the case
of collocated LMA/HA. If there is a binding from a mobile node operating
in CMIP mode and later if it moves to a PMIP domain, should the LMA
remove the binding or wait for the dereg message from the MN. We tried
to address that issue. Now, this solution is part of the MIP6-PMIP
interworking draft draft-devarapalli-netlmm-pmipv6-mipv6-01.txt.

> Given the "Point-to-Point" assumption, this text should be removed

Sure.

> Given the "Point-to-Point" assumption, this text should be removed.

Sure.

Jean-Michel, thanks for some very good comments, as always !
Appreciate it.

Regards
Sri