Subject: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03

From: Pete McCann <[email-masked]>
Date: Tue, 8 Feb 2011 10:12:25 -0600

Hi,

Below is my review of draft-ietf-mip4-nemo-haaro-03.  I'd like to see
some discussion on the major issues before we move to WGLC.

-Pete

Some issues in Section 3.2.3:

   The destination address is set to
   Correspondent Router's HoA.
This is only true of the HoTI and CoTI messages, right?  The text seems
to say that all 4 messages have their destination address set
to the CR's HoA.

   each containing a 64-bit random
SHOULD BE:
   each containing a (different) 64-bit random

It seems that 3.2.3 has a lot of text describing the route
optimization procedure which would be better moved into
its own sub-section.  Suggest renaming 3.2.3 as "Route
Optimization Overview" and putting "Updating Router keys and Nonces"
in its own Section 3.2.4.

In Section 3.2.3, try to be a bit more careful about describing
the IP source and destination addresses of each message.
I assume that the HoTI is sent with a source address equal
to the HoA of the MR, and the CoTI is sent with a source address
equal to the CoA of the MR.  Both are sent to the HoA of the CR.
The first must be reverse tunneled because it doesn't have a topologically
correct source address, but the CoTI does not need to be so tunneled
as long as the CR's HoA is globally routable.  The response HoT and CoT
messages are both sent from the CR's HoA and destined to the HoA and
CoA of the MR, respectively.  They must both be reverse tunneled
to the HA.  Is this right?

More text is needed on how the keygen tokens are derived from the nonces,
Kcrs, and CoAs.  I know you may be repeating some of the MIP6 spec but it would
be good for this spec to stand on its own.

Section 3.3.3:
   The registration request MUST be set to the Home
   Address.
SHOULD BE:
   The registration request MUST be sent to (have a destination
   address of) the Home
   Address of the Correspondent Router.

Section 3.4:
This section talks about triggering route optimization upon
reception of a packet from a known network; however, 3.3.1
focused on the trigger being the transmission of a packet.
Which is the preferred scenario?

Section 4:
The scheme for realm compression looks a bit complicated and
I don't completely understand the reason for defining a new
scheme that is so different from the one in RFC 1035.  You say
it achieves better compression but I think this is only true for
odd cases where you want to compress the middle labels of
a realm name that happen to match an earlier middle label but
where the suffix doesn't match.  I think it's more likely that
MRs homed on the same HA will share the same suffixes.

Also, DNS labels cannot be longer than 63 characters so you
might as well use the top 2 bits of the label length field as
DNS does (unless you think realm names have different rules?).

Section 5.5:
I thought that this Route Optimization Prefix Advertisement
extension was what provided each correspondent router with
the binding between MR HoA and mobile prefixes managed
by that HoA.  However, the rules given don't allow for the
occurrence of an MR HoA and a prefix in the same listing.
How exactly is the binding supposed to be achieved?

Sections 5.5 - 5.9:
You should add text describing how the IP and UDP fields
are set in these new messages.

Numerous editorial nits:

The last sentence of the Abstract is a bit confusing:
   The
   functionality adds possibility to discover eligible peer nodes based
   on information received from Home Agent, Network Prefixes they
   represent, and how to establish direct tunnel between such nodes.
Did you mean to say:
   The
   functionality adds the possibility to discover: eligible peer nodes based
   on information received from Home Agent; Network Prefixes they
   represent; and, how to establish a direct tunnel between such nodes.
?

Section 1:
   proposes method
SHOULD BE:
   proposes a method

   Although NAT and pending shortage of IPv4 addresses
   makes widespread deployment not feasible, using Route Optimization
   only in routers is still a practical scenario.
Maybe be a bit more specific about what is not feasible:
   Although NAT and the pending shortage of IPv4 addresses
   makes widespread deployment of end-to-end route optimization infeasible,
   using Route Optimization from mobile router to mobile router is
still a practical scenario.

   reliability and availability
SHOULD BE:
   reliability, and availability

   From service provider perspective
SHOULD BE:
   From a service provider perspective

   for enterprise
SHOULD BE:
   for an enterprise

   MPLS VPNs or Layer 3
SHOULD BE:
   MPLS VPNs, or Layer 3

   options however, are
   not reliable approach
SHOULD BE:
   options, however, are
   not a reliable approach

   In this example case, organization network
SHOULD BE:
   In this example case, the organization network

   two sites,
   that
SHOULD BE:
   two sites
   that

   to the backend to
   minimum.
SHOULD BE:
   on the backend to
   a minimum.

   beyond the need of a single, coordinating Home
   Agent.
Did you mean:
   removing the need for a single, coordinating Home
   Agent.
?

Section 3:
   domain; However, extranets
SHOULD BE:
   domain; however, extranets

   The procedure aim
SHOULD BE:
   The procedure aims

   are same
SHOULD BE:
   are the same

Section 3.1:
   regardless whether
SHOULD BE:
   regardless of whether

   indicated with
SHOULD BE:
   indicated with a
(two instances)

   extension, see Section 5.1.
SHOULD BE:
   extension; see Section 5.1.

   from Home Agent
SHOULD BE:
   from the Home Agent

   registration timeouts and specific
SHOULD BE:
   registration timeouts, and specific

Section 3.1.1
   As noted, NEMO-supporting Home Agent
SHOULD BE:
   As noted, a NEMO-supporting Home Agent

    Only change to this functionality
SHOULD BE:
    The only change to this functionality

   including Route Optimization capability extension,
   Section 5.1,
SHOULD BE:
   including a Route Optimization Capability extension
   (Section 5.1)

   MUST include Route Optimization Reply extension
   (Section 5.2) to indicate whether Route Optimization
   was accepted.
SHOULD BE:
   MUST include a Route Optimization Reply extension
   (Section 5.2) to indicate that the Route Optimization
   Capability extension was understood.

   informs Mobile Router if NAT was
SHOULD BE:
   informs the Mobile Router whether NAT was

   with according prefix(es)
SHOULD BE:
   with corresponding prefix(es)

   routers in
   customer's
SHOULD BE:
   routers in
   the customer's

   e.g.  Default prefix (0.0.0.0/0) pointing towards
   Internet gateway for Internet connectivity, and possible extranets.
SHOULD BE:
   e.g. a default prefix (0.0.0.0/0) pointing towards
   an Internet gateway for Internet connectivity or additional prefixes
   belonging to possible extranets.

   within specific realm
SHOULD BE:
   within a specific realm

   share same
SHOULD BE:
   share the same

   receiving registration reply
SHOULD BE:
   receiving a registration reply

   as a host-prefixes to
SHOULD BE:
   as host-prefixes into

   SHALL also be inserted
   to
SHOULD BE:
   SHALL also be inserted
   into

Section 3.1.2:
   from Home Agent
SHOULD BE:
   from the Home Agent

   prefix advertisements, and in registration messages
SHOULD BE:
   prefix advertisements and in registration messages

   direction, see Section 3.3.4
SHOULD BE:
   direction; see Section 3.3.4

             in Care-of-address extension in registration reply.
             If the entry exists,
SHOULD BE:
             in the Care-of-address extension of a registration reply.
             If set to true,

             from Route
             Optimization Cache as long as tunnel
SHOULD BE:
             from the Route
             Optimization Cache as long as a tunnel

             using Return Routability procedure, they
             are calculated in-situ based on nonces and router key.
SHOULD BE:
             using a Return Routability procedure, it
             is calculated in-situ based on nonces and a router key.

   Care-of nonce indexes  If the KRm was established with Return
SHOULD BE:
   Care-of nonce indices
             If the KRm was established with a Return
(Put a newline and indent all of the descriptions in the remainder
of this section)

Section 3.2:
   Same principles
SHOULD BE:
   The same principles

   Two messages
SHOULD BE:
   two messages

   to Correspondent Router's Home Address, one via Home Agent using
   Mobile Router's Home Address,
SHOULD BE:
   to the Correspondent Router's Home Address, one via the Home Agent using
   the Mobile Router's Home Address

   by Mobile IP
   protocol
SHOULD BE:
   by the Mobile IP
   protocol

   mechanism,
   Return Routability procedure
SHOULD BE:
   mechanism,
   the Return Routability procedure

   Assumption on traffic patterns
SHOULD BE:
   The main assumption on traffic patterns

   where mobile
   router is acting as a CR.
SHOULD BE:
   where a mobile
   router is acting as a CR.

Section 3.2.1:
   Correspondent Router uses router key to verify that the
   keygen tokens sent by Mobile Router in registration request are the
   CR's own.
SHOULD BE:
   A Correspondent Router uses its router key to verify that the
   keygen tokens sent by a peer Mobile Router in a registration request are the
   CR's own.

   nonces, see
SHOULD BE:
   nonces; see

Section 3.2.2:
   The Mobile Router may use same nonces with all Mobile Routers.
SHOULD BE:
   The Mobile Router may use the same nonces with all Correspondent Routers.

Section 3.2.3:
   whose lifetime have
SHOULD BE:
   whose lifetimes have

   Nonce should be kept acceptable
SHOULD BE:
   A nonce should remain valid

Section 3.3:
   The Mobile Router learns Correspondent Router's Care-of
   address by a new extension, "Care-of Address", in registration reply.
SHOULD BE:
   The Mobile Router learns the Correspondent Router's Care-of
   address by a new extension, "Care-of Address", in the registration reply.

   Second issue is rising from security standpoint: In a registration
SHOULD BE:
   The second issue is a security consideration: in a registration

   re-registration to Home Agent
SHOULD BE:
   re-registration to the Home Agent

   Additional aspect is that Mobile Router MAY use different Care-of-
   Address for different Correspondent Routers
SHOULD BE:
   An additional aspect is that a Mobile Router MAY use a different Care-of-
   Address for different Correspondent Routers

   where network provides
SHOULD BE:
   where the network provides

Section 3.3.1:
   at any time; However a better
SHOULD BE:
   at any time; however, a better

   and destination address exists  in
   the network prefixes of Route Optimization Cache.
SHOULD BE:
   and whose destination address falls within
   the network prefixes of the Route Optimization Cache.

   With small number
SHOULD BE:
   With a small number

Section 3.3.3:
   between Mobile Router and Correspondent Router
SHOULD BE:
   between a Mobile Router and a Correspondent Router

   either Return Routability procedure
SHOULD BE:
   either the Return Routability procedure

   from desired interface
SHOULD BE:
   from the desired interface

   address of desired outgoing interface
SHOULD BE:
   address of the desired outgoing interface

   The address MAY be same as the Care-of address used with
   Home Agent.
SHOULD BE:
   The address MAY be the same as the Care-of address used with
   the Home Agent.

   MUST include Mobile-Correspondent
   Authentication extension
SHOULD BE:
   MUST include a Mobile-Correspondent
   Authentication extension

   SHOULD include
   Mobile Network Request Extension
SHOULD BE:
   SHOULD include
   a Mobile Network Request Extension

   The registration reply MUST include Mobile-Correspondent
   Authentication extension
SHOULD BE:
   The Registration Reply MUST include a Mobile-Correspondent
   Authentication extension

   conditions apply, registration request
SHOULD BE:
   conditions apply, the Registration Request

   to facilitate detecting
SHOULD BE:
   to facilitate detection

   (see Section
   (Section 10)
SHOULD BE:
   (see Section 10)

   in it's Route Optimization Cache
SHOULD BE:
   in its Route Optimization Cache

   by incoming Mobile Router
SHOULD BE:
   by the incoming Mobile Router

   arbitrary networks; However, since Home Agent
SHOULD BE:
   arbitrary networks; however, since the Home Agent

   authorize Mobile Router's claim
SHOULD BE:
   authorize the Mobile Router's claim

   registrations from without this check
SHOULD BE:
   registrations without this check

   and Route Optimization Cache updated.
SHOULD BE:
   and the Route Optimization Cache updated.

   The reply MUST include a list
   of eligible care-of-addresses for the tunnel in Section 5.4, with
   which the Mobile Router may establish a tunnel with.
SHOULD BE:
   The reply MUST include a list
   of eligible care-of-addresses (see Section 5.4) with which
   the Mobile Router may establish a tunnel.

   Mobile-Correspondent Authentication
   extensionSection 5.3.
SHOULD BE:
   Mobile-Correspondent Authentication
   extension (see Section 5.3).

   The Correspondent Router's routing table MUST be updated to include
   the Mobile Router's networks are reachable
SHOULD BE:
   The Correspondent Router's routing table MUST be updated to indicate
   that the Mobile Router's networks are reachable

   but only only act on it
SHOULD BE:
   but only act on it

Section 3.3.4:
   firewall.A deviation from RFC 3519 [RFC3519] is that keepalives
   should be sent both from ends of the tunnel
SHOULD BE:
   firewall.  A deviation from RFC 3519 [RFC3519] is that keepalives
   should be sent from both ends of the tunnel

   sending it's own
SHOULD BE:
   sending its own

   in second
SHOULD BE:
   per second

Section 3.3.6
   join home link
SHOULD BE:
   join its home link

   if it's Route Optimization Cache
SHOULD BE:
   whether its Route Optimization Cache

   in the
   order of ten seconds
SHOULD BE:
   on the
   order of ten seconds

   at it is
SHOULD BE:
   it is

   have to also be acquired
SHOULD BE:
   have also to be acquired

Section 3.4:
   assumption is that at
   least
SHOULD BE:
   assumption that at
   least

   registers; Receives
SHOULD BE:
   registers and receives
(3 instances)

   receives to traffic
SHOULD BE:
   receives traffic

---

From: jouni korhonen <[email-masked]>
Date: Wed, 9 Feb 2011 13:51:39 +0200

Hi Pete,

Thanks for a thorough review. I cut the excess away to get to the realm part..

> The scheme for realm compression looks a bit complicated and

Actually it was a breeze to implement, since it is just adding strings into a data structure and later getting an index to a searched string from there.

> MRs homed on the same HA will share the same suffixes.

Could be. But still not a reason why we could not beef up something that was done -87 ?

> DNS does (unless you think realm names have different rules?).

The algorithm handles strings as a "blob" up to 127 octets. That property is used e.g. when the "longest non-matching string" actually spans multiple labels of a realm and then pushed into the dictionary. So essentially we can assign an index to a multi-label realms (or parts of it) as long as the total length is < 128 octets.

- Jouni

---

From: Pete McCann <[email-masked]>
Date: Wed, 9 Feb 2011 09:49:26 -0600

Hi, Jouni,

> Could be. But still not a reason why we could not beef up something that was done -87 ?

I just worry about the draft running into problems with reviewers
because of the extra complexity; in some ways, compression is
really orthogonal to the purpose for which the draft was written.
I understand that this is a case where the extension might contain
lots of realms and therefore compression is a good idea for scalability,
but it isn't really required for correct operation.  Re-using something
already specified and implemented in many places seems like a
safer alternative.

>From the text it looks like you are encoding one label at a time,
and using the length field in the same way as RFC 1035.  I don't
think there is any constraint on the length of the strings in the dictionary.
Of course, if you eliminated one bit from the index encoding you would
be limited to 63 dictionary entries instead of 127.  (it also seems to me
inefficient and inelegant to empty the dictionary when it overflows - why
not have an LRU replacement strategy?)

Anyway, if we had an extra bit in the label length field we could use extended
label types from EDNS0, and maybe define a new extended label type to
improve on the compression of RFC1035 by allowing for offsets greater
than 63.

Just a thought.  I know you've already implemented your scheme and would
like to stick with it.  Let's see if anyone else has comments on the right
direction here.

-Pete

---

From: Jouni <[email-masked]>
Date: Wed, 9 Feb 2011 18:28:31 +0200

Hi Pete,

> already specified and implemented in many places seems like a

Well.. at the beginning we got some much concerns from others regarding the possible packet size growth.

> From the text it looks like you are encoding one label at a time,

From 4.2.1

   ..
   dictionary based algorithm, which is designed to compress arbitrary
   length text strings.  In this scheme, an entire realm, a single label
   or a list of labels may be replaced with an index to a previous
   occurrence of the same string stored in the dictionary.  The realm
   ..
   dictionary.  The realms are compressed label by label or as a list of
   labels.  The dictionary can hold maximum 128 strings.  Thus, when

> not have an LRU replacement strategy?)

Because I was lazy to be honest ;) Such addition would be easy to do, though. And we probably should add LRU there.

> improve on the compression of RFC1035 by allowing for offsets greater

Realms are not necessarily something that are put into DNS. RFC4282 does not have such requirements. However, in certain cases, like with RFC3588, realms are explicitly said to be piggybacked on DNS.

> like to stick with it.  Let's see if anyone else has comments on the right

Ok.

- JOuni