Subject: [netlmm] Review of draft-singh-netlmm-protocol-00

From: Christian Vogt <[email-masked]>
Date: Tue, 23 Jan 2007 22:27:45 +0100

Authors, Folks,

following my previous email, here is the review of draft-
singh-netlmm-protocol-00, which Vidya and Phil asked me to
write.

The draft introduces a "PMIP client", which registers the
mobile node's current point of attachment with a Local
Mobility Anchor (LMA) on behalf of the mobile node.  The
PMIP client shares an SA with the LMA, whereas a typical
access router does not.  The intent is to keep any PMIP-
specific functionality on the access routers small or even
avoid it, and to use SAs only between the PMIP client and
the LMA.

An inherent concept of this protocol proposal is that it
allows only one PMIP client to proxy a given mobile node,
irrespective of which PMIP link that mobile node currently
attaches to.  While this idea nicely suits the conventional
notion of a "proxy", it may lead to increased signaling
overhead and latency.  According to the draft, the mobile
node's serving access router must first contact the mobile
node's serving PMIP client, and it can update the LMA only
then.  The draft specifies an alternative protocol where the
PMIP client updates the LMA directly, but the LMA's response
must still be communicated back to the access router by the
PMIP client.  So the signaling overhead and latency is the
same in both versions.  Since the mobile node may move
further and further away from its serving PMIP client while
roaming across the PMIP domain, it may be hard to meet the
Requirements document's goal #1, which calls for a maximum
handover latency of 70 ms.

Robustness and efficient PMIP client failover is another
challenge that one ought to consider when the serving PMIP
client cannot change while the MN moves across the PMIP
domain.  This applies to LMA failure as well, however, and
is hence a more general issue.  Of course, a sub-optimal
fall-back solution would always be for the MN to re-
authenticate to the domain and so be assigned a different
PMIP client.

While the security between a MN and an access router can
assumed to be anchored at the link layer or the movement
detection signaling at the IP layer, the draft currently
does not attend to the security of signaling between a
mobile node's serving access router and PMIP client.  How
can the PMIP client verify that the trigger from the access
router is legitimate?  The access router may have been
subverted by an attacker and it may cooperate with the
attacker, or the attacker itself may impersonate an access
router and as such contact the PMIP client.  The PMIP client
could thereby be tricked to direct packets away from the
legitimate recipient, allow the attacker to act as a man in
the middle in the communications of a victim on a different
link, or flood a victim with packets from a third party.

The security between the mobile node's serving access router
and PMIP client is less of an issue when the PMIP client is
colocated with the access router.  But note that, once the
mobile node moves to a different access router, the two
entities are no longer colocated.

The straightforward solution is probably to set up security
associations between each pair of access router and PMIP
client.  This would do away with the threat of access router
impersonation (although it would not help against access
router subversion).  But it might lead to a scalability
issue.

Another concept of the protocol proposal is that, for a
given mobile node, the security association through which
the mobile node ends up being proxied to the LMA is unique.
The consequence of this is that there either is only a
single PMIP client in the PMIP domain, and all signaling for
all MNs goes through the single SA between that PMIP client
and the LMA.  Or the security associations between a PMIP
client and the LMA cannot be preestablished, but rather
needs to be set up on a per-mobile-node basis.  The
rationale behind this idea is to adopt the RFC 3775/3776
concept of having one SA per mobile node.  Yet I think the
price to be paid for this concept is too high, due to the
following reasons:

    - An inherent property of localized MM is that one can
    assume that it is used in a single administrative domain.
    (Inter-domain handovers can be considered separately.)
    This means that entities within the PMIP domain know each
    other and, once mutually authenticated, can trust each
    other.  (Access points and other equipment which an
    attacker could easily get his hands on are an exception
    as they are at an increased risk to subversion.)  The
    per-MN SAs in RFC 3775 are necessary because no entities
    from within the access network are involved in a home
    registration.  But in a localized MM domain, per-MN SAs
    are not required IMO.

    - Using per-MN SAs for PMIPv6 increases the number of SAs
    significantly.  This might be a scalability issue.
    Moreover, since each SA needs to be set up through IKE,
    and each such set-up requires a-priori interaction with
    the AAA infrastructure, signaling overhead and latency
    increases as well.

In summary, I would recommend three changes to the protocol
proposal:

    - Use a single, possibly pre-configured SA between each
    PMIP client and an LMA.  The LMA trusts all signaling
    that is protected through this SA, even though it may
    pertain to different MNs, and even though different
    registrations for the same MN may arrive through
    different such SAs.

    - Allow the serving PMIP client to change while the MN
    roams across the PMIP domain.  E.g., the PMIP client
    might always be colocated with the currently serving
    access router.

    - Address the security for signaling between the access
    router and the PMIP client.  It may be sufficient if you
    assume the two entities are colocated and leave the
    protocol between the access router and an external PMIP
    client as future work.

Finally, I would like to emphasize the clean separation of
localized MM and global MM in this draft.  According to
section 4.4., it is the MN's responsibility to initiate RFC
3775 signaling with its (global) home agent when moving from
one LMA to a different LMA in a possibly different PMIP
domain.

Best regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

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

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Wed, 24 Jan 2007 19:37:25 -0500

Hi,  Christian, 

Thanks for reviewing the draft. Please find inline responses. 

Regards,
Ajoy 

-----Original Message-----
From: Christian Vogt [mailto:[email-masked]] 
Sent: Tuesday, January 23, 2007 3:28 PM
To: Bedekar Anand-ABEDEKA1; Singh Ajoy-ASINGH1; Kalyanasundaram
Suresh-CSK090; Netlmm
Cc: Vidya Narayanan; Roberts Phil-APR042; James Kempf;
[email-masked]; McCann Peter-A001034
Subject: Review of draft-singh-netlmm-protocol-00

Authors, Folks,

following my previous email, here is the review of draft-
singh-netlmm-protocol-00, which Vidya and Phil asked me to write.

The draft introduces a "PMIP client", which registers the mobile node's
current point of attachment with a Local Mobility Anchor (LMA) on behalf
of the mobile node.  The PMIP client shares an SA with the LMA, whereas
a typical access router does not.  The intent is to keep any PMIP-
specific functionality on the access routers small or even avoid it, and
to use SAs only between the PMIP client and the LMA.

An inherent concept of this protocol proposal is that it allows only one
PMIP client to proxy a given mobile node, irrespective of which PMIP
link that mobile node currently attaches to.  While this idea nicely
suits the conventional notion of a "proxy", it may lead to increased
signaling overhead and latency.  According to the draft, the mobile
node's serving access router must first contact the mobile node's
serving PMIP client, and it can update the LMA only then.  The draft
specifies an alternative protocol where the PMIP client updates the LMA
directly, but the LMA's response must still be communicated back to the
access router by the PMIP client.  So the signaling overhead and latency
is the same in both versions.  Since the mobile node may move further
and further away from its serving PMIP client while roaming across the
PMIP domain, it may be hard to meet the Requirements document's goal #1,
which calls for a maximum handover latency of 70 ms.

Ajoy-> We allow buffer forwarding from source to target AR during
handover, so the data flow will continue from sourceAR to targetAR while
the PMIP signaling is in progress. Thus we do not expect any handover
latency due to this, and the impact of the PMIP signaling on the
handover latency itself is less critical. So we do expect that the
latency requirement can be met through such data forwarding between
sourceAR and targetAR. 

Robustness and efficient PMIP client failover is another challenge that
one ought to consider when the serving PMIP client cannot change while
the MN moves across the PMIP domain.  This applies to LMA failure as
well, however, and is hence a more general issue.  Of course, a
sub-optimal fall-back solution would always be for the MN to re-
authenticate to the domain and so be assigned a different PMIP client.

Ajoy->  I agree. When the PMIP clients are centralized boxes, we expect
that these boxes are carrier-grade with a high degree of reliability and
availability. So the PMIP clients should have failover mechanisms, such
as, standby cards.  I think this is a fairly well understood area
nowadays. Note that PMIP client function will be co-located on existing
control plane processing boxes supported in specific radio technologies.
So, we are not introducing new box that we have to worry about. Also,
unlike LMA, PMA client does not need to handle any bearer packets hence
we can't really compare this with LMA. 

While the security between a MN and an access router can assumed to be
anchored at the link layer or the movement detection signaling at the IP
layer, the draft currently does not attend to the security of signaling
between a mobile node's serving access router and PMIP client.  How can
the PMIP client verify that the trigger from the access router is
legitimate?  The access router may have been subverted by an attacker
and it may cooperate with the attacker, or the attacker itself may
impersonate an access router and as such contact the PMIP client.  The
PMIP client could thereby be tricked to direct packets away from the
legitimate recipient, allow the attacker to act as a man in the middle
in the communications of a victim on a different link, or flood a victim
with packets from a third party.

The security between the mobile node's serving access router and PMIP
client is less of an issue when the PMIP client is colocated with the
access router.  But note that, once the mobile node moves to a different
access router, the two entities are no longer collocated.

The straightforward solution is probably to set up security associations
between each pair of access router and PMIP client.  This would do away
with the threat of access router impersonation (although it would not
help against access router subversion).  But it might lead to a
scalability issue.

Ajoy-> I agree that the straightforward solution would be to use
security associations between AR and PMIP client pairs, e.g. using
IPSec. Given that PMA and AR will be part of same domain, establishing
security association between PMA and AR should not be a big issue. As I
mentioned above, the PMIP client will likely be collocated with other
functions in specific wireless technologies, so there will likely be
security associations for the execution of those functions anyway. So
the PMIP client-to-AR association won't be an extra burden beyond what
will be needed anyway. 

Another concept of the protocol proposal is that, for a given mobile
node, the security association through which the mobile node ends up
being proxied to the LMA is unique.
The consequence of this is that there either is only a single PMIP
client in the PMIP domain, and all signaling for all MNs goes through
the single SA between that PMIP client and the LMA.  Or the security
associations between a PMIP client and the LMA cannot be preestablished,
but rather needs to be set up on a per-mobile-node basis.  The rationale
behind this idea is to adopt the RFC 3775/3776 concept of having one SA
per mobile node.  Yet I think the price to be paid for this concept is
too high, due to the following reasons:

Ajoy-> Ok, agree. Ideally it will be better to have single SA between
PMA and LMA. But please note that  
per-MN SA increases reuse of existing protocol, and this is a desirable
outcome per the requirements draft.
Note that a standard MIPv6 HA handles per-MN security associations
already, so if the LMA has to handle per-MN security associations, it
won't be any worse off than a standard MIPv6 HA. However, we are open to
make this change if there is such interest in WG, but we do believe
there is merit in making LMA as close to MIPv6 HA as possible. 

Ajoy-> See above. 

Ajoy-> OK, this can be considered as an enhancement to our proposal. Do
you see any need to consider 
this in base draft, or dealt with as an add-on? 

Ajoy-> Please see my comment above regarding the SA between PMIP client
and AR. 

Finally, I would like to emphasize the clean separation of localized MM
and global MM in this draft.  According to section 4.4., it is the MN's
responsibility to initiate RFC
3775 signaling with its (global) home agent when moving from one LMA to
a different LMA in a possibly different PMIP domain.

Ajoy-> Thanks very much for the detailed review, Christian.
In passing I'd also like to emphasize is that the draft allows a clean
separation of bearer plane and control plane, which is aligned with the
architectural view of various SDOs including 3GPP / 3GPP2 / WIMAX etc.  

Best regards,
- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 25 Jan 2007 19:20:09 +0100

Hi Ajoy -

I agree with the removed comments.  Further comments in-line...

> there is merit in making LMA as close to MIPv6 HA as possible. 

In RFC 3775 MIPv6, there is a need for per-MN SAs because the protocol
runs between the MN and the HA.  But in the case of PMIP6, the 
protocol runs between the PMIP client and the HA, so one SA for 
multiple MN should be fine.  As you say, it's a trade-off between 
reusability and efficiency.  But in this case I would personally opt 
for efficiency.

> this in base draft, or dealt with as an add-on? 

What I originally had in mind when writing this was that you might
actually merge the PMIP client functionality into the access router so
as to avoid a separate entity.  The serving PMIP client would then 
move with the MN as the MN hands over from AR to AR.  In this case, 
you would not have to worry about the security between the access 
router and the PMIP client as the two would always be within one box. 
  Of course, it would require the use of one single SA between each 
PMIP client and the LMA.

But if you want to leave the PMIP client as a separate entity so as to 
separate the control plane from the data plane more cleanly, then, 
yes, I agree that PMIP client migration can be left as future work.

> architectural view of various SDOs including 3GPP / 3GPP2 / WIMAX etc.

Alright.

Best regards,
- Christian

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 25 Jan 2007 14:33:19 -0500

Hi,  Christian, 

Please find inline responses. 

Regards,
Ajoy 

-----Original Message-----
From: Christian Vogt [mailto:[email-masked]] 
Sent: Thursday, January 25, 2007 12:20 PM
To: Singh Ajoy-ASINGH1
Cc: Bedekar Anand-ABEDEKA1; Kalyanasundaram Suresh-CSK090; Netlmm
Subject: Re: Review of draft-singh-netlmm-protocol-00

Hi Ajoy -

> associations between a PMIP client and the LMA cannot be 
> preestablished, but rather needs to be set up on a per-mobile-node 
> basis.  The rationale behind this idea is to adopt the RFC 3775/3776 
> concept of having one SA per mobile node.  Yet I think the price to be

> paid for this concept is too high, due to the following reasons:
> 
> per-MN SA increases reuse of existing protocol, and this is a 
> desirable outcome per the requirements draft.
> won't be any worse off than a standard MIPv6 HA. However, we are open 
> to make this change if there is such interest in WG, but we do believe

In RFC 3775 MIPv6, there is a need for per-MN SAs because the protocol
runs between the MN and the HA.  But in the case of PMIP6, the protocol
runs between the PMIP client and the HA, so one SA for multiple MN
should be fine.  As you say, it's a trade-off between reusability and
efficiency.  But in this case I would personally opt for efficiency.

Ajoy-> Okay. We would like to hear from other folks as well. Note that
there is a clear business reason for re-using MIPv6 HA for both local
and global mobility. The re-use of MIPv6 HA for local and global
mobility will reduce overall production cost of MIPv6 HA and thereby
increase the deployment of MIPv6 based solution. 

> Ajoy-> OK, this can be considered as an enhancement to our proposal. 
> Ajoy-> Do

What I originally had in mind when writing this was that you might
actually merge the PMIP client functionality into the access router so
as to avoid a separate entity.  The serving PMIP client would then move
with the MN as the MN hands over from AR to AR.  In this case, you would
not have to worry about the security between the access router and the
PMIP client as the two would always be within one box. 
  Of course, it would require the use of one single SA between each PMIP
client and the LMA.

But if you want to leave the PMIP client as a separate entity so as to
separate the control plane from the data plane more cleanly, then, yes,
I agree that PMIP client migration can be left as future work.

Ajoy-> I would prefer to keep the separation of BP/CP. IMHO, this is a
good thing and simplifies the netlmm protocol. Separation of BP/CP will
also enhance the scalability of access network. 

> Ajoy-> Please see my comment above regarding the SA between PMIP 
> Ajoy-> client
> and AR. 
> 
> Finally, I would like to emphasize the clean separation of localized 
> MM and global MM in this draft.  According to section 4.4., it is the 
> MN's responsibility to initiate RFC
> 3775 signaling with its (global) home agent when moving from one LMA 
> to a different LMA in a possibly different PMIP domain.
> 

> separation of bearer plane and control plane, which is aligned with 
> the architectural view of various SDOs including 3GPP / 3GPP2 / WIMAX
etc.

Alright.

Best regards,
- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 25 Jan 2007 20:50:56 +0100

Ajoy -

Ok, that's fine.

- Christian

---

From: Sebastian Thalanany <[email-masked]>
Date: Thu, 25 Jan 2007 16:05:26 -0600

Hi, Christian,
                       Agree with your observations. The following 
aspects of this draft are beneficial:
                                 a.  Separation between the BP and the 
CP, with a standalone PMIP client
                                 b.  Application of a single SA or a per 
MN SA, for local mobility
                                 c.  Allow various deployment options, 
since global mobility and local mobility are distinguished

Regards,
    Sebastian

The separation between the BP and the CP, in this draft is useful from 
an architectural perspective
Christian Vogt wrote:

>> PMA and LMA. But please note that  per-MN SA increases reuse of 
>> existing protocol, and this is a desirable
>> you see any need to consider this in base draft, or dealt with as an 
>> add-on? 
>
>

---

From: "SEITE Pierrick RD-RESA-REN" <[email-masked]>
Date: Fri, 26 Jan 2007 14:00:20 +0100

Hi Ajoy,

I agree that separation of CP/BP with a Standalone PMIP client (PMA) is a key point. Of course the price to pay is a new "AR-PMIP client" interface that is not yet clearly specified. Despite this, the concept is interesting because it goes in the direction of some SDOs and is aligned with architectures relying on a standalone mobility manager (e.g. 3GPP SAE). 

Regards,
Pierrick

-----Message d'origine-----
De : Singh Ajoy-ASINGH1 [mailto:[email-masked]] 
Envoyé : jeudi 25 janvier 2007 20:33
À : Christian Vogt
Cc : Netlmm
Objet : [netlmm] RE: Review of draft-singh-netlmm-protocol-00

Hi,  Christian, 

Regards,
Ajoy 

-----Original Message-----
From: Christian Vogt [mailto:[email-masked]] 
Sent: Thursday, January 25, 2007 12:20 PM
To: Singh Ajoy-ASINGH1
Cc: Bedekar Anand-ABEDEKA1; Kalyanasundaram Suresh-CSK090; Netlmm
Subject: Re: Review of draft-singh-netlmm-protocol-00

Hi Ajoy -

etc.

Alright.

Best regards,
- Christian

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Fri, 26 Jan 2007 10:56:20 -0500

Hi, Pierrick, 

Thanks for sharing your view. We will address your concern in next update of our draft. 

Regards,
Ajoy  

-----Original Message-----
From: SEITE Pierrick RD-RESA-REN [mailto:[email-masked]] 
Sent: Friday, January 26, 2007 7:00 AM
To: Singh Ajoy-ASINGH1; Christian Vogt
Cc: Netlmm
Subject: RE: [netlmm] RE: Review of draft-singh-netlmm-protocol-00

Hi Ajoy,

Regards,
Pierrick

-----Message d'origine-----
De : Singh Ajoy-ASINGH1 [mailto:[email-masked]] Envoyé : jeudi 25 janvier 2007 20:33 À : Christian Vogt Cc : Netlmm Objet : [netlmm] RE: Review of draft-singh-netlmm-protocol-00

Hi,  Christian, 

Regards,
Ajoy 

-----Original Message-----
From: Christian Vogt [mailto:[email-masked]]
Sent: Thursday, January 25, 2007 12:20 PM
To: Singh Ajoy-ASINGH1
Cc: Bedekar Anand-ABEDEKA1; Kalyanasundaram Suresh-CSK090; Netlmm
Subject: Re: Review of draft-singh-netlmm-protocol-00

Hi Ajoy -

> there is merit in making LMA as close to MIPv6 HA as possible.

In RFC 3775 MIPv6, there is a need for per-MN SAs because the protocol runs between the MN and the HA.  But in the case of PMIP6, the protocol runs between the PMIP client and the HA, so one SA for multiple MN should be fine.  As you say, it's a trade-off between reusability and efficiency.  But in this case I would personally opt for efficiency.

Ajoy-> Okay. We would like to hear from other folks as well. Note that
there is a clear business reason for re-using MIPv6 HA for both local and global mobility. The re-use of MIPv6 HA for local and global mobility will reduce overall production cost of MIPv6 HA and thereby increase the deployment of MIPv6 based solution. 

> this in base draft, or dealt with as an add-on? 

What I originally had in mind when writing this was that you might actually merge the PMIP client functionality into the access router so as to avoid a separate entity.  The serving PMIP client would then move with the MN as the MN hands over from AR to AR.  In this case, you would not have to worry about the security between the access router and the PMIP client as the two would always be within one box. 
  Of course, it would require the use of one single SA between each PMIP client and the LMA.

But if you want to leave the PMIP client as a separate entity so as to separate the control plane from the data plane more cleanly, then, yes, I agree that PMIP client migration can be left as future work.

Ajoy-> I would prefer to keep the separation of BP/CP. IMHO, this is a
good thing and simplifies the netlmm protocol. Separation of BP/CP will also enhance the scalability of access network. 

etc.

Alright.

Best regards,
- Christian

--
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/

---

From: Julien Laganier <[email-masked]>
Date: Mon, 29 Jan 2007 15:57:38 +0100

Folks,

This draft proposes a proxy MIPv6 protocol (PMIP) as a 
NETLMM solution. The proposal defines a new functional 
entity, the proxy Mobile IP client, which sends proxy 
binding updates and receive proxy binding 
acknowledgments on behalf of the mobile node. This 
functional entity can be standalone (somewhere in the 
core network) or co-located with the first access 
router to which an MN attaches. In either case the 
location of a PMIP client is fixed. 

I have the following comments:

0. I would recommend sticking to the NETLMM-centric 
terminology the WG agreed on (i.e. LMA, MAG, MN.)

1. The proposal has a different functional architecture 
than the one described in the NETLMM goals draft 
(draft-ietf-netlmm-nohost-req-05). In the NETLMM goals 
draft, the entity sending routing updates (MAG) is the 
entity "that terminates a specific edge link", whereas 
in this document it is a fixed network entity, 
standalone or co-located with the first access router 
to which the MN attaches.

2. I don't understand why the documents proposes two 
solution, one based on MIPv6, another on HMIPv6 based. 
This is duplication of the same protocol 
functionality, and should be avoided.

3. I don't understand what is the intent of sending the 
PBU from PMIP client to AR, which in turns forward it 
to the LMA without modifying it. What's the added 
value/functionality of that compared to the situation 
where the PBU is send directly from PMIP client to 
LMA? Also, why is the encapsulation functionality 
implemented ("e.g. within a UDP/IP packet") ? 

4. In one of the security mechanisms, the PMIP client 
and HA maintains per-MN security associations. 

I got the feeling that this is trying to overload 
RFC3776 semantic so that proxy BU sent by a PMIP 
client would be accepted as legitimate BU coming from 
the MN itself. In case that's really the intent, I do 
not think it is good to build in the protocol such 
"impersonation" of the MN by the PMIP client. The 
proxy characteristic of a BU should instead be made 
explicit, and a different IPsec configuration should 
be used (i.e. PAD and SPD entries, etc.) 

Besides, I do not see what is the security-wise value 
of having per-MN SAs between PMIP client and LMA 
bootstrapped with AAA. Is the intent to verify 
authorization of a PMIP client to sends proxy BU on 
behalf of a given MN? If so it should it should be 
clarified how this goal is met. If not, the goal of 
per-MN SA should be explained.

5. The draft states that:

   the PMIP client can (assuming that it has the
   knowledge of MN's interface identifier) infer the
   addresses that can be potentially auto-configured by
   the MNs. The PMIP client can therefore perform a DAD
   based on the MN's interface identifier (thereby
   detecting that some other MN has used the same
   interface identifier).

I don't think we can assume that PMIP client knows MN 
IID. If RFC3041 addresses or CGAs are used by MN it is 
unlikely that the PMIP client knows MN's IIDs.

   In addition, the PMIP client should also send
   to the AR the outcome of the DAD that it has 
   performed internally. 

I assume this "outcome" which is being sent is the 
duplicate/no-duplicates status, right? If so, then I 
have a question on this:

   If the MN is performing stateless address
   auto-configuration, the MN and AR can perform a DAD
   at this stage. The AR should send a proxy reply as
   appropriate, based on the DAD
   performed by the PMIP client. 

How can the AR send a proxy reply based on the DAD 
performed by the PMIP client, while this PMIP client 
was unaware of the MN's autoconfigured stateless 
address at the time it performed this DAD?  

   In order to ensure that the MN does not generate
   traffic for any address other than the one
   corresponding to the interface identifier that was
   authenticated, filters can be set at the AR.

As I said above I do not think basing mechanisms on IID 
are sufficient.

Thanks.

--julien

---

From: Anand Bedekar <[email-masked]>
Date: Tue, 30 Jan 2007 19:29:06 -0600

Hello Julien,

Thanks for the review. Please take a look at some comments below.

-Anand

> terminology the WG agreed on (i.e. LMA, MAG, MN.)
[Anand] Agreed, we'll update this in the next version of the draft.

> to which the MN attaches.
[Anand] That's true. But I think the proposal is in keeping with the
spirit of the goals. We interpreted the functional architecture
described in the draft as a candidate architecture sufficient for 
elaborating on the goals, rather than as the end goal itself 
constraining possible solutions. We don't see this as a huge issue, but 
let me know if you view it differently.

> functionality, and should be avoided.
[Anand] Agreed - in the next version of the draft, we will focus on the
MIPv6-based one.

> implemented ("e.g. within a UDP/IP packet") ?
[Anand] As mentioned in section 3 (page 6) of the draft,
"The second alternative is to overcome implementations that
    follow RFC 3776 [4] and assume that the source address of the
    binding update should be the same as the address in the "Alternative
    CoA" field of the BU."
One of the intentions of this draft is to show how a MIPv6 HA (as
currently specified in 3775/3776) can be used as a LMA in the NetLMM
context (more on this below). Here is some lack of clarity on my part 
about RFC 3776. As I understand it, if an RFC3776-compliant HA were to 
be used as the LMA, the behaviour for processing IPSec as spelled out in 
RFC3776 seems to require that the CoA or alternative CoA in the BU would 
need to be the same as the source address of the BU. (But this is not 
very clear - cf. sections 3.1, 6.1, and 6.2. Section 6.2, step 2 seems 
to imply that the value of the source addr field is simply replaced with 
the home address for further processing, so it may not matter? The care 
of address is still there in the Alternate CoA field, which is inside 
the part protected by ESP. It is also not very clear to me what the HA 
would do if source addr != alternate CoA - an implementation of the HA 
may reject the BU, or it may still accept it? Some clarification here on 
RFC3776 would be appreciated.) Anyway, the mechanism of having the PMIP 
client first send the BU to the AR (encapsulated), and then having the 
AR send the (decapsulated) BU to the LMA would ensure that the source 
address of the BU can be the same as the CoA - this would avoid any 
uncertainty over HA implementations following 3776. If this uncertainty 
were not there, this mechanism wouldn't be needed.

> the MN itself.

[Anand] Yes (actually it is trying to conform to the RFC3775 semantics
as well). This is motivated mainly by trying to reuse a MIPv6 HA as the
LMA in the NetLMM context to the extent possible.

> In case that's really the intent, I do

[Anand] This can definitely be accommodated within the proposed
functional architecture. For example, a per-PMIP client SA could be used
by the LMA, rather than a per-MN SA.

> per-MN SA should be explained.
[Anand] It's more to address a scaling concern rather than any real 
security issue. If per-MN SAs between the  LMA and PMIP client are used, 
then it may be impractical to assume that
all LMAs and all PMIP clients in the domain have a priori access to the
(per-MN) keys required for the SAs.
(Also not good security practice to have the same per-MN key available
at multiple PMIP clients or LMAs, etc.) The AAA server can produce a key
whenever a PMIP client is "instantiated" for a given MN in the domain,
and send the key to the PMIP client and the LMA. This enables a scalable
bootstrapping of the per-MN SAs. At the same time, the AAA server itself
would only give out a key for a given MN to a particular PMIP client if
that PMIP client was authorized to send proxy BU on behalf of that MN.
So as you noted, the AAA involvement does allow enforcement of
"authorization restrictions" as well.

> unlikely that the PMIP client knows MN's IIDs.
[Anand] I agree with this concern. If the IID that the MN would use is
something that cannot be predicted by the PMIP client, then I would in
fact suggest that DHCPv6 should be used rather than stateless
configuration (thus also avoid the need for any kind of proxy DAD). In
any case, DHCP may be needed for other host configuration parameters
like MTU, DNS servers, etc. I think it will be useful to find out what
the group thinks of this.

> As I said above I do not think basing mechanisms on IID
[Anand] I agree, if the IID that the MN uses is not predictable, then
purely IID-based mechanisms may be insufficient.

> --julien

Thanks a lot for the detailed review, Julien.
-Anand