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

From: Mäkelä Antti <[email-masked]>
Date: Tue, 8 Feb 2011 16:57:16 +0000

Hi, thanks for all comments.

Based on this I'd say that most of these changes are editorial, some clarifications and one glaring mistake (in 3.4), which is in due to earlier change that wasn't reflected everywhere in the document. Biggest issue seems to be realm compression - this is something that Jouni can mostly comment on.

>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

  You are correct. Obviously the CoT/HoT's are replies to init messages.

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

  I'll see about this.

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

  This is correct.

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

  Correct as well.

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

  Very well - I'll add some more clarifications (even though it is slightly copy-paste from MIP6 spec).

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

  Agree.

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

  This is one of the changes made earlier due to comment on the list about computational cost of matching based on destination prefix instead of source prefix. The transmission is correct. I need to change 3.4's text as well - it's the old source prefix-matching behavior. Thank you very much for pointing this out.

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

  Jouni, can you comment?

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

  Yes it does - our implementation does too. As it says, it's "1..n times the following information structure".

  The idea is that if you only have a mobile node (no network), then n=1, and you have the extension as
  M=1, HoA=x.x.x.x

  If the MR also has a network, then next occurrence has
  M=0, Prefix=a.a.a.a/oo

  If the MR has additional network, then next occurrence is
  M=0, Prefix=b.b.b.b/pp

  If there's another mobile node in the network, then next occurrence is
  M=1, HoA=y.y.y.y

  ...and if it has network, well, you get the idea.

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

  Ok.

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: Mäkelä Antti <[email-masked]>
Date: Wed, 9 Feb 2011 10:57:24 +0000

Hello,

  I've now come up with -04 that as of this time has the following modifications. I'm waiting Jouni to comment on the realm compression portion. Apart from that, would these changes be satisfactory?

  Thanks.

--
- Antti Mäkelä | Researcher -
- Department of communications and networking -
- Aalto University -

>to say that all 4 messages have their destination address set

  This now reads:

The destination address of HoTI and CoTI messages is set to Correspondent Router's HoA with the sources being MR's home and care-of-address, respectively.

   >each containing a (different) 64-bit random

  Fixed.

>in its own Section 3.2.4.

  I'm assuming you mean "Return Routability Overview". There's plenty of overviews for RO as a whole :)

>be good for this spec to stand on its own.

  I've moved bulk of the original text to one level above, near the start of Section 3.2. 

  Anyway, regarding copypasting MIP6 spec - I think I already have covered.

  - Reasons for RR procedure
  - Message types
  - Message contents (Cookies, tokens, nonce indices)
  - Cookie: 64-bit random number
  - Nonce: Random number with a lifetime, indexed

  - Tokens: This wasn't explicitly specified how it's generated from cookie + nonce. I've added this information. I've added the following bit of text:

---
   Correspondent Router responds to HoTI and CoTI messages by
   constructing HoT and CoT messages, respectively, as replies.  The HoT
   message contains home init cookie, current home nonce index and home
   keygen token.  The CoT message contains care-of init cookie, current
   care-of nonce index and care-of keygen token.

   The Home Keygen token is constructed as follows:

   Home keygen token = First (64, HMAC_MD5 (Kcr, (home address | nonce |
   0)))

   The Care-of Keygen token is constructed as follows:

   Care-of keygen token = First (64, HMAC_MD5 (Kcr, (Care-of address |
   nonce | 1)))

   Note that the Care-of address in this case is the source address of
   the received CoTI message packet.  The address may have changed in-
   transit due to network address translation.  This does not affect
   registration process; subsequent registration requests are expected
   to arrive from the same translated address.
---

> Address of the Correspondent Router.

  Fixed.

>Which is the preferred scenario?

  This has now been fixed, and reads as follows. Sections 3.3.1 and the example diagrams were already as they should.

If a node in mobile network C is about to send traffic to mobile network A, the route optimization is straightforward; MR C already has network A in its Route Optimization Cache. Thus, packet transmission triggers Route Optimization towards MR A. When MR C registers to MR A (after Return Routability procedure is completed), MR A does not have information on mobile network C; Thus it will perform a re-registration to the Home Agent on-demand. This allows MR A to verify that MR C is indeed managing network C.

If a node in mobile network B sends traffic to mobile network C, MR B has no information on network C. No route optimization is triggered. However, when the node in network C replies and the reply reaches MR C, route optimization happens as above. Further examples of signaling are in (reference).

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

  Jouni?

>How exactly is the binding supposed to be achieved?

  Already explained - there can be 1..n information elements that can have both information. Only the first occurrence must have M=1 since you can't have prefixes without a MR.

>are set in these new messages.

  Are you sure this is needed in 5.5? It's an extension to the reply from HA.

  In 5.6 - 5.9, added the following text for 5.6:

This message is sent from Mobile Router to Correspondent Router when performing Return Routability procedure. The source and destination IP addresses are set to MR's Home Address and CR's Home Address, respectively. The UDP source port MAY be randomly chosen. The UDP destination port is 434.

5.7:

This message is sent from Mobile Router to Correspondent Router when performing Return Routability procedure. The source and destination IP addresses are set to MR's Care-of-Address and CR's Home Address, respectively. The UDP source port MAY be randomly chosen. The UDP destination port is 434.

and this for 5.8 and 5.9 (in 5.9 using "Care-of-Test Init" instead of "Home-Test init"):

This message is sent from Correspondent Router to Mobile Router when performing Return Routability procedure as a reply to Home-Test Init message. The source and destination IP addresses, as well as UDP ports, are reversed from the Home-Test Init message the message is constructed for. As such, the UDP source port is always 434.

>   represent; and, how to establish a direct tunnel between such nodes.

  Ok, for me, I see no difference in the meaning of these sentences, but I agree that semicolons make it a bit easier to understand.

  As for the rest, I've incorporated most of them. I'll mention ones I have question about. A lot of my cross-references were apparently broken in the text version - I've done my editing in XXE and didn't check the text version thoroughly.

>   removing the need for a single, coordinating Home

  No - I mean that currently the spec does not cover MR's connected to different Home Agents. However, it's not limiting that in any way, either - if the mobile nodes can learn of their peers via some other mechanism (DHT, DNS, whatnot) they don't need to use information from Home Agent for that but can still use other mechanisms in this spec - for single Mobile Nodes that is enough. For networks - well, if the MRs can in addition somehow verify an arbitrary MR's claim that they are representing a specific network, then they also have RO for networks.

  So hence, "beyond", not "removing".

  Maybe this form would be the best:

  "such as not being tied to a single Home Agent".

>             in the Care-of-address extension of a registration reply.

  also changed this to "care-of-addresses" since the extension supports multiple CoA's.

>(Put a newline and indent all of the descriptions in the remainder

  Also fixed Home nonce indices.

---

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

Hi, Antti,

Thanks for the quick turnaround.  A couple of comments/questions below:

>  I'm assuming you mean "Return Routability Overview". There's plenty of overviews for RO as a whole :)

Yes, "Return Routability Overview" would be fine.

>   The Home Keygen token is constructed as follows:

Was there a discussion in MIP6 on whether to use MD5 or SHA1
for this?  Just curious.  We probably don't want to depart too much
from the MIP6 spec but MD5 is pretty old and broken at this point.

>  Already explained - there can be 1..n information elements that can have both information. Only the first occurrence must have M=1 since you can't have prefixes without a MR.

Ok, maybe put some explanation in the text that the list is
a sequence of MR HoAs each followed by a list of prefixes
owned by that MR.

>  Are you sure this is needed in 5.5? It's an extension to the reply from HA.

Right, I meant 5.6.  Your text looks fine.
>  "such as not being tied to a single Home Agent".

Maybe say, "such as not requiring all MRs to be homed on the same Home Agent."

Other changes looks good.  Let's wrap up the discussion on compression with
Jouni and proceed from there.

-Pete

---

From: Mäkelä Antti <[email-masked]>
Date: Wed, 9 Feb 2011 16:04:16 +0000

Hi,

>from the MIP6 spec but MD5 is pretty old and broken at this point.

  Well, we went with MD5 since it's the standard in MIP4 - and you can reuse existing HMAC_MD5 functions when extending current implementations. Of course, best thing would of course be a free selection of hash algorithms, but none of the existing MIP4 structures really lend much to it at least as part of the protocol itself. 

>a sequence of MR HoAs each followed by a list of prefixes

  Ok - I've added a clarification before the figure:

"The extension contains a sequence of information structures. An information structure may consist of either an MR HoA or a network prefix. Any network prefixes following an MR HoA are owned by that MR. An MR HoA MUST be first in sequence, since you cannot have prefixes without an MR."

>Maybe say, "such as not requiring all MRs to be homed on the same Home Agent."

  Done.  

>Jouni and proceed from there.

  Great.

  - Antti

---

From: Pete McCann <[email-masked]>
Date: Wed, 9 Feb 2011 11:54:08 -0600

Hi, Antti,

>  Well, we went with MD5 since it's the standard in MIP4 - and you can reuse existing HMAC_MD5 functions when extending current implementations. Of course, best thing would of course be a free selec…

I think we should go with whatever was used for MIP6.  (was that SHA-1?)
I don't think it matters too much that we stick with MD5.  Any modern crypto
library will have HMAC_SHA1 as well.  This is new functionality so backwards
compatibility isn't a concern.

Other edits look good.

-Pete

---

From: Mäkelä Antti <[email-masked]>
Date: Wed, 9 Feb 2011 18:21:04 +0000

>compatibility isn't a concern.

  It's SHA-1 for MIP6. Our implementation right now goes with MD5, but I guess it's not too hard to replace that as such..

  Mostly I'm concerned about protocol fields and maintaining symmetry to existing MIP4 fields. SHA-1 is 160-bit hash, MD5 is 128 bits. The authenticator field in all other authenticators (foreigh-mobile, foreign-home, mobile-home etc) is essentially 128 bits, so using 160 bits for mobile-correspondent might affect processing since you cannot use same "template" as with processing the other authenticator fields. 

  Of course, you could always say that use First (128, HMAC_SHA1(xxx)), but at this point somebody who understands about crypto might start grinding their teeth...

  - Antti

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 9 Feb 2011 11:25:43 -0800

Hi Antti.  Comments below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mäkelä Antti
Sent: Wednesday, February 09, 2011 10:21 AM
To: Pete McCann
Cc: [email-masked]
Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03

  It's SHA-1 for MIP6. Our implementation right now goes with MD5, but I guess it's not too hard to replace that as such..
[Kent Leung (kleung)] Seems HMAC_SHA1 is better to use than MD5.  

  Mostly I'm concerned about protocol fields and maintaining symmetry to existing MIP4 fields. SHA-1 is 160-bit hash, MD5 is 128 bits. The authenticator field in all other authenticators (foreigh-mobile, foreign-home, mobile-home etc) is essentially 128 bits, so using 160 bits for mobile-correspondent might affect processing since you cannot use same "template" as with processing the other authenticator fields. 
[Kent Leung (kleung)] The Authentication Extensions are not limited to 128 bits since the Length field is used to indicate size of the Authenticator field.  If implementations are hard coded with 128 bits, then going with HMAC-MD5 (which is the default crypto for MIPv4).  Maybe by default it's HMAC_SHA1 (160 bits), with option for HMAC_MD5 (128 bits)?

Kent

  - Antti

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

---

From: Mäkelä Antti <[email-masked]>
Date: Wed, 9 Feb 2011 21:24:21 +0000

Hi,

  Specifying the used hash algorithm on a per-message basis is certainly possible. The authentication extension has a bunch of free bits as of now. It could be simply defined that if a bit is not set, the authenticator has been computed using MD5 and if yes, the authenticator has been configured using SHA-1.

  Anyway, picking one algorithm and sticking to it is probably easier (and doesn't cause a discussion on a minimum set that needs to be supported in implementations, and so on). Instead, I think there could perhaps be a wider effort to make the MIP4 messages support freely selectable crypto algorithms as a whole (has there ever been work on "selectable hash algorithm extension"?). 

  So if SHA-1 is better choice (it's been used with MIP6), the question becomes whether using truncated version to match other authenticator lengths is a good idea - actually, MIP6 only uses first 96 bits, not 128, so it's probably ok. As per RFC 3775,

      Mobility Data = care-of address | correspondent | MH Data
      Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data))

  So if I were to go SHA-1, I'd replace the authenticator with

  First(128, HMAC_SHA1(KRm, Protected Data))

  For Tokens and Krm, just change the algorithm:

  Home keygen token = First (64, HMAC_SHA1 (Kcr, (home address | nonce | 0)))

  and

  KRm = SHA1 (home keygen token | care-of keygen token)

  (Which pretty much makes them identical with MIP6).

  Anyway, if there's no one defending the use of MD5, I can make the above changes.

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 9 Feb 2011 13:28:36 -0800

The algorithm is selectable by SPI value.  For example, in MIPv4 deployments where some MNs supported keyed MD5 (due to backwards compatability) and other MNs support HMAC-MD5, the SPI in the MN-HA AE would select the right security association which contains the algorithm for authentication.

Kent

-----Original Message-----
From: Mäkelä Antti [mailto:[email-masked]] 
Sent: Wednesday, February 09, 2011 1:24 PM
To: Kent Leung (kleung); Pete McCann
Cc: [email-masked]
Subject: RE: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03

Hi,

  and

---

From: Mäkelä Antti <[email-masked]>
Date: Thu, 10 Feb 2011 05:36:51 +0000

Ok - I was under the impression that the SPI was only used to toggle e.g. usage of timestamps. 

________________________________________
From: [email-masked] [[email-masked]] on behalf of Kent Leung (kleung) [[email-masked]]
Sent: Wednesday, February 09, 2011 23:28
To: Mäkelä Antti; Pete McCann
Cc: [email-masked]
Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03

Kent

---

From: Pete McCann <[email-masked]>
Date: Thu, 10 Feb 2011 10:04:44 -0600

No, Kent is correct.  The SPI is an index to find the "security association",
which includes all aspects (secret, algorithm, replay protection method, etc).

If we need a method to dynamically update a security association (such as
was done with the MN-AAA extension) that is the time we need to worry
about encoding algorithms and such.

-Pete

---

From: Mäkelä Antti <[email-masked]>
Date: Thu, 10 Feb 2011 16:16:59 +0000

Very well. 

I'll update the draft to use SHA1 truncated to 128 bits (MIP6 uses 96 bits, so I'd think that truncation is ok). I checked and our implementation should bend to that very easily as well since the library already supports SHA1 as well.

Was there anything else to add to the realm compression discussion?

________________________________________
From: [email-masked] [[email-masked]] on behalf of Pete McCann [[email-masked]]
Sent: Thursday, February 10, 2011 18:04
To: Mäkelä Antti
Cc: Kent Leung (kleung); [email-masked]
Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03

-Pete

---

From: Jouni <[email-masked]>
Date: Thu, 10 Feb 2011 18:28:34 +0200

Antti,

> Was there anything else to add to the realm compression discussion?

We could add the LRU replacement algorithm instead of junking the whole dictionary, when it gets full. We have not implemented LRU though, so I have no idea how much better it would perform. I believe LRU would beat out current approach though, with a cost of few lines more of code and such. Up to you.

- Jouni

---

From: Mäkelä Antti <[email-masked]>
Date: Thu, 10 Feb 2011 17:13:38 +0000

>We could add the LRU replacement algorithm instead of junking the whole dictionary, when it gets full. We have not implemented LRU >though, so I have no idea how much better it would perform. I believe LRU would beat out current approach though, with a cost of few >lines more of code and such. Up to you.

  Hey,

The LRU should be doable. Currently, text says about filling the dictionary as such:

--
The dictionary can hold maximum 128 strings. Thus, when adding the 129th string into the dictionary, the dictionary MUST first be reset to the initial state (i.e. Emptied) and the index of the string will become 0.
--

Simplest change would of course be simply a rollover to the index that next one goes to index 0, but not flushing the dictionary. The implementation code footprint would remain the same as before.

However, a more LRU'ish way requires extra information - which *is* the least recently used entry. How's this (adds basically just a table of index entries, table length 128). Adds a second search when index becomes full, though.

-----
The dictionary can hold maximum 128 strings. When more strings are added into the dictionary, the least-recently entry MUST be discarded. 
----

And add in the end of 4.2.2 the details:

-----
Alongside the dictionary, a counter and a table of integers with 128 entries is maintained. The counter is initialized to 0 at the start of encoding or decoding process.

When a new string is to be inserted into the dictionary, and the dictionary is full, the table MUST be searched for the smallest value. The index of the value in the table becomes the index of the new dictionary entry. Existing entry MUST be discarded and replaced with the new string. If the dictionary is not full, the new string MUST be inserted into the end of the dictionary, and counter is stored at the same index.

When the search algorithm finds a match in existing labels, the current value of the counter MUST replace the existing value in the table at the label's index. 

The counter MUST increased whenever a new dictionary entry is inserted, or match is found during the search. 
------

This would result in a second table (where you can probably survive with unsigned shorts), and slow down processing somewhat, but probably be a bit more effective.

---

From: jouni korhonen <[email-masked]>
Date: Mon, 14 Feb 2011 08:43:02 +0200

Stuff inline.

> The LRU should be doable. Currently, text says about filling the dictionary as such:

Just need to make sure that it works in a case there are multiple strings with the same reference count. A dictionary entry reference counter overflow needs to be handled as well. Also a trivial dictionary replacement strategy, in the worst case, results into swapping of few strings.. Making these things without testing worries me a bit, to be honest.

> Alongside the dictionary, a counter and a table of integers with 128 entries is maintained. The counter is initialized to 0 at the start of encoding or decoding process.

"Each string in the dictionary is associated with a 16-bit reference count. The counter is initialized to 0 at the start of the encoding or decoding process. The 16-bt counter is treated as an unsigned integer."

> When a new string is to be inserted into the dictionary, and the dictionary is full, the table MUST be searched for the smallest value. The index of the value in the table becomes the index of the…

"When a new string is to be inserted into the dictionary, and the dictionary is full, then table MUST be searched for the string with the lowest reference count. If there are multiple strings with the (lowest) same reference count, the string with the smallest index value gets selected. The index of the selected string in the dictionary becomes the index of the dictionary entry to be replaced. The reference count to the new dictionary entry is left as it was earlier. If the dictionary is not full, the new string is inserted into the first available index in the dictionary and its reference count is initialized to 1."

> When the search algorithm finds a match in existing labels, the current value of the counter MUST replace the existing value in the table at the label's index. 

Dunno what the above is for... remove it.

> The counter MUST increased whenever a new dictionary entry is inserted, or match is found during the search. 

"When the search algorithm finds a match in the dictionary, the reference count of the string MUST be increased by one. If the reference count overflows, i.e. wraps from 65535 to 0, then the whole dictionary MUST be reset to the initial state (i.e.  emptied), the index of the string will become 0 and the reference count is initialized to 1."

> This would result in a second table (where you can probably survive with unsigned shorts), and slow down processing somewhat, but probably be a bit more effective.

No need for new tables in a conceptual sense. We just add a reference counter to each string and let it be like that.

- Jouni

---

From: Mäkelä Antti <[email-masked]>
Date: Mon, 14 Feb 2011 09:45:28 +0000

>> The dictionary can hold maximum 128 strings. When more strings are added into the dictionary, the least-recently entry MUST be >>iscarded.
>Just need to make sure that it works in a case there are multiple strings with the same reference count. A dictionary entry reference >counter overflow needs to be handled as well. Also a trivial dictionary replacement strategy, in the worst case, results into swapping of >few strings.. Making these things without testing worries me a bit, to be honest.

  Indeed, me too. Especially when there are not necessarily that much gains. Your reference counter approach seems ok on the surface, though.

  The simple adjustment option of simply NOT flushing the dictionary but overwriting from the bottom sounds most appealing to me instead of specifying a new scheme in a relatively ad-hoc fashion without an implementation. 

  Also, as our research showed, in the case where there are lots of realms with some common elements (such as example.com), the only loss you get is that at i=129 you have to re-introduce those few common labels - bad thing in case you have exactly 131 labels or so, but not really in a generic case.

  Pete - do you think this small change (not flushing, but overwriting from bottom) is ok, instead of LRU scheme? I can upload -04 as soon as you give the word.

---

From: Pete McCann <[email-masked]>
Date: Mon, 14 Feb 2011 08:56:02 -0600

>  Pete - do you think this small change (not flushing, but overwriting from bottom) is ok, instead of LRU scheme? I can upload -04 as soon as you give the word.

Yes, I'm all for simplicity.  This whole scheme (even with just
rolling over to the
bottom) seems like we're off in the weeds to me.  Go ahead and submit what you
think is best and I'll try to get some wider review from outside the WG.

-Pete

---

From: Mäkelä Antti <[email-masked]>
Date: Mon, 14 Feb 2011 15:34:10 +0000

Hi,

-04 submitted with all the changes discussed in the mailing list, including the SHA-1 change and the simpler version of realm compression adjustment (overwriting entries instead of resetting the entire dictionary).