Subject: [Mip4] Comments on draft-ietf-mip4-nemo-haaro-02.txt

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 27 Oct 2010 16:30:08 +0200

Hello MIP4 WG,

This is the second time I read in detail a HAaRO document.  I think some
of my initial thoughts were considered already.

I do support this draft, and these are not my last comments on it.

It is 50-page long, has meaningful examples and message exchange diagrams.

The document describes a method to achiever optimized (shorter) routes
between two Mobile Routers of the same Home Agent, shorter than through
that Home Agent, but still with tunnels.  Basically, the HA communicates
to a MR the MNP/HoA/CoA of another MR (called "CR" for Correspondent),
such that their respective routing tables point to each other, rather
than through HA.

This method is novel compared to other RO methods discussed in MIPv6
context, in that it addresses the main MIPv6 RO security issue by taking
advantage of the transitivity of trust relationships between of HA and
MRs: if MR1 trusts HA and HA trusts MR2 then MR1 trusts MR2.

Additionally, the draft describes a procedure of developping trust
relationships (dynamically generating keys) by employing Return
Routability tests between two MRs.  This is new too compared to RR of
MIPv6 which is limited to Mobile Hosts.  The draft also describes
methods of compressing a set of IPv4 prefixes sharing a common leading
bit string, domain names ("realms"), NAT traversal, multiple HAs, and more.

I have a number of comments on the content.

My first comment is a question: is there a security problem of allowing
MR to perform RR tests on behalf of an LFN, without LFN agreeing to this?

> The basic premise is still the same; Mobile Routers, when
> registering to the Home Agent, either inform the Home Agent of the
> mobile network prefixes they are managing (explicit mode) or get
> prefixes assigned by Home Agent (implicit mode).

With respect to the implicit mode of rfc5177: I think the above text
makes a wrong assumption: it reads as if the HA assigns a prefix to the
MR upon registration.  This is not  happening so.  In implicit mode, the
prefix is already assigned to the MR by non-MIP means, and configured in
MR and in HA also by some non-MIP means.  HA does use a MIP-NEMO Prefix
Table which uses that prefix, but it is in addition to the prefix being
in its routing table.  In any case, that prefix is  not communicated by
HA to MR.

The same later on the draft says the same:
> implicit (statically configured or assigned by Home Agent).

The prefixes are never assigned by the HA, by current state of affairs
(no DHCPv4 Prefix Delegation for NEMOv4, expired daft-subnet-allocation,
etc.)

The same later on the draft:

> As noted, NEMO-supporting Home Agent already maintains, and in some
> cases assigns, information on which network prefixes are reachable
> behind specific Mobile Routers.

Again I think this is a misunderstanding because HA never assigns a MNP
to the moving network.

Then.

There are a number of typos throughout the draft, most of them very easy
to deal with and often the same pattern: "a" missing, "it's/its", "a/an".

> in an single organization

"an" should be "a".

> "; With"

should be "; with".

> The schema requires a Mobile Router to be able to receive messages
> from Home Agent and other Mobile Routers unsolicited - that is,
> without first initiating a request.

and soon below:

> Note that the redistribution of network prefix information from the
> Home Agent happens only during the registration signaling.  There are
> no "routing updates" from Home Agent except during re-registrations
> triggered by handovers, registration timeouts and specific
> solicitation.

It reads as this latter paragraph contradicts the former.  Reading the
former paragraph I understand that the HA may send a message to MR
without MR requesting it.  Yet the 2nd paragraph says there are no
"updates" and that this information from HA happens as re-registration
(a Reply from HA), timeouts (also initiated by MR) and specific
solicitation (S bit set in RegReq).

The comment: is it possible the HA sends a message to MR without MR
requesting it first? (as rfc3543 RegRevocation message sent by HA to MR,
without it being requested).  I hope not.

> Upon receiving registration reply with a Route Optimization prefix
> advertisement extension, the Mobile Router SHALL insert the Mobile
> Router Home Addresses included in the extension as a host-prefixes
> to the local Route Optimization Cache if they do not already exist.

I read the "host-prefix" as a "host-based route", i.e. a 32-bit
prefixlen route of the form: 192.0.1.1/32-192.0.1.2, where the .1 is the
MR's HoA and .2 is the gateway.

> The Route Optimization Cache contains mappings between potential
> Correspondent Router HoA's, network(s) associated with each HoA,
> network topology, and Return Routability procedure-related
> information.

In this list I think there should be the CoA too.

What is "network topology"?

Later on in the draft when reading "The above information on network
topology" makes think "network topology" is about NAT information and
how NATted addresses hide private addresses, or so.  Is it this?  I
think this is only a few aspects of what a network topology is.

> KRms

I think it should clarify this is a plural of KRm, like in "KRm's"(?)
because

> procedure, contains the Home nonce index for each CR-HoA
>
>
>
>
>
>
>
> Makela & Korhonen        Expires April 21, 2011                [Page
>  11]  Internet-Draft                    HAaRO October 2010
>
>
> Home keygen token  If the KRm was established with Return
> Routability procedure, contains the Home keygen token for each
> CR-HoA.

This reads as if the sentence on page 11 is not ended.

> Two messages are sent to Correspondent Router's Home Address, one via
> Home Agent using Mobile Router's Home Address, and the other directly
> from the Mobile Router CoA, with two responses coming through same
> routes.

I think the two responses come through different IP paths, not same
routes (although they can be forwarded according to same entries in
routing tables - what is a "route"?).  And yes, they must end at the
"same node".

> an desired external secure

"a" instead of "an" is better.

> Each Mobile Router maintains a 'correspondent router key', Kcr, which
> is MUST NOT be shared with any other entity.  Kcr is used for
> authenticating peer Mobile Routers in the situation where mobile
> router is acting as a CR.  This is analogous to node key, Kcn, in
> Mobile IPv6.  Correspondent Router uses router key to verify that the
> keygen tokens sent by Mobile Router in registration request are its
> own.

This last "its own"... CR's?  or MR's?

> 3.3.1.  Triggering Route Optimization

Is this section about triggering RO?  Or triggering starting RR?

I think when MR receives other MR's prefix from HA we already have RO in
place, although RR tests aren't performed yet... but I may be wrong.

> It is RECOMMENDED to start Route optimization only be started when
> receiving a packet where destination address is in a locally managed
> prefix (and the prefix is registered as route optimizable) and source
> address exists in the network prefixes of Route Optimization Cache.

Wrong twice use of "start", ok.

The 2nd condition ("source adress exists in the network prefix") is
ambiguous for implementation - how would an implementation make this
check?   Is this longest-prefix match?  (remark longest-prefix match is
specified and implemented for dst not src addresses).

Remark also that checking each incoming packet with a longest-prefix
match rule on the src may be time consuming (as opposed to typically not
making this check) and unnecessarily slowing a router down.

> In addition, host-routes to Correspondent Routers' Care-of addresses
>  SHOULD be associated with the assigned to the physical interfaces
> assigned with corresponding MR-CoA.

Wrong double use of "assign", should be once.

Too long formulation.  When shortened I could try to understand.

However, I doubt there is necessity to specify the need of a host-based
route towards the CoA - the default route should be sufficient, no?

> optimized tunnel

I am not sure what an optimized tunnel is.  It may be that is the tunnel
interface on MR towards the other MR, for optimizing the path.  But that
tunnel is not optimized ("optimized" with respect to what?).

> The Correspondent Router relies to the request

replies.

> When a Mobile Router wishes to leave network, it SHOULD, in addition
> to sending the registration request to the Home Agent with lifetime
> set to zero, also send such a request to all known Correspondent
> Routers.

This reads as if the MR wishes to join the home link, right?  Not to
leave network, right?

> the a new master prefix

the new master prefix...

> This also indicates that the Mobile Router is capable of receiving
> route optimization binding updates.

I think that's rather RO-capable RegReq instead of RO BU.

> Mobile Router optimization capability

should be "Mobile Router Route Optimization capability" throughout the
draft, there are two places.

> outer Mobile Routers

should be other Mobile Routers.

> S         Soliciting prefixes managed by specific Mobile Router.

... by _a_ specific MR reads better.

> The extension is only included when explicitly requested by the
> Mobile Router in the registration request message.

Yes, the R bit of the capability.

> 1-n times the following information structure

should be "1..n times" to avoid reading "-" as minus instead of range.

> Each network prefix can be associated with a realm

A "realm" is defined in rfc4282, reference would be good.

Alex