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

["Vijay Devarapallli" <[e-mail]>]

On Fri, Apr 4, 2008 at 5:13 PM, Hesham Soliman <[e-mail]> 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

>
>  Hesham
>
>
>
>  On 05/04/2008, at 11:11 AM, Vijay Devarapallli wrote:
>
> > 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
> > <[e-mail]> 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
> > > > [e-mail]
> > > > https://www1.ietf.org/mailman/listinfo/mipshop
> > > >
> > >
> > > _______________________________________________
> > > Mipshop mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mipshop
> > >
> > >
> >
>
>
_______________________________________________
Mipshop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mipshop