[Mip4] AD review of draft-ietf-mip4-nemo-v4-base

Jari Arkko <jari.arkko@piuha.net> Mon, 21 January 2008 15:40 UTC

Return-path: <mip4-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGyku-0001vU-TE; Mon, 21 Jan 2008 10:40:12 -0500
Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1JGykt-0001qk-DI for mip4-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 10:40:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGykt-0001qc-3J for mip4@ietf.org; Mon, 21 Jan 2008 10:40:11 -0500
Received: from p130.piuha.net ([2001:14b8:400::130] helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGyks-0001GX-H7 for mip4@ietf.org; Mon, 21 Jan 2008 10:40:11 -0500
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id D03F2198CF9; Mon, 21 Jan 2008 17:40:09 +0200 (EET)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 9744E198CAF; Mon, 21 Jan 2008 17:40:09 +0200 (EET)
Message-ID: <4794BCDC.2050508@piuha.net>
Date: Mon, 21 Jan 2008 17:40:12 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.14pre (X11/20071022)
MIME-Version: 1.0
To: draft-ietf-mip4-nemo-v4-base@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: Mobile IPv4 Mailing List <mip4@ietf.org>
Subject: [Mip4] AD review of draft-ietf-mip4-nemo-v4-base
X-BeenThere: mip4@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip4@ietf.org>
List-Help: <mailto:mip4-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=subscribe>
Errors-To: mip4-bounces@ietf.org

I have reviewed this specification. It is generally in good shape. There
are a few observations below; I think you should address them but they
were not grave enough for me to block the progress of the document. If
you can, it would be helpful if you could revise the document in the
next few days, as I will be starting IETF Last Call.

Regarding recent discussion on the list, please do not introduce new
changes to the draft, except if there's a clear bug. Route optimization,
etc. should be out of scope.

Technical:

> Optionally, all requested Mobile
> Networks could be acknowledged using only one Mobile Network
> Acknowledgement extension with "Prefix Length" and "Prefix" fields
> set to zero. 
I think this is unnecessary complexity. Suggest deleting this possibility.

>    5.  Propagate Mobile Network Prefix routes via routing protocol
This seems unnecessary in some typical cases, such as when the home
agent already advertises a shorter prefix that contains this new prefix.

> The
>    solution described here does not place any restriction on the number
>    of levels for nested mobility.  But note that this might introduce
>    significant overhead on the data packets as each level of nesting
>    introduces another tunnel header encapsulation.
In fairness, it should be noted that this specification is incapable of
detecting loops in such nesting configurations. As a result, I think we
should warn the reader about these configurations with stronger language
than there is currently.

>    If a dynamic routing protocol is used between the Mobile Router and
>    the Home Agent to propagate the mobile network information into the
>    home network, the routing updates SHOULD be protected with IPsec ESP
>    confidentiality between the Mobile Router and Home Agent, to prevent
>    information about home network topology from being visible to
>    eavesdroppers.
>
>    A routing protocol message protected with ESP, and sent through the
>    Mobile Router - Home Agent bidirectional tunnel, SHOULD NOT contain
>    the Mobile IPv4 Mobile-Home Authentication Extension, since ESP
>    provides enough security.
Are you specifying how to protect the routing protocol in question (not
your job!) or merely requiring the tunnel packets carrying these routing
exchanges are ESP protected? If the former, revise. If the latter, OK.
But even in that case, is the Mobile IPv4 Mobile-Home Authentication
Extension really used on tunnel packets?

>    The policy of future assignments to this number space should be
>    following Expert Review.
>   
I believe "Standards Action or IESG Approval" would be more appropriate,
for reasons of ensuring interoperability.

Editorial:

>    Although Mobile IPv4 stated that Mobile Network can be supported by
>    the Mobile Router and Home Agent using static configuration or
>    running a routing protocol, there is no solution
I suppose you meant "Although the original Mobile IPv4 specifications
claimed that ..."

Jari



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