[Mip6] Comments on draft-ietf-mip6-mn-ident-option-00.txt

[Jari Arkko <[e-mail]>]

I have reviewed this document. Here are my comments:

Substantial:

> [RFC2486]  Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.

It may be appropriate to refer to draft-ietf-radext-rfc2486bis-03.txt
instead. This document is in IETF LC at the moment, which means that
its in front of the ident-option draft; reference delay should not
be a problem. One good reason for switching to the bis reference
is that the ABNF in the original RFC had a number of problems.

> If this option is present in the Binding Update, it MUST be included in the corresponding reply (Binding Acknowledgement).

Hmm... why? Does not seem to be grounds for a MUST. But I wonder
why you need it in the first place.

> 5.  IANA Considerations

This one is missing the text about the subtype registry.
Here's a suggestion:

    In addition, the IANA needs to create a new namespace for
    the subtype field of the Mobile Node Identifier Option.
    The currently allocated values are as follows:

        NAI (defined in this document)      [1]

    New values for this namespace can be allocated using
    Standards Action [RFC 2434].

> it MUST be present in all subsequent Binding Updates
> used to renew the binding cache entry.

Is this really necessary? Presumably you could store
the identifier in the BCE. This would also provide
some privacy benefits, see also below.

> 4.  Security Considerations
> 
>     None.  This document defines new identifiers for a mobile node and
>     does not introduce new security threats.

I don't think this covers it completely. Here's some suggested
text that deals with a few issues:

    Mobile IPv6 already contains one mechanism for identifying
    mobile nodes, the Home Address Option [RFC 3775]. As a result,
    the vulnerabilities of the new option defined in this document
    are similar to those that already exist for Mobile IPv6. In
    particular, the use of a permanent, stable identifier may
    compromise the privacy of the user, making it possible to
    track a particular device or user as it moves through
    different locations.

    In addition, since an NAI reveals the home affiliation
    of a user, it may assist an attacker in determining the
    identity of the user, help the attacker in targeting
    specific victims, or assist in further probing of
    the username space.

    These vulnerabilities can be addressed through various
    mechanisms, such as those discussed below:

    o  Encrypting traffic at link layer such that other
       users on the same link do not see the identifiers.
       This mechanism does not help against attackers on
       the rest of the path between the mobile node and
       its home agent.

    o  Encrypting the whole packet, such as when using
       IPsec to protect the communications with the home
       agent [RFC 3776].

    o  Using an authentication mechanism that enables the
       use of privacy NAIs [RFC2486bis] or temporary,
       changing "pseudonyms" as identifiers.

    In any case, it should be noted that as the identifier
    option is only needed on the first registration at the
    home agent and subsequent registrations can use the
    home address, the window of privacy vulnerability in
    this document is reduced as compared to the RFC 3775.
    In addition, this document is a part of a solution to
    allow dynamic home addresses to be used. This is
    an improvement to privacy as well, and affects both
    communications with the home agent and the correspondent
    nodes, both of which have to be told the home address.

> The MN-NAI mobility option uses an identifier of the form user@realm
> [RFC2486].

Perhaps you could indicate whether you allow the use of
the privacy, internationalization, or bang syntaxes from
RFC2486bis.

Editorial:

> Alignment requirements:
> 
> This option does not have any alignment requirements.

This looks like a field description. Change to:

> This option does not have any alignment requirements.

(That is, indent as regular text and delete the heading.)

> Title: MN Identifier Option for Mobile IPv6

Change to "Mobile Node Identifier Option for Mobile IPv6".

> 3.  MN Identifier option 3.1  MN-NAI mobility option

I guess I'm confused here. You are defining just one
Mobile IPv6 option. I think its name should be the "Mobile
Node Identifier Option". If you want to have a subsection 3.1
to talk about the case when the type of identifier is a NAI,
that's fine. But the current 3.1. sounds like you were defining
another option.

> authentication enabling extension

Change to "authentication related extension"

> IANA should record value for this new Mobility Option.

... should record *a* value ...

--Jari

_______________________________________________
Mip6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6