Subject: Re: [Mipshop] AD review of mipshop-4140bis

From: "Vijay Devarapallli" <[email-masked]>
Date: Fri, 4 Apr 2008 17:11:19 -0700

Hesham,

We need to add a paragraph that explains what changed from RFC 4140,
and why it is now a Proposed Standard instead of Experimental. The IESG
wanted something along these lines for 4068bis. I suspect they would want
such a paragraph/section even for 4140bis.

Vijay

On Sun, Mar 30, 2008 at 6:36 PM, Hesham Soliman
<[email-masked]> wrote:
> Hi Jari, all,
>
>  Please take a look at the new revision at:
>  http://www.elevatemobile.com/ietf/draft-ietf-mipshop-4140bis-02.txt
>
>  and let me know if you're happy with the way your comments were
>  addressed. If you are, I'll submit it.
>
>  Cheers,
>  Hesham
>
>  On 17/01/2008, at 1:35 AM, Jari Arkko wrote:
>  > I have made my AD review of this document. Please find detailed
>  > comments
>  > below.
>  >
>  > Overall, I was pleasantly surprised by this specification. It is in
>  > relatively good shape and while there are issues, there are generally
>  > minor and mostly solvable by removing the offending parts. I was happy
>  > with the security parts. The main issues that I have are the flooding
>  > scheme and the error recovery parts.
>  >
>  > I expect some discussion and a new draft revision. After that we can
>  > go
>  > to IETF Last Call.
>  >
>  > Technical:
>  >
>  > >    This specification allows a mobile node to use more than one
>  > RCoA if
>  > >    it received more than one MAP option.  In this case, the mobile
>  > node
>  > >    MUST perform the binding update procedure for each RCoA.
>  >
>  > This MUST seems overly strong. Why would the mobile node be forced to
>  > use more than one MAP, if it only wanted to use one? See also further
>  > below where some inconsistencies with the above have been detected.
>  >
>  > >    Note that a mobile node may send a BU containing its LCoA
>  > (instead of
>  > >    its RCoA) to correspondent nodes, which are connected to its same
>  > >    link.  Packets will then be routed directly without going
>  > through the
>  > >    MAP.
>  > How does this happen? If two nodes sit on the same link and employ
>  > MAP(s) and home agent(s), they will only see each other's RCoAs and/or
>  > HoAs. They would see each other's care-of addresses when route
>  > optimization is attempted. But per your specification above you may
>  > not
>  > attempt it with your local address unless you already know the other
>  > node is on the same link. Chicken and egg...
>  >
>  > Suggestion: do not restrict the type of address the nodes may use in
>  > route optimization.
>  >
>  > >    Upon reception of a router advertisement with the MAP option, the
>  > >    receiving router MUST copy the option and re-send it after
>  > >    incrementing the Distance field by one.
>  > I hope you do not mean re-sending every RA again on another interface,
>  > triggered by the reception. This would disturb the router's own timing
>  > and processing of RAs. Please clarify the text to indicate that the
>  > received RAs are only used for learning the information, and then the
>  > information is used in the router's own independent RA sending
>  > process.
>  >
>  > >    The MAP option is propagated towards ARs in its domain.
>  > I'm not convinced that the dynamic distribution of MAP information is
>  > useful. First of all, its a very small configuration task compared to
>  > some of the other things you would have to have in this environment
>  > (e.g., security policies and key material allowing each mobile node to
>  > talk to each MAP securely).
>  >
>  > Secondly, you seem to be assuming that the MAP is placed in the router
>  > hierarchy. I would actually expect that a local domain's MAP would be
>  > placed in the same network as other servers and services exists, not
>  > necessarily in the aggregated router hierarchy that leads to the
>  > Internet. This would imply that a MAP RA would have to be distributed
>  > not just "down" but also "sideways" or even "up" if you draw the
>  > router
>  > placement in the network in a hierarchical manner. Of course, you can
>  > configure the routers to do this. But at the end of the day, you've
>  > created a complicated flooding scheme to achieve very little. And
>  > there
>  > may be error modes that we have not thought of.
>  >
>  > I would suggest removing the support for dynamic distribution, and
>  > simply requiring ARs to be configured with this information.
>  >
>  > >    A mobile node MUST store the received option(s) in order to
>  > choose at
>  > >    least one MAP to register with.  Storing the options is
>  > essential, as
>  > >    they will be compared to other options received later for the
>  > purpose
>  > >    of the movement detection algorithm.
>  > >
>  >
>  > The "at least one" part is right, in my opinion. But it is
>  > inconsistent
>  > with what I quoted earlier: "MUST perform the binding update procedure
>  > for each RCoA"
>  >
>  > >    If no MAP options are found in the router advertisement, the
>  > mobile
>  > >    node MUST use the Mobile IPv6 protocol, as specified in [1 <http://tools.ietf.org/html/draft-ietf-mipshop-4140bis-01#ref-1
>  > >].
>  > >
>  >
>  > Hmm. I think MUST NOT use HMIP would be more appropriate within the
>  > specification of how to deal with MAP options. You are assuming that
>  > whoever implements your spec will also implement and be able to use
>  > Mobile IPv6 (including, for instance, having a home agent).
>  >
>  > > 10. Detection and Recovery from MAP Failures
>  >
>  > Paragraph 1 is good, but the rest seems suspect.  For instance, on a
>  > large domain having every AR send this many pings to the MAP would by
>  > itself create a problem. And I am not sure this document should be
>  > dictating a specific mechanisms where service provider infrastructure
>  > keeps aware of what's up and what's not. I would suggest removing
>  > everything else except the ability of mobile nodes to react to zero
>  > lifetime. Or perhaps even that could be removed, if you simply
>  > recommended that if routers become aware of inability to reach the
>  > MAP,
>  > the MAP option is deleted from RAs.
>  >
>  > Editorial:
>  >
>  > Please correct the issues from
>  >
>  > http://tools.ietf.org/wg/mipshop/draft-ietf-mipshop-4140bis/draft-ietf-mipshop-4140bis-01.nits.txt
>  >
>  > >    It is pertinent to note that the use of the MAP does not reply or
>  > >    assume that a permanent Home Agent is present.
>  >
>  > s/reply/rely/
>  >
>  > >    The mobile node can communicate with a correspondent node
>  > through the
>  > >    HA, or in a route-optimised manner, as described in [1 <http://tools.ietf.org/html/draft-ietf-mipshop-4140bis-01#ref-1
>  > >].  When
>  > >    communicating through the HA, the message formats in [1 <http://tools.ietf.org/html/draft-ietf-mipshop-4140bis-01#ref-1
>  > >] can be re-
>  > >    used.
>  > s/can be re-used/are used/
>  >
>  > > This specification does not provide an algorithm
>  > >    for the distance-based MAP selection.  However, such an
>  > algorithm may
>  > >    be introduced in future extensions utilising information about
>  > the
>  > >    speed of mobility from lower layers.
>  > >
>  > >    ... The following algorithm is simply based on selecting the
>  > >    MAP that is most distant, provided that its preference value
>  > did not
>  > >    reach a value of zero.  The mobile node operation is shown below:
>  > >
>  > >    1.  Receive and parse all MAP options
>  > An apparent inconsistency. Do you provide a distance-based algorithm
>  > or
>  > not? Note that there might be different algorithms, better/perfect,
>  > etc., but that was not what the text was claiming.
>  >
>  > >    This is achieved by using the RCoA as the identity in IKE Phase 2
>  > >    negotiation.  This step is identical to the use of the home
>  > address
>  > >    in IKE phase 2.
>  > >
>  > I think you mean child SA creation, not phase 2. Phase 2 was an IKEv1
>  > concept. I see that Vijay noted this as well in his review.
>  >
>  > Jari
>  >
>  >
>  >
>  > _______________________________________________
>  > Mipshop mailing list
>  > [email-masked]
>  > https://www1.ietf.org/mailman/listinfo/mipshop
>
>  _______________________________________________
>  Mipshop mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/mipshop
>
_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 5 Apr 2008 11:13:42 +1100

Then I would need help from someone to tell me why it is now PS and  
not experimental.
I can obviously add the changes from 4140.

Hesham

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Fri, 4 Apr 2008 17:35:06 -0700

On Fri, Apr 4, 2008 at 5:13 PM, Hesham Soliman <[email-masked]> wrote:
> Then I would need help from someone to tell me why it is now PS and not
> experimental.

I don't know all the reasons why 4140 was experimental. You probably
know better.

The one reason that I know off (and understood) is that 4140 relied on the
use of IKEv1 whereas 4140bis uses IKEv2. IKEv2 provides a mechanism
(EAP) to enable authentication between a mobile node and a MAP that
belong to different domains. IKEv1 didn't have such a mechanism. So
this meant, 4140 didn't really specify a mechanism for MN-MAP mutual
authentication that would work in all cases. Hence it was
experimental.

I vaguely remember some issues about scalability. I wasn't involved in
those discussions.

>  I can obviously add the changes from 4140.

Ok.

Vijay

> > > > >  node MUST use the Mobile IPv6 protocol, as specified in [1
> <http://tools.ietf.org/html/draft-ietf-mipshop-4140bis-01#ref-1
> > > > > ].
> > > > >
> > > > >
> > > >
> > > > >  HA, or in a route-optimised manner, as described in [1
> <http://tools.ietf.org/html/draft-ietf-mipshop-4140bis-01#ref-1
> > > > > ].  When
> > > > >  communicating through the HA, the message formats in [1
> <http://tools.ietf.org/html/draft-ietf-mipshop-4140bis-01#ref-1
> > > > > ] can be re-
> > > > >  used.
> > > > >

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 5 Apr 2008 11:39:21 +1100

On 05/04/2008, at 11:35 AM, Vijay Devarapallli wrote:
> On Fri, Apr 4, 2008 at 5:13 PM, Hesham Soliman <[email-masked] 
> > wrote:
> belong to different domains. IKEv1 didn't have such a mechanism.

=> Yeah, that wasn't the reason. Wasn't even discussed.
I'll see if Jari can suggest something. May be I can blame it on MAP  
discovery.

Hesham

> So

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Fri, 4 Apr 2008 17:39:29 -0700

I found some relevant comments from Steve Bellovin.

https://datatracker.ietf.org/idtracker/ballot/1422/

Vijay

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 5 Apr 2008 12:07:44 +1100

Steve Bellovin's comments were addressed to his satisfaction. You can  
start here:
http://www.ietf.org/mail-archive/web/mipshop/current/msg00787.html

and follow the thread.

Hesham

---

From: Jari Arkko <[email-masked]>
Date: Mon, 07 Apr 2008 14:50:55 +0300

Hesham,

Before I forget: please ensure that changes that were introduced to RFC
4140 by the RFC Editor are also in the 4140bis. Sometimes authors start
from their old source and miss this. See the diff URL below; I have not
looked at if the changes in the current draft or not. Please check them
before submitting a new version.

http://www.arkko.com/ietf/mipshop/rfc4140-from-draft-ietf-mipshop-hmipv6-04.diff.html

See also http://www.ietf.org/mail-archive/web/ietf/current/msg51214.html

Jari

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 7 Apr 2008 21:52:52 +1000

> before submitting a new version.

=> Good catch, thanks for that. Are you ok with the current doc?  
Should I submit?

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 7 Apr 2008 21:58:58 +1000

It looks like I actually started off with the RFC not my last version  
of the draft, so just let me know if the changes are ok and I'll submit.

Hesham

---

From: Jari Arkko <[email-masked]>
Date: Mon, 07 Apr 2008 15:12:19 +0300

Hi Hesham,

And thanks for the new version. I have looked at it and most things are
now in order, good! There are a few minor remaining issues:

1) The history has to be there, i.e., what changed from 4140. Also, you
need to include a paragraph or two about what kind of "experiment" has
been going on with 4140. I.e., have people used it, implemented it,
whether there was any testing, etc. You don't need to invent any fancy
results, simply state what has or has not been done.

2) Typo: 1. eceive and parse all MAP options.

3) This still needs a change:
OLD:
Note that a mobile node may send a BU containing its LCoA (instead of
its RCoA) to correspondent nodes, which are connected to its same
link. Packets will then be routed directly without going through the
MAP.
NEW:
Note that a mobile node may send a BU containing its LCoA (instead of
its RCoA) to correspondent nodes. If these nodes are connected to the same
link, packets will then be routed directly without going through the
MAP.

4) Delete this because its inconsistent with later text that actually
defines an
distance-based algorithm:

This specification does not provide an algorithm
for the distance-based MAP selection. However, such an algorithm may
be introduced in future extensions utilising information about the
speed of mobility from lower layers.

5) Typo: KEv2 allows the

I'm expecting a revised ID. The above changes should be easy to do, when
can we see the new revision?

Jari

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 7 Apr 2008 22:28:37 +1000

> can we see the new revision?

=> Tomorrow morning my time, so if you're up late you'll see it.
Ok to all of the above BTW.

Hesham

---

From: Jari Arkko <[email-masked]>
Date: Mon, 07 Apr 2008 17:01:18 +0300

Hesham,

> I can obviously add the changes from 4140.
I don't think I was around in this WG at the time the decisions about
4140's status were taken. However, I would expect that its been
experimental so that you can

- gain implementation experience on parts that we were uncertain of
(like discovery)
- allow you to test something that may not have had a complete security
story in the initial document
- gain deployment interest
- etc

However, you don't actually need to explain in this document why the old
RFC was Exp. Just explain what the differences are, and what you've
learned from the "experiment" after publication of RFC 4140.

Jari