Subject: [netlmm] proxymip6-01

From: "Alper Yegin" <[email-masked]>
Date: Wed, 11 Jul 2007 12:26:02 +0300

Hello,

I have some comments and questions on I-D proxymip6-01.

   It sends Router
   Advertisement messages to the mobile node on the access link
   advertising the mobile node's home network prefix as the hosted on-
   link-prefix.

I presume this would not work with SEND. Correct?

   The mobile access gateway typically acts as a default router on the
   access link and any packet that the mobile node sends to any
   corresponding node is received by the mobile access gateway and it
   forwards the packet to its local mobility anchor through the bi-
   directional tunnel.

s/typically acts/MUST act
s/is received/MUST be received

As for the "forwarding", I think there is a bit of a detail there because of
EnableMAGLocalrouting.

   The Proxy Mobile IPv6 model, defined in this document requires the
   Proxy Binding Update messages sent by the mobile access gateway to
   have the Time Stamp option.

Are we assuming that all combinations of MAGs and LMAs have synchronized
clocks? 

   Upon receiving a Binding Update request from a mobile node with
   lifetime value set to 0, from a tunnel between itself and a trusted
   mobile access gateway, the local mobility anchor upon accepting that
   de-registration message, MUST forward the Binding Acknowledgement
   message in the tunnel from where it received the Binding Update
   request.

Do we really mean "MN sending a BU through the tunnel between the MAG and
the LMA?" Is this a special case of mixing MIP6 with PMIP6?

   One of the workarounds for this issue is to set the DNAv6
   configuration parameter, DNASameLinkDADFlag to TRUE and that will
   force the mobile node to redo DAD operation every time the interface
   comes up, even when DNAv6 does detect a link change .

If we go down that path, now all IPv6 nodes will have to perform DAD because
they would not know when they are being hosted by a PMIP6-enabled network.
This seems to defeat the purpose of DNA.

   The specific detection mechanism of the loss of a visiting mobile ...

   o  Link-layer event specific to the access technology

We used to have "link down" defined in the DNA WG's link indications draft.
We could use it here... if we had kept it.

   However, if the mobile access gateway has the ability to withdraw the
   previous default-router entry, by sending a Router Advertisement
   using the link-local address that of the previous mobile access
   gateway and with the Router Lifetime field set to value 0, then it is
   possible to force the flush of the Previous Default-Router entry from
   the mobile node's cache.

Again, SEND gets in the way of such a scheme...

Thanks.

Alper

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

---

From: "Jong-Hyouk Lee" <[email-masked]>
Date: Wed, 11 Jul 2007 19:02:29 +0900

Dear colleague.

Please see the inline.

> s/is received/MUST be received

As my opinion, we should not use the "MUST" keyword at this sentence. If we
define like "MAG MUST act as a default router on the access link ... MUST be
received ...", it would minimize the flexibility of PMIPv6 approach. I think
that a local mobility anchor (LMA) should send its own prefix information in
the network, not only mobile access gateway (MAG).

> Are we assuming that all combinations of MAGs and LMAs have synchronized

Well, the PMIPv6 specification (draft-ietf-netlmm-proxymip6-01) assume that
all proxy mobility agent such as LMAs and MAGs in a domain managed by one
network provider MUST synchronize their time information by Network Time
Protocol (RFC 1305). It is a possible scenarios, but I also think it is
doubtful.

> the LMA?" Is this a special case of mixing MIP6 with PMIP6?

As I know, that is just for de-registration initiated by a mobile node.

Cheers.

-- 
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: Julien Laganier <[email-masked]>
Date: Thu, 12 Jul 2007 18:31:17 +0200

Hi Alper,

On Wednesday 11 July 2007 11:26, Alper Yegin wrote:
>    It sends Router
>    Advertisement messages to the mobile node on the
> access link advertising the mobile node's home
> network prefix as the hosted on- link-prefix.
>

It could be made to provided that the MAG in the 
visited network has been certified by the MN's home 
domain. The certificate could be:

   1. generic and authorize advertisement of *any*
     prefix if it includes the prefix ::0/0 as per 
    [RFC3779].

   2. tailored to prefixes in use in the home network,
     if it includes e.g. 2001:1234:5678:/48

   3. tailored to a per-MN prefix in use by a specific
     MN, e.g. 2001:1234:5678:9abcd::/64.

Case 1. and 2. would at the minimum require an operator 
to certify all MAGs of its roaming partner and 
provisions them once. The security implications of 
doing so need to be weighted carefully. That would be 
a bit lax, IMHO.

Case 3. would require an operator to certify MAGs of 
its roaming partners each time one of its MN roams 
there. This seems to require a certificate transport 
from home to visited.

[...]

>    However, if the mobile access gateway has the
> ability to withdraw the previous default-router
> entry, by sending a Router Advertisement using the
> link-local address that of the previous mobile
> access gateway and with the Router Lifetime field
> set to value 0, then it is possible to force the
> flush of the Previous Default-Router entry from the
> mobile node's cache.
>

That would work only if the new MAG is able to spoof 
the link-local address of the old MAG. To do so, the 
new MAG needs the CGA public-private key pair of the 
old MAG. That mean that either all MAGs are 
provisioned with key pairs of other MAGs, or that all 
use the same key-pair and hence they configure the 
same link-local address.

FWIW the current MN-AR interface mandates that all MAGs 
configures the same link-local address to avoid issues 
with DAD not kicking in after a handover due to DNAv6 
concluding that the link did not changed (since 
announced prefix remains the same).

--julien

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 13 Jul 2007 13:00:39 +0300

Hi Julien,

> there. This seems to require a certificate transport

If I'm understanding the implications of these remedies right, they don't
appear to be practical for large-scale deployments. 

> use the same key-pair and hence they configure the

Same problem here...

> announced prefix remains the same).

I presume that'd be an IANA-assigned value (one well-known LL address for
all). That should solve the problem of having to do DAD for each handover.

Alper

---

From: Julien Laganier <[email-masked]>
Date: Fri, 13 Jul 2007 14:08:14 +0200

Hi Alper,

On Friday 13 July 2007 12:00, Alper Yegin wrote:
> > >    Advertisement messages to the mobile node on
> > > the access link advertising the mobile node's
> > > home network prefix as the hosted on-
> > > link-prefix.
> > >
> > visited network has been certified by the MN's
> > home domain. 

I think I wrote that too quickly, sorry. Let me rewrite 
it better. What I meant was: 

It could be made to work provided that the MAG in the 
visited network is authorized by the MN's home 
network. That can be realized through the home domain 
authorizing the visited domain to advertise prefixes 
on its behalf with a certificate, while the visited 
domain delegates further that authorization to its 
MAGs with additional certificates (this last part is 
exactly like a regular deployment of SEND where an 
operator certifies its access routers). In addition, 
the MAGs need to be provisionned with the first 
certificate of the chain (home to visited).

The certificate from the home domain to the visited 
domain could be:

    2. tailored to prefixes in use in the home
     network, if it includes e.g. 2001:1234:5678:/48

    3. tailored to a per-MN prefix in use by a
      specific MN, e.g. 2001:1234:5678:9abcd::/64.

Case 1. and 2. would at the minimum require a home
domain to certify its roaming partner and authorize 
them to advertise any prefix on behalf of the home 
domain. This requires a one-time provisioning of the 
visited domain with a certificate. The visited domain 
can then distribute that certificate to each of its 
MAGs. The security implications of doing so need to be 
weighted carefully. That would be a bit lax, IMHO.

Case 3. would require a home domain to certify its 
roaming partner and authorize it to advertise the 
per-MN prefix each time one of its MN roams there. The 
visited domain would then have to make this 
certificate available to each of its MAGs. This seems 
to require a certificate transport from the home to 
visited domain, up to MAGs, each time a new MN roams 
into a visited domain.

> If I'm understanding the implications of these
> remedies right, they don't appear to be practical
> for large-scale deployments.

Now that I managed to explain myself correctly:

   - I think case 1. and 2. above are quite practical,
    but I am a bit suspicious about such a security
    policy (in other words I think it's a bit lax given
    the level of protection offered by a regular SEND
    deployment).

   - For case 3. above, which seems to preserve the 
    fine-grained authorization control of SEND, I'm not
    sure if it is practical or not. What I'm however 
    now sure is that it requires a certificate 
    transport from the home to visited domain, and to  
    MAGs each time a new MN roams into a visited
    domain. It means we need to specify how to use or
    extend an existing protocol (e.g. AAA, PMIPv6) to
    do that. Once we've done it we can study if it is
    practical or not.
  
> > > entry, by sending a Router Advertisement using
> > > the link-local address that of the previous
> > > mobile access gateway and with the Router
> > > Lifetime field set to value 0, then it is
> > > possible to force the flush of the Previous
> > > Default-Router entry from the mobile node's
> > > cache.
> > >
> > That would work only if the new MAG is able to
> > spoof the link-local address of the old MAG. To do
> > so, the new MAG needs the CGA public-private key
> > pair of the old MAG. That mean that either all
> > MAGs are provisioned with key pairs of other MAGs,
> > or that all use the same key-pair and hence they
> > configure the same link-local address.
>
> Same problem here...

Yes, I do not think it is very practical. I also think 
that this is not good from a security point of view. 
At the minimum such a MAG CGA key-pair sharing should 
be limited to one domain, IMHO. That would not 
interact well with the current MN-AR interface, see 
below...

> > FWIW the current MN-AR interface mandates that all
> > MAGs configures the same link-local address to
> > avoid issues with DAD not kicking in after a
> > handover due to DNAv6 concluding that the link did
> > not changed (since announced prefix remains the
> > same).
>
> I presume that'd be an IANA-assigned value (one
> well-known LL address for all). That should solve
> the problem of having to do DAD for each handover.

Yes I've thought about that too; that would work. But, 
it wouldn't work with SEND. We cannot use the same 
public-private key pair in *every* PMIP-SEND 
deployment.

Or else IANA would have to assign and publish the CGA 
public and *private* key pairs :-D !?

Best,

--julien

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 16 Jul 2007 00:04:11 -0700

Hi Alper,

Sorry for the late reply. Please see inline ...

Regards
Sri

> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]] 
> Sent: Wednesday, July 11, 2007 2:26 AM
> To: [email-masked]
> Subject: [netlmm] proxymip6-01
> 
> Hello,
> 

We did not cover the details on how SEND needs to be configured 
in the PMIP domain. But, this is more a provisioning issue and
how the MAG's are configured with the certs. Some guidance is
probably required. But, it might be too much to cover in the
base doc.

> s/is received/MUST be received

Ok.

> Are we assuming that all combinations of MAGs and LMAs have 

Yes. NTP needs to be configured, as we do in MIP4. There was a thread
proposing different approaches and the consensus was to go with the
Time Stamp based approach.

> the LMA?" Is this a special case of mixing MIP6 with PMIP6?

Yes. This is for the integrated scenario. These scenarios are covered
in the PMIP-CMIP interaction document. Some minimal text related to
the scenario.

> This seems to defeat the purpose of DNA.

Not trying to avoid DNAv6. But, its for covering the specific issues
and the possible ways to deal with the issue. DNAv6 certainly introduces
some challenges specifically for the shared link model and there is just
one minor issue in case of p2p link mode, the issue of link local address
uniqueness. When the shared link support is added to PMIP6, in an
exension document, IMO, the DNAv6 issues needs to be addressed for that
scenario.

> We could use it here... if we had kept it.

Ok. The event is required for the MAG to detect the loss of
a visiting mobile node from its access link. Not sure, if DNAv6
can provide that event. 

> Again, SEND gets in the way of such a scheme...

True. This is a good point.

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 22 Jul 2007 03:52:59 +0300

Hi Sri,

> probably required. But, it might be too much to cover in the

I agree. We could document that dealing with SEND is out of scope for the
base spec.

> in the PMIP-CMIP interaction document. Some minimal text related to

A reference, and a bit of more text would be useful. I cannot make sense out
of that text.

> exension document, IMO, the DNAv6 issues needs to be addressed for that

Julien seems to have a solution for that problem (requiring MAGs to
configure the same LL address).

> a visiting mobile node from its access link. Not sure, if DNAv6

DNAv6 cannot. draft-ietf-dna-link-information-06.txt could, if Link Down
were not removed from the spec. 

Alper