[Mip4] AD review comments on advance draft-ietf-mobileip-lowlatency-handoffs-v4-08.txt

[Pete McCann <[e-mail]>]

Hi,

We received the following AD review comments from Thomas Narten on
draft-ietf-mobileip-lowlatency-handoffs-v4-08.txt.  We have asked
the editor (Karim El Malki) to prepare a new revision in response.

If anyone has comments on the comments or suggested text for Karim
(I'm sure he'd appreciate it) please send it to the list.

-Pet




-----------------------

IANA considerations needs work. I suspect that IANA will not
understand what needs to be done here. E.g., try the following thought
experiment: ask someone outside of the WG to read the section and can
they identify the name spaces and possible values that could be
used). Be more clear. Say specifically what is being requested, i.e,
naming the name space and citing where it is defined, etc. Look
at RFC 3543 or 3519 for examples.

Security considerations needs work. At a minimum, the text about "use
ESP" seems insufficient (see security AD comments in ID tracke for
draft-ietf-seamoby-card-protocol for starters - I suspect the same
point applies to this document.) THe security analysis as a whole
seems pretty weak, and in reading it, I didn't get a sense that the
security issues were well-understood. E.g., seems like a lot of the
security properties depend on L2 security, of which there is no
discussion. I.e., has a detailed analysis in the context of a specific
LL type  been done? Could it be done?

Editorial:

>       aFA - anchor Foreign Agent, the FA that is currently handling
>          the network end of the BET in POST-REGISTRATION.

Pleas expand acronyms on first use.

>    The Registration MAY be transmitted more than once to reduce the
>    probability that it is lost due to errors on the wireless link.

seems like MAY need to be a SHOULD/MUST, if this protocol is going to
be robust...

>    since it is unnecessary for a secured unicast message.  The ICMP
>    solicitations and advertisements MUST be authenticated.  These
>    messages MUST be protected using ESP [10] to prevent attacks.  An FA
>    MUST NOT accept ICMP solicitations or advertisements from sources
>    which are not authenticated.

Which transforms specifically?

>    issues the Registration Request.  Therefore the
>    MIN_SOLICITATION_INTERVAL in oFA MUST be set to a value equal to (0.5
>    * nFA's CHALLENGE_WINDOW * nFA's Agent advertisement interval).  The
>    CHALLENGE_WINDOW and Agent advertisement interval are defined in [7]
>    and [1] respectively.  The minimum requirement is that the
>    MIN_SOLICITATION_INTERVAL MUST be manually configurable, while
>    possible autoconfiguration mechanisms are outside the scope of this
>    document.  To allow advertisement caching in certain implementations

The two MUSTs contradict each other. I think the first MUST should
probably not be a MUST, but be a suggested default.

>    When the MN receives an Agent Advertisement with a Mobility Agent
>    extension, it performs actions according to the following movement
>    detection mechanism: the MN MUST be "Eager" to perform new bindings.
>    This means that the MN MUST perform Registrations with any new FA
>    from which it receives an advertisement (i.e. MN is Eager), as long
>    as there are no locally-defined policies in the MN that discourage
>    the use of the discovered FA.  For example, the MN could have a
>    policy based on the cost of service.  The method by which the MN
>    determines whether the FA is a new FA is described in [1] and MAY use
>    an FA-NAI extension [11].

First MUST to be "Eager" seems unecessary. Experimentation is needed
to figure out how eager one should be. That suggests SHOULD or just
pointing  out the obvious that if one doesn't do registrations, one
doesn't get benefits...

>    - when L3 cannot rely upon L2 security between the MN and the FA to
>      make modifications to IP routing and therefore authenticated Mobile
>      IP messages are required,
>

Don't understand this bullet

>    Registration with nFA will not complete before the MN moves on, HTT

HTT used prior to expansion/defn.

>      Code              A value indicating the result of the Handoff
>                        Request.  Only two codes are currently supported,
>                        0, indicating success, and a nonzero value,
>                        indicating that the handoff cannot be performed.

Seems foolish to all any non-zero to indicate error. Better to just
say 0 and 1 defined, rest are for future.

>    established.  The techniques which will solve this problem and allow
>    the MN to receive traffic independently of the timing of the L2
>    handoff event are currently under study by the Mobile IP WG but are
>    outside the scope of this document.

MIP WG has been closed...


-- 
Mip4 mailing list: [e-mail]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/