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

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Jan 2008 17:40:12 +0200

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 Jan 2008 17:47:38 +0100

Jari, thanks for reviewing this document,

Jari Arkko wrote:
> 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.
> 
> changes to the draft, except if there's a clear bug. Route 
> optimization, etc. should be out of scope.

Ok.

> 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.

Ok, just deleted this possibility and text.  I've also checked - I think
in no other place does the text mention this possibility.

> agent already advertises a shorter prefix that contains this new 

That is right to me, in some deployments the mobile network prefixes are
aggregated into a shorter prefix which is already assigned as pointing
to HA, but in some cases it's not really the case.  Can we add [if
necessary] like this:

"5.  Propagate Mobile Network Prefix routes via routing protocol if
      necessary"

>> 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.

Ok, how about the following:

        "[...] The solution described here
	does not place any restriction on the number of levels for
	nested mobility.  Two issues should be noted though.  First,
	whenever physical loops occur in a nested aggregation of
	mobile networks this protocol does neither detect nor solve
	them - datagram forwarding may be blocked.  Second, Mobile
	Routers in a deep nested aggregation of mobile networks might
	introduce significant overhead on the data packets as each
	level of nesting introduces another tunnel header
	encapsulation."

>>  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.
>> 
>>  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?

Right, the goal is halfway towards the latter.  And I think indeed the 
Mobile-Home auth extension is only used on RegReq/Rep and not on the 
tunnelled packets.

Let's drop the following paragraph(?):
   "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."

> I believe "Standards Action or IESG Approval" would be more 
> appropriate, for reasons of ensuring interoperability.

Ok, modified it.  For info, the description of "Standards Action", "IESG 
Approval" and "Expert Review" are described in RFC2434 and to some 
extent RFC2780.  Other?

This could be discussed in the context of NEMO FA-extensions draft: 
would it prefer its RegRep Sub-type 'NEMOv4 Tunneling Extension' set by 
the HA allocated by a "Designated Expert"?  By "Standards Action"?  or 
by "IESG Review"?  I'd prefer the middle.

> I suppose you meant "Although the original Mobile IPv4 specifications

Right, modified it to say:
    "Although the original Mobile IPv4 specifications stated that Mobile
     Networks can be supported by the Mobile Router and Home Agent using
     static configuration or running a routing protocol (see Section 4.5
     of RFC 3344 [RFC3344]),"

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Jan 2008 19:07:35 +0200

> Can we add [if

OK.

>     level of nesting introduces another tunnel header

OK

>    provides enough security."

OK

> Ok, modified it.  For info, the description of "Standards Action",
> "IESG Approval" and "Expert Review" are described in RFC2434 and to
> some extent RFC2780.  Other?

draft-narten-iana-considerations-rfc2434bis, and you should add
reference to it.

> would it prefer its RegRep Sub-type 'NEMOv4 Tunneling Extension' set
> by the HA allocated by a "Designated Expert"?  By "Standards Action"? 
> or by "IESG Review"?  I'd prefer the middle.

Lets take that up separately. Just change the rules for this draft now.

>     static configuration or running a routing protocol (see Section 4.5
Good.

Thanks.

Jari