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

From: Pete McCann <[email-masked]>
Date: Tue, 18 May 2004 13:49:27 -0500

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: [email-masked]
    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/

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 May 2004 14:27:56 -0700

Pete,

> LL type  been done? Could it be done?

The CARD draft was recently rewritten to use SEND signatures based on the
SEND router certificates, as suggested by Steve Bellovin in the comments
Thomas refers to here. The Seamoby WG is still in the process of discussing
a few final comments about the document, but since CARD applies to IPv4 as
well as IPv6, a similar solution might apply here (of course, the rewritten
draft has not yet been through the IESG so there may yet be suprises in
store for the Seamoby WG). The new CARD security protocol drops IPsec for
the MN-AR interface and instead uses the SEND security association (IPsec
remains for the AR-AR interface, however).

One major issue is certificate exchange. In IPv6, the SEND DCS/DCA messages
can be used for certificate exchange on the same router, but there's nothing
like that for IPv4, even if the same signature format and certificate
profile as SEND is used. The solution for CARD is to define a certificate
exchange extension that works similarly to SEND, with the MN sending a list
of trusted roots and the AR sending back the chain for one of them. An
additional benefit that CARD provides is that the MN can solicit for
certificates to handover candidate access routers connected to APs that the
MN can see, thereby allowing the MN to have the certificate chain
preconfigured for the new AR prior to movement. This can result in
additional latency reduction for handover.

Provided the MIP4 WG was willing to go with CARD certificate exchange, the
SEND signature option could be reused for low latency handover PrxyRtXXX
messages as was done for CARD. The alternative option would be to try
defining something like DCS/DCA for IPv4, but there is little realistic
chance that it would be deployed, since AFAICT, hosts in IPv4 rarely use
router advertisments to discover their default routers, they use DHCP. The
exception is Mobile IPv4 FAAdverts, of course.

An alternative would be to reuse the MIPv4 MN-FA authentication extension
for low latency. If the WG decides that it likes that alternative better, it
might be a good idea to talk to Steve Bellovin and Russ Hously about it
first, to make sure they are OK with it, to avoid another IESG return.
While the SEND solution looks like a pretty good one from a technical
standpoint for this problem, the assumption is that Steve preferred that
solution since he explicitly mentioned it in his comments, which is
secondarily why it was used in CARD.

            jak