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

[Alexandru Petrescu <[e-mail]>]

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

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.
> I think this is unnecessary complexity. Suggest deleting this 
> possibility.

Ok, just deleted this possibility and text.  I've also checked - I think
in no other place does the text mention 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.

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

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

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

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

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.

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

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 
______________________________________________________________________


-- 
Mip4 mailing list: [e-mail]
    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/