headers
Internet-Drafts | 1 Apr 2008 07:15
Picon
Favicon

I-D Action:draft-ietf-mipshop-3gfh-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility for IP: Performance, Signaling and Handoff Optimization Working
Group of the IETF.

	Title           : Mobile IPv6 Fast Handovers for 3G CDMA Networks
	Author(s)       : H. Yokota, G. Dommety
	Filename        : draft-ietf-mipshop-3gfh-06.txt
	Pages           : 27
	Date            : 2008-03-31

Mobile IPv6 is designed to maintain its connectivity while moving
from one network to another.  It is adopted in 3G CDMA networks as a
way to maintain connectivity when the mobile node moves between
access routers.  However, this handover procedure requires not only
movement detection by the MN, but also the acquisition of a new
care-of address and Mobile IPv6 registration with the new care-of
address before the traffic can be sent or received in the target
network.  During this period, packets destined for the mobile node
may be lost, which may not be acceptable for real-time application
such as Voice over IP (VoIP) or video telephony.  This document
specifies fast handover methods in the 3G CDMA networks in order to
reduce latency and packet loss during handover.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-3gfh-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
(Continue reading)

Permalink | Reply | 0 comments |
headers
Behcet Sarikaya | 1 Apr 2008 17:09
Picon
Favicon

Re: Last Call: draft-ietf-mipshop-fmipv6-rfc4068bis (Mobile IPv6 Fast Handovers) to Proposed Standard

I have a comment on this document on something that just came to my attention.

Starting from version 02, a little arrow has been added to Figure 3 which describes the reactive mode with Hi/Hack (if necessary) indication. This change was not properly marked in the change log. I understand that the origins of this change is "the need from the field, e.g. PMIP".

Sending a Handover Indication message by NAR which already knows that handover has already finished violates simple protocol engineering principles that we follow in designing protocol s. Similarly PAR sending Handover Acknowledge is problematic PDU naming.

Regards,

Behcet

----- Original Message ----
From: The IESG <iesg-secretary <at> ietf.org>
To: IETF-Announce <ietf-announce <at> ietf.org>
Cc: mipshop <at> ietf.org
Sent: Monday, February 25, 2008 7:39:28 AM
Subject: [Mipshop] Last Call: draft-ietf-mipshop-fmipv6-rfc4068bis (Mobile IPv6 Fast Handovers) to Proposed Standard

The IESG has received a request from the Mobility for IP: Performance,
Signaling and Handoff Optimization WG (mipshop) to consider the following
document:

- 'Mobile IPv6 Fast Handovers '
  <draft-ietf-mipshop-fmipv6-rfc4068bis-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2008-03-15. Exceptionally,
comments may be sent to iesg <at> ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-fmipv6-rfc4068bis-05.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14722&rfc_flag=0

_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
http://www.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
https://www.ietf.org/mailman/listinfo/mipshop
Permalink | Reply | 0 comments |
headers
Teco Boot | 3 Apr 2008 15:54
Picon

Re: [MEXT] TLV header in DSMIP

Hi Hesham,
I posted before on using TLV-encap for tunnel optimization (e.g. header
compression).
I think type values can be requested at time of defining protocols for this.
But I think tunnel optimization needs a more efficient TLV structure: 1
octet for only the type is needed, the other 3 octets are overhead and
should be eliminated.
Any objection mentioning such a usage? If not, we block something that
really makes sense.
Teco.

> -----Oorspronkelijk bericht-----
> Van: mext-bounces <at> ietf.org [mailto:mext-bounces <at> ietf.org] Namens Hesham
> Soliman
> Verzonden: donderdag 3 april 2008 10:45
> Aan: mext <at> ietf.org
> Onderwerp: [MEXT] TLV header in DSMIP
> 
> Folks,
> 
> During one of the reviews for DSMIP the issue came up regarding the
> TLV header Type field values and how the current spec doesn't describe
> how it can be used for IPsec.
> After looking into this a bit I don't see why we would need IPsec for
> this. We originally defined because people wanted to use GRE so the
> format would be:
> IP
> UDP
> GRE
> IP
> ...etc
> 
> It seems like it would be sufficient to only define this now for GRE
> and if someone comes up with a need for using IP/IPsec directly after
> the TLV header they can define that behaviour and request a new type
> value.
> 
> So the new draft would only allocate one value for GRE.
> 
> Any objections to this ? please respond quickly, we need to finish
> this ASAP.
> 
> Thanks,
> Hesham
> _______________________________________________
> MEXT mailing list
> MEXT <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mext
Permalink | Reply | 1 comment |
headers
Frank Xia | 5 Apr 2008 01:12
Favicon

MPLS Tunnel Support for Proxy Mobile IPv6

Hi folks
 
We just submitted a draft "MPLS Tunnel Support for Proxy Mobile IPv6"
Abstract:
 
The Proxy Mobile IPv6 allows a mobile node's IPv4 and IPv6 traffic
between a Local Mobility Anchor(LMA) and a Mobile Access Gateway
(MAG) to be tunneled using IPv6, IPv4 or IPv4-UDP encapsulation
headers.  In this document, Multiprotocol Label Switching (MPLS)
tunneling is proposed as an alternative tunnel technology which is
used between a MAG and a LMA.  MPLS is now become more and more
popular, and MPLS support is an important function for edge and core
routers.  Integrating MPLS and Proxy IP Mobility can leverage Proxy
IP Mobility deployment in the industry.
 
 
BR
Frank
 
 
_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
https://www.ietf.org/mailman/listinfo/mipshop
Permalink | Reply | 0 comments |
headers
Vijay Devarapallli | 5 Apr 2008 02:11
Picon

Re: AD review of mipshop-4140bis

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
<hesham <at> elevatemobile.com> 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
>  > Mipshop <at> ietf.org
>  > https://www1.ietf.org/mailman/listinfo/mipshop
>
>  _______________________________________________
>  Mipshop mailing list
>  Mipshop <at> ietf.org
>  https://www.ietf.org/mailman/listinfo/mipshop
>
Permalink | Reply | 501 comments |
headers
Hesham Soliman | 5 Apr 2008 02:13

Re: AD review of mipshop-4140bis

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

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
> <hesham <at> elevatemobile.com> 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
>>> Mipshop <at> ietf.org
>>> https://www1.ietf.org/mailman/listinfo/mipshop
>>
>> _______________________________________________
>> Mipshop mailing list
>> Mipshop <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/mipshop
>>
Permalink | Reply | 5 comments |
headers
Vijay Devarapallli | 5 Apr 2008 02:35
Picon

Re: AD review of mipshop-4140bis

On Fri, Apr 4, 2008 at 5:13 PM, Hesham Soliman <hesham <at> elevatemobile.com> 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
> > <hesham <at> elevatemobile.com> 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
> > > > Mipshop <at> ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/mipshop
> > > >
> > >
> > > _______________________________________________
> > > Mipshop mailing list
> > > Mipshop <at> ietf.org
> > > https://www.ietf.org/mailman/listinfo/mipshop
> > >
> > >
> >
>
>
Permalink | Reply | 3 comments |
headers
Hesham Soliman | 5 Apr 2008 02:39

Re: AD review of mipshop-4140bis


On 05/04/2008, at 11:35 AM, Vijay Devarapallli wrote:
> On Fri, Apr 4, 2008 at 5:13 PM, Hesham Soliman <hesham <at> elevatemobile.com 
> > 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.

=> 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
> 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
>>> <hesham <at> elevatemobile.com> 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
>>>>> Mipshop <at> ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/mipshop
>>>>>
>>>>
>>>> _______________________________________________
>>>> Mipshop mailing list
>>>> Mipshop <at> ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mipshop
>>>>
>>>>
>>>
>>
>>
> _______________________________________________
> Mipshop mailing list
> Mipshop <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mipshop
Permalink | Reply | 0 comments |
headers
Vijay Devarapallli | 5 Apr 2008 02:39
Picon

Re: AD review of mipshop-4140bis

I found some relevant comments from Steve Bellovin.

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

Vijay

On Fri, Apr 4, 2008 at 5:35 PM, Vijay Devarapallli <dvijay <at> gmail.com> wrote:
> On Fri, Apr 4, 2008 at 5:13 PM, Hesham Soliman <hesham <at> elevatemobile.com> 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
>  > > <hesham <at> elevatemobile.com> 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
>  > > > > Mipshop <at> ietf.org
>  > > > > https://www1.ietf.org/mailman/listinfo/mipshop
>  > > > >
>  > > >
>  > > > _______________________________________________
>  > > > Mipshop mailing list
>  > > > Mipshop <at> ietf.org
>  > > > https://www.ietf.org/mailman/listinfo/mipshop
>  > > >
>  > > >
>  > >
>  >
>  >
>
Permalink | Reply | 1 comment |
headers
Hesham Soliman | 5 Apr 2008 03:07

Re: AD review of mipshop-4140bis

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

On 05/04/2008, at 11:39 AM, Vijay Devarapallli wrote:
> I found some relevant comments from Steve Bellovin.
>
> https://datatracker.ietf.org/idtracker/ballot/1422/
>
> Vijay
>
> On Fri, Apr 4, 2008 at 5:35 PM, Vijay Devarapallli  
> <dvijay <at> gmail.com> wrote:
>> On Fri, Apr 4, 2008 at 5:13 PM, Hesham Soliman <hesham <at> elevatemobile.com 
>> > 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
>>>> <hesham <at> elevatemobile.com> 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
>>>>>> Mipshop <at> ietf.org
>>>>>> https://www1.ietf.org/mailman/listinfo/mipshop
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mipshop mailing list
>>>>> Mipshop <at> ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mipshop
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> _______________________________________________
> Mipshop mailing list
> Mipshop <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mipshop
Permalink | Reply | 0 comments |

Gmane