Subject: [netlmm] AD review of draft-ietf-netlmm-nohost-req-03.txt

From: Jari Arkko <[email-masked]>
Date: Thu, 27 Jul 2006 11:41:12 +0300

I have reviewed this document. Here are my comments:

Overall, its in good shape but the issues listed below need
to be addressed/discussed before we can take this to the
IETF Last Call and the IESG.

>      1) Movement detection using DNA [6] or possibly a link specific
>         protocol,
>      2) Any link layer or IP layer AAA signaling, such as 802.1x [7] or
>         PANA [8]. The mobile node may also or instead have to obtain a
>         router  authorization  certificate  using  SEND  [9],  if  the
>         certificate is not already cached,
>      3) Router discovery which may be part of movement detection,
>      4) If  stateless  address  autoconfiguration  is  used,  address
>         configuration and Duplicate Address Detection (unless optimistic
>         Duplicate Address Detection [10] is used) including for link
>         local addresses. If stateful address configuration is used, then
>         DHCP is used for address configuration,
>      5) Binding Update to the home agent,
>      6) If route optimization is in effect, return routability to
>         establish the binding key,
>      7) Binding Update to correspondent nodes for route optimization.

This needs some improvement. (Or you might also consider making it less
detailed to avoid getting problems with the details. E.g., talk about
home registration instead of Binding Updates.)

Is the list ordered? For 1, DNA can not happen until 2 is done.
For 2, it seems that SEND would be a logical part of 3, not 2.

Binding acknowledgements are missing.

There's more to link layer signaling than 802.1x.

The text in 4 about "including" seems to need some editing.

What about MLD?

>      The result is approximately 10 messages at the IP level before a
>      mobile node can be ensured that it is established on a link and has
>      full IP connectivity.

Even without DNA and SEND, I'm counting twelve for the basic
case of: RS/RA, MLD, DAD, HA BU/BA, HOTI/HOT, COTI/COT,
CN BU/BA.

>      Furthermore, in some cases, the mobile node
>      may need to engage in "heartbeat signaling" to keep the connection
>      with  the  correspondent  or  global  mobility  anchor  fresh,  for
>      example, return routability in Mobile IPv6 must be done at a
>      maximum every 7 minutes even if the mobile node is standing still.

You may want to soften this statement a bit. It seems to be required
only when you have traffic and/or want to keep the correspondent
binding up. And there are ways to avoid this.

And I am not aware of global mobility anchor hearbeat
signaling, or are you referring to IPsec DPD?

>      When  a  mobile  node  moves  geographically,  it  also  moves
>      topologically between subnets. In order to maintain routability,
>      the mobile node must change its local IP address when it moves
>      between subnets. A correspondent node or eavesdropper can use the
>      topological to geographical map to deduce in real time where a
>      mobile node - and therefore its user - is located.

This is a bit too straightforward claim. Eavesdropper can certainly
do that, but the ability of the correspondent nodes to do this depends
on what type of protocol and configuration you run. For instance,
in MOBIKE CNs would never be able to do that, because all communication
takes place through a gateway.

Soften/reformulate the claim.

>      If the access network policy wants to deny localized mobility
>      management to a mobile node, it can do so at the time network
>      access authentication occurs, in a manner the reverse of how some
>      networks restrict routing to the Internet before network access
>      authentication and open it afterwards.

Is there a need for this document to state anything about this?
It does not appear to be a requirement that the NETLMM protocol
needs to deal with. And in any case, typical networks where NETLMM
would be run have per-mobile node authentication at L2, and they
can generally perform any policing and differential treatment
to the node they want.

Suggest deleting this text.

>      Goal  #3  Location  privacy:  Location  privacy  is  preserved  for
>      external correspondents, but the mobile node itself still maintains
>      a  local  care-of  address.  If  the  mobile  node  performs  route
>      optimization,  location  privacy  may  be  compromised,    but 
> not  
>      performing route optimization is no better than having a remote
>      home agent. 

1) The privacy compromise argument rests on the mobile node
knowingly doing something that harms itself. Surely mobile
nodes that care about location privacy would avoid RO. I would
suggest cutting the entire text to "Location privacy is preserved
for external correspondents, assuming the mobile node itself
does not disclose its care-of address in other ways."

2) I have trouble parsing the last part about RO. But the way that
I read it, it seems to claim that local HA with bidir tunneling
is not any more efficient than a remote HA. This seems incorrect;
a local HA ensures that that routing is in general fairly efficient.
Without RO, some unnecessary paths may need to be taken, but
at least they will not take you to the other side of the world and
back.

>      Although the credentials used for
>      network access authentication could also be used for mobile service
>      authentication and authorization if the local home agent uses EAP
>      over IKEv2 to authenticate the mobile node with its home AAA
>      server, the two sets of credentials are in principle different, and
>      could require additional credential provisioning.

I'm not sure I buy the argument about different credentials, but
there is some work that would be needed. Suggest changing this
to:

     The credentials used for
     network access authentication could also be used for mobile service
     authentication and authorization if the local home agent uses EAP
     over IKEv2 to authenticate the mobile node with its home AAA
     server. This may require additional authorization between the
     home and visited networks to use the same credentials for a
     different service, however.

Editorial:

>            Localized Mobillity Management", Internet draft, Work in 

Typo.

>      care of address conceptually is within the micromobiity domain 

Typo.

>      Goal #3 Location privacy: The mobile node mantains a local care-of 

Typo.

>      scalablity. The IETF host-based protocols require host software 

Typo.

>      fufilled.  

Typo.

>      WLAN switch approach used between WLAN switches in different 

Once you resolve one of the nohost-ps DISCUSSes that dealt with
comparisons to WLANs, please update this document as well so that
we don't get the same DISCUSS here.

>      requires proper bidirectional authentication and authorization of 

s/bidirectional/mutual/?

Finally, Idnits reports these problems:

>  Miscellaneous warnings:
>  - Line 29 has weird spacing: '...    The  list ...'
>  - Line 72 has weird spacing: '... mobile  node ...'
>  - Line 77 has weird spacing: '...s,  and  also ...'
>  - Line 116 has weird spacing: '...agement  probl...'
>  - Line 124 has weird spacing: '... subnet  confi...'
>  - (65 more instances...)  
>
--Jari

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 27 Jul 2006 08:29:07 -0700

Jari,

Thanx for the review. I will work though the list and enter the comments 
into Traq.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 27 Jul 2006 11:22:55 -0700

> case of: RS/RA, MLD, DAD, HA BU/BA, HOTI/HOT, COTI/COT,

perhaps point to draft-thaler-mobility-comparison-01.txt
which also counts the number of messages for Mobile IPv6.
I think it does a better job.

Vijay

---

From: Christian Vogt <[email-masked]>
Date: Thu, 27 Jul 2006 23:51:23 +0200

Hi Jari, hi all.

> Even without DNA and SEND, I'm counting twelve for the basic case of:
> RS/RA, MLD, DAD, HA BU/BA, HOTI/HOT, COTI/COT, CN BU/BA.

Yes, and 3 little follow-ups concerning this:

- Assuming the use of RFC 2462bis rather than RFC 2462, at least 2 DAD
NSs are necessary:  one for the link-local address and one for each
global  IP address.  RFC 2462 facilitates simultaneous uniqueness
verification for multiple IP addresses through a single DAD run when the
IIDs of these IP addresses are the same.  However, RFC 2462bis removes
this option and requires separate DAD runs due to the potential presence
of nodes using privacy addresses or SEND.

- Not sure you want to add address resolution here but IMO it should be
menioned:  A MN typically sends the RS from a link-local address or from
the unspecified address.  In either case, the access router will at some
point have to initiate an NS/NA exchange for the MN's global IP
address(es).  Furthermore, the access router is likely to initiate an
NS/NA exchange for the MN's link-local address if (a) the MN uses
Optimistic DAD, (b) sends an RS from its optimistic link-local address,
but (c) does not add a TSLLAO, and if (d) the access router prefers to
unicast solicited RAs back to the solicitor.

- Multiple MLD Report messages may be sent if the IIDs for link-local
and global IP addresses are different.  This may, e.g., happen with
SEND, due to the random modifier in CGA computation.

Feel free to copy and paste from the above text where this is of help.

- Christian

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

"Everything should be made as simple as possible, but not simpler."
(Albert Einstein)

Jari Arkko wrote:
> Overall, its in good shape but the issues listed below need to be
> addressed/discussed before we can take this to the IETF Last Call and
> the IESG.
> 
> 
>> protocol, 2) Any link layer or IP layer AAA signaling, such as
>> 802.1x [7] or PANA [8]. The mobile node may also or instead have to
>> obtain a router  authorization  certificate  using  SEND  [9],  if
>> the certificate is not already cached, 3) Router discovery which
>> may be part of movement detection, 4) If  stateless  address
>> autoconfiguration  is  used,  address configuration and Duplicate
>> Address Detection (unless optimistic Duplicate Address Detection
>> [10] is used) including for link local addresses. If stateful
>> address configuration is used, then DHCP is used for address
>> configuration, 5) Binding Update to the home agent, 6) If route
>> optimization is in effect, return routability to establish the
>> binding key, 7) Binding Update to correspondent nodes for route
>> optimization.
> 
> 
> This needs some improvement. (Or you might also consider making it
> less detailed to avoid getting problems with the details. E.g., talk
> about home registration instead of Binding Updates.)
> 
> Is the list ordered? For 1, DNA can not happen until 2 is done. For
> 2, it seems that SEND would be a logical part of 3, not 2.
> 
> Even without DNA and SEND, I'm counting twelve for the basic case of:
> RS/RA, MLD, DAD, HA BU/BA, HOTI/HOT, COTI/COT, CN BU/BA.
> 
> 
>> Furthermore, in some cases, the mobile node may need to engage in
>> "heartbeat signaling" to keep the connection with  the
>> correspondent  or  global  mobility  anchor  fresh,  for example,
>> return routability in Mobile IPv6 must be done at a maximum every 7
>> minutes even if the mobile node is standing still.
> 
> 
> And I am not aware of global mobility anchor hearbeat signaling, or
> are you referring to IPsec DPD?
> 
> 
> do that, but the ability of the correspondent nodes to do this
> depends on what type of protocol and configuration you run. For
> instance, in MOBIKE CNs would never be able to do that, because all
> communication takes place through a gateway.
> 
> Is there a need for this document to state anything about this? It
> does not appear to be a requirement that the NETLMM protocol needs to
> deal with. And in any case, typical networks where NETLMM would be
> run have per-mobile node authentication at L2, and they can generally
> perform any policing and differential treatment to the node they
> want.
> 
>>  external correspondents, but the mobile node itself still
>> maintains a  local  care-of  address.  If  the  mobile  node
>> performs  route optimization,  location  privacy  may  be
>> compromised,    but not performing route optimization is no better
>> than having a remote home agent.
> 
> 
> 1) The privacy compromise argument rests on the mobile node knowingly
> doing something that harms itself. Surely mobile nodes that care
> about location privacy would avoid RO. I would suggest cutting the
> entire text to "Location privacy is preserved for external
> correspondents, assuming the mobile node itself does not disclose its
> care-of address in other ways."
> 
> 2) I have trouble parsing the last part about RO. But the way that I
> read it, it seems to claim that local HA with bidir tunneling is not
> any more efficient than a remote HA. This seems incorrect; a local HA
> ensures that that routing is in general fairly efficient. Without RO,
> some unnecessary paths may need to be taken, but at least they will
> not take you to the other side of the world and back.
> 
> 
>> Although the credentials used for network access authentication
>> could also be used for mobile service authentication and
>> authorization if the local home agent uses EAP over IKEv2 to
>> authenticate the mobile node with its home AAA server, the two sets
>> of credentials are in principle different, and could require
>> additional credential provisioning.
> 
> 
> there is some work that would be needed. Suggest changing this to:
> 
> The credentials used for network access authentication could also be
> used for mobile service authentication and authorization if the local
> home agent uses EAP over IKEv2 to authenticate the mobile node with
> its home AAA server. This may require additional authorization
> between the home and visited networks to use the same credentials for
> a different service, however.
> 
> Editorial:
> 
> 
> comparisons to WLANs, please update this document as well so that we
> don't get the same DISCUSS here.
> 
> 
>> Miscellaneous warnings: - Line 29 has weird spacing: '...    The
>> list ...' - Line 72 has weird spacing: '... mobile  node ...' -
>> Line 77 has weird spacing: '...s,  and  also ...' - Line 116 has
>> weird spacing: '...agement  probl...' - Line 124 has weird spacing:
>> '... subnet  confi...' - (65 more instances...)
>> 
> 
> --Jari