Subject: [netlmm] AD review of draft-ietf-netlmm-proxymip6, batch 1

From: Jari Arkko <[email-masked]>
Date: Thu, 03 Jan 2008 00:30:42 +0100

My AD review of this document is ongoing. I am sending the first batch
of comments and questions in this e-mail in order to get the discussion
about these issues started and the possibly necessary document changes
done. I hope to send the rest of my review in the coming days.

Note that I'm currently somewhere in Section 5. It is very likely that
some of the questions below will be answered by the rest of the document.

Technical:

>    Mobile Node (MN)
>
>       Throughout this document, the term mobile node is used to refer to
>       an IP host whose mobility is managed by the network. 
s/host/node/ -- there should be nothing that prevents a router
benefiting from this as well, as long as it it still has the right
prefix as it moves around.

>    Mobile Node (MN)
>
>       Throughout this document, the term mobile node is used to refer to
>       an IP host whose mobility is managed by the network.  The mobile
>       node may be operating in IPv6 mode, IPv4 mode or in IPv4/IPv6 dual
>       mode.  The mobile node is not required to participate in any
>       mobility related signaling for achieving mobility for an IP
>       address that is obtained in that Proxy Mobile IPv6 domain.  This
>       document further uses explicit text when referring to a mobile
>       node that is involved in mobility related signaling as per the
>       Mobile IPv6 specification [RFC-3775 <http://tools.ietf.org/html/rfc3775>].
>   

The last sentence is unclear. What explicit text? The problem is that
you are using the term "mobile node" in two different meanings in this
paragraph. One is the actual mobile node unaware of Mobile IPv6, and the
other one is the proxy that pretends to be a mobile node on behalf of
the unaware node.

>    Mobile Node's Home Address (MN-HoA)
Why do we need this concept, if the we offer each mobile node a full
prefix? In any case, the network is incapable of known what address(es)
the mobile node chooses to use in IPv6.

>             Figure 3: Mobile Node Handoff - Signaling Call Flow

This figure shows an orderly sequence of events. In real life, things
may not be so well ordered. Detachment from a previous link may be
detected later than attachment to a new link. I hope the protocol
details later in the document make it clear that such cases can also be
handled.

The second worry that I have here is about the router solicitations.
Under what conditions will a normal ND implementation send out a router
solicitation that appears to be necessary here so that the new default
router can be learned? Is there something that you have to assume beyond
RFC 2461/4861?

> IPsec is the default security mechanism for
> securing the signaling messages.  However in certain deployments of
> this protocol, other security mechanisms MAY be applied and the
> signaling messages must be protected using the semantics provided by
> that respective mechanism.  The specification of the other security
> mechanisms are beyond the scope of this document
This is vague and unnecessary. Please rewrite as "That is, IPsec is the
mandatory to implement security mechanism. However, additional documents
may specify alternative mechanisms."

> Therefore, the local mobility
> anchor MUST allow only authorized mobile access gateways to create
> binding cache entries on behalf of the mobile nodes.

I believe it would be better to restrict this further. The statement
above reads like an authorization to do anything, and this may not be
desirable particularly in configurations that involve MAGs and host
Mobile IPv6 implementations served by the same home agent.

Here's a potential rewrite:

Therefore, the local mobility anchor MUST restrict the creation 
and manipulation of proxy bindings to specifically authorized
mobile access gateways, mobile nodes, and prefixes.

> The actual
> mechanism by which the local mobility anchor verifies if a specific
> mobile access gateway is authorized to send Proxy Binding Updates on
> behalf of a mobile node is outside the scope of this document.  One
> possible way this could be achieved is by sending a query to the
> policy store, such as AAA.

This is problematic as the authorization check is a key feature of the
proxy functionality, and you cannot leave it unspecified. However,
specifying
a mandatory base requirement appears easy. Here's an attempt that continues
from where my previous comment ended:

The local mobility anchor MUST be locally configurable to authorize such
specific combinations. Additional mechanisms such as a policy store or AAA
may be employed, but these are outside the scope of this specification.

>    o  The Link-local address of the mobile node on the interface
>       attached to the access link.  This is obtained from the Link-local
>       Address option, present in the Proxy Binding Update request.
>   

Why is this information needed? Can we guarantee that an IPv6 host
always has
at most one of these?

>    Typically, the MN-Identifier is the key for locating a Binding Cache
>    entry.  However, when supporting multihoming there MAY be more than
>    one Binding Cache entry with the same MN-Identifier and in such cases
>    the entry can be located using any of the following key combinations:
>
>    o  MN-Identifier, MN-HNP
>
>    o  MN-Identifier, Proxy-CoA
>
>    o  MN-Identifier, MN-Interface-Identifier
>
>    o  MN-Identifier, Access Technology Type (When MN-Interface-
>       Identifier is not present)
>   
This seems somewhat ad hoc. Is there a better way to define how proxy
BCEs are looked up? E.g., MN-ID + ATT + MNIID.

Editorial:

> It is possible to support mobility for IPv6 nodes without
> host involvement by extending Mobile IPv6 [RFC-3775 <http://tools.ietf.org/html/rfc3775>] signaling
> messages and reusing the home agent.  This approach to supporting
> mobility does not require the mobile node to be involved in the
> exchange of signaling messages between itself and the Home Agent. 
Inconsistent capitalization of home agent.

> It is possible to support mobility for IPv6 nodes without
>    host involvement by extending Mobile IPv6 [RFC-3775 <http://tools.ietf.org/html/rfc3775>] signaling
>    messages and reusing the home agent.
s/and reusing the home agent/between a network node and a home agent/

>       Mobile Access Gateway is a function that manages the mobility
>       related signaling for a mobile node that is attached to its access
>       link.  It is responsible for tracking the mobile node's movements
>       on the access link and for signaling the mobile node's local
>       mobility anchor.
>   
Perhaps "... movements to and from the access link ... " (because the
MAG wouldn't
necessarily be responsible for L2 mobility on the link, for instance).

> This flag is enabled for
>       Binding Cache entries that are proxy registrations and is turned
>       off for all other entries that are created due to the
>       registrations directly sent by the mobile node.
Is the second part necessary? Suggest deleting "that are created due to
the registrations directly sent by the mobile node".

Jari

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

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 2 Jan 2008 17:00:30 -0800 (PST)

Hi Jari,

Thanks for the review. Please see inline.

Regards
Sri

> done. I hope to send the rest of my review in the coming days.

Thanks for your time on this.

> prefix as it moves around.

Thought about this. We thought, a router i.e., a host will multiple
interfaces, per definition is still an IP Host. Need to verify
this in the IP terminology specs. But, sure, we can change it.

> other one is the proxy that pretends to be a mobile node on behalf of

Explicit text to indicate if the mobile node is mobility aware or not
not. We do not use the term "mobile node" to refer to an proxy mobility
agent any where in the document. The term mobile node is always used to
refer to the end host and in some cases that end host is mobility aware.
We can rephrase this or remove the last line.

> the mobile node chooses to use in IPv6.

True. We dont really preserve the HoA. As such, the network may
not even be aware of the HoA that the MN generates, when using
3041. However, when supporting non-auto configuration based addressing,
IKEv2/DHCPv6, the network does provide mobility to a given address
and offcourse for the whole prefix. We thought its probably good to
keep the 3775 concept of a home address.

> details later in the document make it clear that such cases can also be

True. Figure-3 some what provides the high level protocol overview.
The sequence reflects only a specific scenario. We can add an explicit
line to state that the order may infact be different, the Registration
PBU from the nMAG may arrive before the de-registration PBU from the
pMAG.

> router can be learned? Is there something that you have to assume beyond 

Typically, a link flap/media change should trigger a RS. This should
be per 2461/4861. This really falls in the network triggers scope.
Truely, RS is not the only mechanism for the network to detect a new
node on the link and trigger the PMIP6 signaling.  The event could be
a simple network attachment event, access authentication event or
other SDO/link specific event. Additionally, if the mobile node has
DNAv6 stack, the RS trigger logic is bit different. So, the network
can react to any of these events. If you think, the document is
requiring RS as the only trigger, we need to update that and clearly
state that the network may depend on other events.

> may specify alternative mechanisms."

Sure.

> mobile access gateways, mobile nodes, and prefixes.

Sure.

> may be employed, but these are outside the scope of this specification.

Sure.

> Why is this information needed? Can we guarantee that an IPv6 host

This is related to the link-local address collision issue. Covered in
Sec 6.8. If DNAv6 is enabled on the mobile node, it may not trigger
the DAD procedure after it moves to the new link.  That leaves a
possibility of a link-local address collision on the P2P link shared
by the MAG and the MN. For solving this issue, we allow the MAG to save
it in the BCE, so that a new MAG will not configure the same link-local
address on its link after handoff. However, the link-local address option
is optional and is not mandated to be present in the signaling messages.
In access network where there is a possibility of link-local address
collision, this may be enabled. Sec 6.8 has related points.

> BCEs are looked up? E.g., MN-ID + ATT + MNIID.

MN-IID and HNP are optional, as the MAG may not predictably learn
them in all cases. The Proxy CoA address may be different after a
handoff. That leaves few combinations for the BCE lookup.
But, these are indeed unique for a BCE lookup. We can be silent and
leave this to implementations as well.

> Inconsistent capitalization of home agent.

Yes. Typo.

> s/and reusing the home agent/between a network node and a home agent/

Ok.

> necessarily be responsible for L2 mobility on the link, for instance).

Ok.

> the registrations directly sent by the mobile node".

Agree. We can take that out.

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 3 Jan 2008 10:15:07 +0200

> > may be employed, but these are outside the scope of this specification.

Local configuration would not suffice for authorization of MAG to send a PBU
for a given MN as MN's current attachment to the network cannot be stored in
a local configuration. "Query to the AAA store" was meant to capture that,
in an informative fashion. I personally prefer being informative (vague?)
rather than missing that point. Someone may have a better wording to improve
this tradeoff though.

> leave this to implementations as well.

We need to nail this down. We cannot be having a spec whose security relies
on undefined end-point identifier. It is one thing that we don't know what
to put in MN-id, but it is another thing that we don't know whether we use
MN-id or some combination of that with other IDs.

Given that some of the identifiers may be NULL depending on the scenario,
could this be what we need:

MN-ID + MNIID + HNP

Regards, and happy new year.

Alper

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 3 Jan 2008 07:38:45 -0800 (PST)

> rather than missing that point. Someone may have a better wording to improve

There are two things here. The MAG authorization and the issue of 
network having to ensure a given MN is attached to a given MAG.
The later is in the case of a untrusted or a compromized MAG sending
a false PBU. Local configuration should be sufficient for the
authorization. For the later, for eliminating the threat, the network
can query the AAA to ensure the MN is attached a given access network.
This is captured in the security section, as this is really a residual
threat.

> MN-id or some combination of that with other IDs.

MN-Id is the stable identifier. How ever, there could be multiple
sessions for a given MN and the combination of IID or HNP will
act as the selectors for identifying the specific mobility session.

> Regards, and happy new year.

Happy New Year !

Sri

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 3 Jan 2008 19:10:40 +0200

Hi Sri,

> This is captured in the security section, as this is really a residual

Actually this is all about authorization. When the LMA receives a PBU,
before LMA executes the update it needs to check if the MAG who sent it was
authorized to generate such an update. 
- Is this node allowed generate any PBUs (local config can help with that)
- Is this node allowed to generate a PBU on behalf of this particular MN
(AAA comes into the picture)

The latter is not that residual if you consider the deployments where MAGs
and LMAs belong to different domains.

As long as we have that captured somewhere, that's fine.

> act as the selectors for identifying the specific mobility session.

I agree. We just need to document that.

Alper

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 3 Jan 2008 09:36:34 -0800 (PST)

Hi Alper,

> As long as we have that captured somewhere, that's fine.

I see your point, that its still an authorization. The minor
difference is that, that extra step of authorization for
MN presence is required when the MAG cannot be trusted, as
in deployments you pointed out.

We have captured this text, in anycase.

Thanks
Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 03 Jan 2008 11:09:14 -0800

> keep the 3775 concept of a home address.

PMIPv6 specifically allows for assigning a 128-bit address to the
mobile node instead of the home network prefix. So this is required.

>> mobile access gateways, mobile nodes, and prefixes.

hmm... The PMIPv6 specification assumes that only the MAGs modify
the binding cache entries. So the statement in the current draft
is correct. When you have a PMIPv6 LMA and MIPv6 HA co-located,
then the mobile node in addition to authorized MAGs is allowed to
modify the binding cache entry for the mobile node. We describe
this in the PMIPv6 - MIPv6 interactions document,
draft-giaretta-netlmm-mip-interactions-02.

Vijay

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 3 Jan 2008 12:13:37 -0800

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Thursday, January 03, 2008 11:09 AM
> To: Sri Gundavelli
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netlmm] AD review of draft-ietf-netlmm-proxymip6, batch
1
> draft-giaretta-netlmm-mip-interactions-02.

Even in that case as discussed in Vancouver it may not be the best
approach to have MAGs and MN to change the same BC entry. 

In the context of PMIPv6 base specification only authorized MAGs can
create and manipulate proxy bindings. I would therefore suggest the
following text based on Jari's text:

"
Therefore, the local mobility anchor MUST restrict the creation and
manipulation of proxy bindings for a specific mobile node and prefix to
specifically authorized mobile access gateways.
"

Sounds good?

Gerardo

---

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Jan 2008 15:31:25 +0200

Sri,

Thank you very much for your prompt responses to my reviews.

> this in the IP terminology specs. But, sure, we can change it.

The applicable definition would be in RFC 2460. A node with
multiple interfaces is not necessarily a router, a node which
forwards traffic between the interfaces is. In any case, from
a NETLMM perspective I don't think any of this matters. Just
say "an IP host or router" or "an IP node".

> We can rephrase this or remove the last line.

Please rephrase or remove. If you rephrase, please indicate what term
you use to refer "a mobile node that is involved in mobility related
signaling".

> keep the 3775 concept of a home address.

Strictly speaking, NETLMM does not operate on HoAs. But I looked at the
use of this term in the document, and its used in a few places where its
use does make sense as an example.

However, the similarity to the RFC 3775 concept is superficial and
potentially misleading. Given, for instance, the fact that the mobile
node can choose multiple addresses, and other parties are not
aware of them. I would suggest rephrasing the definition. Here's
an attempt:

MN-HoA is an address within a Mobile Node's Home Network Prefix, belonging
to a mobile node in a Proxy Mobile IPv6
domain. It is an address from its home network prefix obtained by
a mobile node in a Proxy Mobile IPv6 domain. The mobile node can
continue to use this address as long as it is attached to the
network that is in the scope of that Proxy Mobile IPv6 domain.
Note that unlike in Mobile IPv6, generally speaking only the
mobile node is aware of the specific address(es) it has chosen, whereas
the other parts of the system are only aware of the prefix.

> PBU from the nMAG may arrive before the de-registration PBU from the

It is sufficient to add text after the explanation of the figure.

(My reading of the rest of the document convinced me that you
have handled the other cases.)

>> Under what conditions will a normal ND implementation send out a
>> router solicitation that appears to be necessary here so that the new
>> default router can be learned? Is there something that you have to
>> assume beyond RFC 2461/4861?
>>
>

I do not think we need to require RS as the only trigger. What I would
like to be clear to the reader is that no special support beyond normal
RFC 4861 implementation is needed. Perhaps you could add some
text to the explanations around Fig 2/3 that the router solicitation
process is as defined normally by RFC 4861?

> collision, this may be enabled. Sec 6.8 has related points.

Ok,fine.

> leave this to implementations as well.

I do not think it helps to leave more things to implementations. The
BCE lookup is a fundamental operation, and it should be defined
crisply. I'm not necessarily looking for new fields of information
or changing the processing, but abstracting it in a better manner
and cleaning up the actual processing language so that it is
very clear what the lookup algorithm is.

For instance, "mn identifying material" = <"mn-id" + "mn-at" +
"mn iid or empty"> and then you use mn identifying material
and only that for the lookups. Or something along those lines...
details to be worked out here.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Jan 2008 15:31:31 +0200

Vijay, Sri,

> draft-giaretta-netlmm-mip-interactions-02.

I suspect that the authorization issue will come in IESG review if we
do not get it done now. I think the ability to prevent an enhanced
home agent implementation to accidentally allow MAG changing
regular mobile node BCEs is needed. But I don't think this will
be a problem; all that the base has to specify is that the LMA
has to know which set of mobile nodes it is allowed to do the
new type of authorization for. You can leave more complex
logic, such as moving from host based to netlmm domain
for the same device to the other document.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 14 Jan 2008 13:47:00 -0800

Jari,

> the other parts of the system are only aware of the prefix.

The PMIPv6 document supports assigning a 128-bit MN-HoA instead of
advertising a /64 MN-HNP. The current document assumes some kind
of link layer mechanism between the MN and the MAG to assign the
128-bit MN-HoA to the MN. The MAG may also know before sending a
Proxy BU whether it should be requesting for a 128-bit MN-HoA from
the LMA or a /64 prefix MN-HNP from the LMA. The LMA could override
the MAG's choice.

So it is not correct to say that the "parts of the system" are
only aware of the prefix.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Jan 2008 23:53:58 +0200

Vijay,

> only aware of the prefix.

Ok. There are legal configurations of NETLMM where some parts of the
system are only aware of the prefix.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 14 Jan 2008 14:03:45 -0800

> system are only aware of the prefix.

Of course. If the LMA assigns a /64 prefix and the MAG advertises
the same, then many parts of the system would not know which address
the MN configured.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Jan 2008 00:05:07 +0200

> the same, then many parts of the system would not know which address
Right. So lets make that clear when you define the term "MN-HoA" --
because this property is indeed different from base Mobile IPv6.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 14 Jan 2008 14:14:41 -0800

> because this property is indeed different from base Mobile IPv6.

hmm.... Lets say we use RFC 5026/4877 to assign the MIPv6 HoA.
IKEv2 configuration payloads are used to assign the 128-bit home
address for the mobile node. In this case it is only the Home
Agent and the Mobile Node that are aware of the 128-bit home
address.

In PMIPv6, when you assign the 128-bit home address (MN-HoA), it
would be the LMA, the MAG and the mobile node that are aware of
the MN-HoA.

In both cases, does any other part of the system care about the
address assigned to the mobile node?

I would actually claim that if there is a system where the PMIPv6
LMA and the MIPv6 HA are co-located, and the mobile node
transitions between using PMIPv6 and MIPv6, then the MIPv6 HoA
and the PMIPv6 MN-HoA are exactly the same.

Or am I off on a tangent? :)

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Jan 2008 00:38:15 +0200

> Or am I off on a tangent? :)
There is no argument about the possibility of configuring things so that
they are exactly the same. However,
the concept in NETLMM is different, can have very different implications
in some typical configuration and that needs to be clearly stated.

Jari

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 15 Jan 2008 00:26:17 -0800

Hi Jari,

Please see inline.

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Monday, January 14, 2008 5:31 AM
> To: Sri Gundavelli
> Subject: Re: [netlmm] AD review of 
> draft-ietf-netlmm-proxymip6, batch 1
> 
> Sri,
> 

Ok. Sure.

> you use to refer "a mobile node that is involved in mobility related

May be CMIP-MN, 

We can also remove it. Dont see a need for the term. In 6.14, we
have some reference to a MN that is disallowed Netlmm service, other
than that and in Introduction we dont talk about CMIP-MN. 

> the other parts of the system are only aware of the prefix.

Ok

> have handled the other cases.)

Ok. We will add an explicit note about the potential reordering.

> process is as defined normally by RFC 4861?

Ok

> details to be worked out here.

How about this:

+===================================+===================================+
|      HNP Non-Zero Value           |            HNP ::/0 Value         |
+===================================+===================================+
|  IID Option     |    IID Option   |    IID Option   |    IID Option   | 
|   present       |    not present  |   present       |   not present   |
+=================+=================+===================================+
|          Use MN-Id,               |   Use MN-Id,    |  Reg   |  Dereg | 
|         HNP for BCE lookup        |  IID, ATT for   | Message| Message|  
|                                   |  BCE Lookup     |        |        |
|                                   |                 +--------+--------+
|                                   |                 | Use    |  Use   |
|                                   |                 | MN-Id  | MN-Id, |   
|                                   |                 |        |Prxy-CoA|

+===================================+=================+=================+

Thanks
Sri

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Jan 2008 13:15:16 +0200

Sri,

> than that and in Introduction we dont talk about CMIP-MN. 

OK either way.

> Ok. We will add an explicit note about the potential reordering.

Good.

>> details to be worked out here.
This is an improvement, because for the first time I can actually grasp algorithm. However, we need to work on this still some more:

- If HNP is non-zero, wouldn't it suffice for the entire lookup? (Or does the MNID provide some sort of authorization function here?)

- In the right side of the table, I would simply define IID to be either the IID from L2 or an empty string. This would simplyfy the algorithm.

- I don't understand the logic in the table on what we have to do when IID is not present (or empty). Can you explain the rationale?

Jari

---

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

Hi Jari,

> - If HNP is non-zero, wouldn't it suffice for the entire lookup? (Or does the MNID provide some sort of authorization function here?)

MN-Id association is required to ensure we handle all LMA reboot
scenario's or prefix recycling issues. Secondly, from the point of
view of implementation, lets say, for scaling to 3 to 5 million
binding search, the lookup time is going to be extremly important
and the choice of the keys are critical. This is true for any choice
of data structure, AVL Tree .. Its easy to allow a search based on
key combination, but that requires threading based on each of the
key and thats very expensive. I'd expect implementations to some how
use MN-Id as one key for locating all BCE's for a given MN-Id and
further apply the above search criterial within. Else, to have this
many threads in an AVL or other data structure, one for MN-Id, ATT,
LLA ...etc, its a huge resource impact in terms of memory.

> - In the right side of the table, I would simply define IID to be either the IID from L2 or an empty string. This would simplyfy the algorithm.

May be I'm missing some thing about this empty IID string.
If the IID is an empty string, it amounts to no IID present,
and when multiple interface of same ATT are present, we will
have the issue of BCE lookup. Is it not the same as below.

> - I don't understand the logic in the table on what we have to do when IID is not present (or empty). Can you explain the rationale?

If the IID is not present, we do a simple lookup based on the
MN-Id. If the HI is set to "Handoff" and if there is only one
BCE entry found, we associate the request to that BCE. If the
HI="New", we create a new BCE. If the HI=Unknown, we wait for
a dereg or allow the LMA to create a new session.

Thanks
Sri