Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis

[[e-mail] (Arnaud Ebalard)]

Hi Charles,

"Charles E. Perkins" <[e-mail]> writes:

> Thanks for the terrific review and many suggestions.  I have been
> owing you a response on the specific questions and issues you
> raised.  So, here goes...

Well, thanks for your work too. Iterating over and over on the spec must
be a bit painful at some point. More fun below ... ;-)

Note that I did not remove any text from your reply so that you can
cross-check.


>>>       A Binding Acknowledgement is used to acknowledge receipt of a
>>>       Binding Update, if an acknowledgement was requested in the Binding
>>>       Update, the binding update was sent to a home agent, or an error
>>>       occurred.
>>>     
>>
>> As a binding update sent to a Home Agent must have the A bit set
>> (i.e. "an acknowledgement was requested in the Binding Update" as
>> stated above), a BA is always sent by the HA. This means the "the
>> binding update was sent to a home agent" is redundant in previous
>> paragraph.
>>   
>
> How about:
>
>                    if an acknowledgement was requested in the Binding
>      Update (e.g., the binding update was sent to a home agent), or an
>      error occurred.

fine with me.


>>>    attachment to other sites, resulting in possible unrechability
>>>    between the MN and the HA, when unique-local IPv6 routable addresses
>>>    are used as care-of addresses.  Also, CNs outside the MN's own site
>>>    are not going to be reachable when unique-local IPv6 routable
>>>    addresses are used as home addresses.  Therefore, unique-local IPv6
>>>    unicast addresses SHOULD NOT be used as home or care-of addresses.
>>>     
>>
>> If this is the only address usable as a CoA for the node, it is worth
>> trying to use it. I tried and found some discussion on the list about
>> this topic but failed (I thought it had been discussed). Can someone
>> give me some feedback on the reason it is that way?
>>   
>
> How about:
>
>                                                  unique-local IPv6
>   unicast addresses SHOULD NOT be used as home or care-of addresses
>   if any other addresses are available to the mobile node.

I think it is better. But I wonder if there is a need to make some
specific case for ULA. Basically, one would expect the MN to apply some
kind of RFC 3484 logic to select the CoA to be used as source address
for the connection with the HA (based on the HA address). I don't think
there is a need to go that far in the description but I also don't think
there is a need to make a specific case about ULA. IMHO, CoA selection
is a local matter for the MN.

>>    As with all IPsec security associations in this specification, manual
>>    configuration of security associations MUST be supported.  The used
>>    shared secrets MUST be random and unique for different mobile nodes,
>>    and MUST be distributed off-line to the mobile nodes.
>>
>>    Automatic key management with IKE [7] MAY be supported.  When IKE
>>   
>>
>> Any reason not to add a link to IKEv2 spec?
>>   
>
> Will do.
>
>>   
>>>    Reference [15] contains a more detailed description and examples on
>>>    using IPsec to protect the communications between the mobile node and
>>>    the home agent.
>>>     
>>
>> What about adding a link to 4877 too?
>>   
> O.K.
>>
>>   
>>> 5.3.  Dynamic Home Agent Address Discovery
>>>
>>>    No security is required for dynamic home agent address discovery.
>>>     
>>
>> May be it is the way I understanded it but this sounds like "no security
>> is needed". It should sounds like "No security is provided for that
>> mechanism".   
>
> As I remember the discussion, it was more properly represented by the
> existing text.  Perhaps opinions have changed in the meantime since this
> was originally written.  It's been a while, but I think the sense of
> the discussion at that time was that DHAAD would only be used in
> environments where security was not a problem.

ok.

>>>    This type provides the necessary functionality but does not open
>>>    vulnerabilities discussed in Section 15.1.
>>>     
>>
>> What about adding a link to RFC5095 here, i.e. "Section 15.1 and
>> [RFC5095]".
>>   
>
> O.K.
>
>>   
>>> 6.1.7.  Binding Update Message
>>>
>>>    The Binding Update (BU) message is used by a mobile node to notify
>>>    other nodes of a new care-of address for itself.  Binding Updates are
>>>    sent as described in Section 11.7.1 and Section 11.7.2.
>>>
>>>    The Binding Update uses the MH Type value 5.  When this value is
>>>    indicated in the MH Type field, the format of the Message Data field
>>>    in the Mobility Header is as follows:
>>>
>>>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>                                        |          Sequence #           |
>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>        |A|H|L|K|        Reserved       |           Lifetime            |
>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>        |                                                               |
>>>        .                                                               .
>>>        .                        Mobility options                       .
>>>        .                                                               .
>>>        |                                                               |
>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>    Acknowledge (A)
>>>
>>>       The Acknowledge (A) bit is set by the sending mobile node to
>>>       request a Binding Acknowledgement (Section 6.1.8) be returned upon
>>>       receipt of the Binding Update.
>>>
>>>    Home Registration (H)
>>>
>>>       The Home Registration (H) bit is set by the sending mobile node to
>>>       request that the receiving node should act as this node's home
>>>       agent.  The destination of the packet carrying this message MUST
>>>       be that of a router sharing the same subnet prefix as the home
>>>       address of the mobile node in the binding.
>>>     
>>
>> This prevents the MN to communicates with the HA on another
>> interface. Is there any reason for that limitation, i.e. not having a
>> SHOULD here instead of a MUST. Or I should ask, what is the reason to
>> have a MUST here.
>>   
>
> I couldn't think of a reason against using SHOULD instead of MUST.
> However, I don't remember anyone asking for this feature, and unless
> there is a reason to make the change, I would not relax that mandate.
>
>> For instance, the main connectivity of the home agent can be provided by
>> a given provided (symmetric line) while the MN are on a subnet for which
>> the prefix is provided by another provider. That way, the download
>> bandwidth used by the MNs is not shared with the upload bandwidth:
>>
>>      ISP1 -- home subnet ---[HA]--- ISP2
>>   
> In this picture, do you mean that the MN has a home address from
> ISP2, and it should be able to send a packet to the home agent via
> a destination address from ISP1?

No. Sorry for the unclear picture. The MN has a home address from ISP1
(home network prefix is from the prefix provided by ISP1) but connects
from a foreign network to the HA which is reachable from outside on an
address from ISP2.  

> but still it could be made workable, and one could establish a
> cost structure for the network which would favor the alternate
> control signal path.  But are there really such networks that need
> this solution?

Mine looks like what I describe above for the following reason: 

 - on ISP2, I have a SDSL (which costs a leg)
 - on ISP1, I have an ADSL (cheap and with good downlink)

When I am in a foreign network, downloading sth consume some upload
bandwidth from my SDSL and some download bandwidth from my ADSL.

If my HA address and my Home Network prefix were in a prefix provided by
ISP1 (ADSL), I would have a very limited upload bandwidth (i.e. download
as a MN).

If both were in a prefix provided by ISP2, downloading something as a MN
would saturate both directions on the SDSL.

Another example were it may be useful: a community of MN that are not
expected to speak *with* the outside world. In that case, you can use a
ULA prefix for the Home Net. But you want to allow the MN to communicate
*from* the outside world, i.e. from foreign networks outside the site.

I would have to check the spec, but I think the only thing that would
prevent to relax that MUST is the fact that the Home Agent List for
DHAAD is built using the HA address provided in the PIO in RA (section
7.2). Home Link Detection mechanism does not use the HA address but the
Home Prefix. 

I let you decide.


>>>       ...
>>>    The deletion of a binding can be indicated by setting the Lifetime
>>>    field to 0 and by setting the care-of address equal to the home
>>>    address.  In deletion, the generation of the binding management key
>>>    depends exclusively on the home keygen token, as explained in
>>>    Section 5.2.5.  (Note that while the senders are required to set both
>>>    the Lifetime field to 0 and the care-of address equal to the home
>>>    address, Section 9.5.1 rules for receivers are more liberal, and
>>>    interpret either condition as a deletion.)
>>>     
>>
>> For the records: 
>>
>> There is no rationale for explicitly providing different behavior for
>> senders and receivers. The various rules associated with what can and
>> should be done on that aspects are spread at various places in the
>> spec. I already discussed that in draft-ebalard-mext-hld-security-00.
>>   
>
> I'm not sure what to do to resolve your issue.  Your first sentence
> is, in the abstract, incorrect; for example, we are exhorted to be
> conservative in what we send, but liberal in what we accept. 

Yes, but this does not mean that we MUST create different logics for
sender and receiver. For instance, sender setting reserved field to 0
and receiver ignoring it is ok. But that specific HoA == CoA case w/
lft != 0 seems weird.


> So, a bit more justification would be needed before making any such
> wholesale changes.  I'm reluctant to absorb text from your draft
> without more discussion.   Do you propose any specific changes for
> this matter? 

As Marcelo pointed out, I don't think that the changes would fit in the
scope of rfc3775bis improvements because it would probably change the
expected behavior. I think adding a reference to hld-sec draft in the
security consideration section would help but I let you and the chairs
decide if it would be useful.


>>>    Home Address
>>>
>>>       The Home Address of the destination Mobile Node.
>>>
>>>    For a type 2 routing header, the Hdr Ext Len MUST be 2.  The Segments
>>>    Left value describes the number of route segments remaining; i.e.,
>>>    number of explicitly listed intermediate nodes still to be visited
>>>    before reaching the final destination.  Segments Left MUST be 1.  The
>>>    ordering rules for extension headers in an IPv6 packet are described
>>>    in Section 4.1 of RFC 2460 [8].  The type 2 routing header defined
>>>    for Mobile IPv6 follows the same ordering as other routing headers.
>>>    If both a type 0 and a type 2 routing header are present, the type 2
>>>    routing header should follow the other routing header.  A packet
>>>    containing such nested encapsulation should be created as if the
>>>    inner (type 2) routing header was constructed first and then treated
>>>    as an original packet by the outer (type 0) routing header
>>>    construction process.
>>>     
>>
>> Considering deprecation of RH0 by RFC 5095, it may be worth modifying
>> this paragraph to reflect that, for instance by stating that except
>> otherwise specified, the RH2 should be the last one in the set of RH
>> (i.e. removing the reference to the specific 'Type 0').
>>   
>
> O.K.  How about:
>
>                                       The type 2 routing header defined
>   for Mobile IPv6 follows the same ordering as other routing headers.
>   If another routing header is present along with a type 2 routing header,
>   the type 2 routing header should follow the other routing header.  A packet
>   containing such nested encapsulation should be created as if the
>   inner (type 2) routing header was constructed first and then treated
>   as an original packet by header construction process for the other
>   routing header.

Seems clear (as far as explaining routing header logic can be ;-) ).


>>>                              ......                         when
>>>    sending unsolicited multicast Router Advertisements more frequently
>>>    than the limit specified in RFC 4861 [20], the sending router need
>>>     
>>
>> s/RFC 4861 [20]/Neighbor Discovery [20]/
>>
>> IMHO, this is easier to read. Note that there are various places in the
>> document where the replacement should be done.
>>   
>
> I'd be happier if you could point them out.

No problem:

Section 6.7 Page 62, first paragrah:

   The Mobile Prefix Solicitation messages may have options.  These
   options MUST use the option format defined in RFC 4861 [20].

Section 6.8 Page 64, first paragraph:

   The Mobile Prefix Advertisement messages may have options.  These
   options MUST use the option format defined in RFC 4861 [20].

Section 6.8 Page 64, second paragraph of Prefix Information descr:

      The Prefix Information option is defined in Section 4.6.2 of RFC
      4861 [20], with modifications defined in Section 7.2 of this

Section 7.2 Page 67, middle of first paragraph:

   than the limit specified in RFC 4861 [20], the sending router need
   not include all options in each of these Advertisements.  However, in

Section 7.5 Page 71, two occurences in first paragraph:

   are available MUST NOT default to them, and SHOULD default to values
   specified in RFC 4861.  Knowledge of the type of network interface

  and

   can cause considerable overhead.  Routers SHOULD adhere to the
   intervals specified in RFC 4861 [20], if this overhead is likely to

Section 7.5 Page 71, last paragraph:

   Note that according to RFC 4861 [20], AdvDefaultLifetime is by
   default based on the value of MaxRtrAdvInterval.  AdvDefaultLifetime

Section 10.6.1 Page 106, two occurences in last paragraph of that sect.: 

   itself and other home agents on the home link.  In RFC 4861 [20] it
   is acceptable for two routers to advertise different sets of prefixes

  and

   All other comparisons of Router Advertisements are as specified in
   Section 6.2.7 of RFC 4861.

Section 11.5.1 Page 126, first paragraph:

   to discover routers and prefixes on the new link, as described in
   Section 6.3.7 of RFC 4861 [20].

Section 13 Page 145, third paragraph:

   The value MinDelayBetweenRAs overrides the value of the protocol
   constant MIN_DELAY_BETWEEN_RAS, as specified in RFC 4861 [20].  This


>>> 8.4.  IPv6 Home Agents
>>>
>>>    In order for a mobile node to operate correctly while away from home,
>>>    at least one IPv6 router on the mobile node's home link must function
>>>    as a home agent for the mobile node.  The following additional
>>>    requirements apply to all IPv6 routers that serve as a home agent:
>>>
>>>    o  Every home agent MUST be able to maintain an entry in its Binding
>>>       Cache for each mobile node for which it is serving as the home
>>>       agent (Section 10.1 and Section 10.3.1).
>>>
>>>    o  Every home agent MUST be able to intercept packets (using proxy
>>>       Neighbor Discovery [20]) addressed to a mobile node for which it
>>>     
>>
>> No opinion on whether this is a good idea or not, but probably worth
>> asking: what about also adding a reference to RFC 4389 (experimental
>> doc)?
>>   
>
> What is the advantage of making the citation?

It complements the content of Section 7.2.8 of RFC 4861 with additional
information on ND Proxy. At least, it does not cost much to add a
reference to that experimental document so that people are aware that
Proxy-ND does not work out of the box with all kinds of links.


>>>    o  The node MAY support stateful address autoconfiguration mechanisms
>>>       such as DHCPv6 [32] on the interface represented by the tunnel to
>>>       the home agent.
>>>     
>>
>> How is that supposed to happen/work? Is that to support provisioning of
>> *additional* addresses (not HoA) from the Home Network? It is unclear.
>>   
>
> What if (a) the mobile node gets an address from DHCP and then
> (b) runs IKE with its home agent?

Sorry, I do not understand what you mean. Can you describe more
precisely the steps? The tunnel does not even exist prior to the binding
(which require the HoA) so I don't see how this can work.

>  How should the statement be made clearer? 

Well, I don't even see how this can work so at the moment, I would
remove that item.


>>> 9.  Correspondent Node Operation
>>>
>>> 9.1.  Conceptual Data Structures
>>>
>>>    ...
>>>    o  A lifetime value, indicating the remaining lifetime for this
>>>       Binding Cache entry.  The lifetime value is initialized from the
>>>       Lifetime field in the Binding Update that created or last modified
>>>       this Binding Cache entry.
>>>     
>>
>> Lifetime may be the one sent in the BA in fact or am i missing sth?
>>   
>
> I reckon so.  I could add a sentence:
>
>   o  A lifetime value, indicating the remaining lifetime for this
>      Binding Cache entry.  The lifetime value is initialized from the
>      Lifetime field in the Binding Update that created or last modified
>      this Binding Cache entry.  The correspondent node MAY select a
>      smaller lifetime for the Binding Cache entry, and supply that value
>      to the mobile node in the Binding Acknowledgment message.

good.


>>> 9.5.1.  Receiving Binding Updates
>>>
>>>    Before accepting a Binding Update, the receiving node MUST validate
>>>    the Binding Update according to the following tests:
>>>
>>>    ...    When the Home Registration (H) bit is not set, the
>>> following are also
>>>    required:
>>>
>>>    ....
>>>
>>>    If the Home Registration (H) bit is set, the Nonce Indices mobility
>>>    option MUST NOT be present.
>>>     
>>
>> The binding auth data must not be present either in that case.
>>   
> ...?  I don't think that is true.

H bit set => receiver of the BU is the MN's HA (See section
6.1.7). Binding Auth Data with the HA does not make sense because BU is
IPsec protected.

The misleading thing with that section is that it is for correspondent
node behavior but is also used to describe the steps performed by the
HA. So, IMHO:

       If the Home Registration (H) bit is set, the Nonce Indices and
       Binding Auth Data mobility options MUST NOT be present.


>>>    o  If the Lifetime specified in the Binding Update is zero, then this
>>>       is a request to delete the cached binding for the home address.
>>>       If the Home Registration (H) bit is set in the Binding Update, the
>>>       Binding Update is processed according to the procedure specified
>>>       in Section 10.3.1; otherwise, it is processed according to the
>>>       procedure specified in Section 9.5.2.
>>>     
>>
>>
>> That item deals with *deletion* but points to sections associated with
>> requests to cache a binding (10.3.1 and 9.5.2). The first sentence
>> should be "If the Lifetime specified in the Binding Update is *not*
>> zero, then this is a request to *cache a binding* for the home
>> address". Otherwise, it does not make sense and is duplicate w/ next
>> item   
>
> Good catch!  I reckon you are correct.  I wonder how that bug
> stayed in the specification for so long!

;-)


>>> 10.3.1.  Primary Care-of Address Registration
>>>
>>>    When a node receives a Binding Update, it MUST validate it and
>>>    determine the type of Binding Update according to the steps described
>>>    in Section 9.5.1.  Furthermore, it MUST authenticate the Binding
>>>    Update as described in Section 5.1.  An authorization step specific
>>>    for the home agent is also needed to ensure that only the right node
>>>    can control a particular home address.  This is provided through the
>>>    home address unequivocally identifying the security association that
>>>    must be used.
>>>
>>>    This section describes the processing of a valid and authorized
>>>    Binding Update when it requests the registration of the mobile node's
>>>    primary care-of address.
>>>
>>>    To begin processing the Binding Update, the home agent MUST perform
>>>    the following sequence of tests:
>>>
>>>    o  If the node implements only correspondent node functionality, or
>>>       has not been configured to act as a home agent, then the node MUST
>>>       reject the Binding Update.  The node MUST also return a Binding
>>>       Acknowledgement to the mobile node, in which the Status field is
>>>       set to 131 (home registration not supported).
>>>
>>>    o  Else, if the home address for the binding (the Home Address field
>>>       in the packet's Home Address option) is not an on-link IPv6
>>>       address with respect to the home agent's current Prefix List, then
>>>       the home agent MUST reject the Binding Update and SHOULD return a
>>>       Binding Acknowledgement to the mobile node, in which the Status
>>>       field is set to 132 (not home subnet).
>>>
>>>    o  Else, if the home agent chooses to reject the Binding Update for
>>>       any other reason (e.g., insufficient resources to serve another
>>>       mobile node as a home agent), then the home agent SHOULD return a
>>>       Binding Acknowledgement to the mobile node, in which the Status
>>>       field is set to an appropriate value to indicate the reason for
>>>       the rejection.
>>>
>>>    o  A Home Address destination option MUST be present in the message.
>>>       It MUST be validated as described in Section 9.3.1 with the
>>>       following additional rule.
>>>     
>>
>> When coming back home, the Home Address destination option may be
>> omitted in fact.
>>   
>
> But this is a section dealing with registering a care-of-address, not
> deregistering it.

Yes, but second paragraph of the next section (10.3.2, "Primary Care-of
Address De-Registration") starts with the following:

        "A Binding Update is validated and authorized in the manner
        described in the previous section; note that when the mobile
        node de-registers when it is at home, it MAY choose to omit the
        Home Address destination option, in which case the mobile node's
        home address is the source IP address of the de-registration
        Binding Update." 

So the content of section 10.3.1 also applies to dereg BU. But in the
end, rereading that paragraph, this seems clear so drop my comment.


>>>    attempt to intercept packets on the mobile node's home link that are
>>>    addressed to the mobile node.
>>>
>>>    In order to do this, when a node begins serving as the home agent it
>>>    MUST multicast onto the home link a Neighbor Advertisement message
>>>    [20] on behalf of the mobile node.
>>>     
>>
>> As specified in section 10.3.1:
>>
>>    Unless this home agent already has a binding for the given home
>>    address, the home agent MUST perform Duplicate Address Detection [21]
>>    on the mobile node's home link before returning the Binding
>>    Acknowledgement.
>>
>> So, the last sentence should be modified to indicate that the NA is sent
>> only after that initial DAD.
>>   
>
> One could argue that the node doesn't begin serving as a home agent
> until after DAD is finished.  But, if you would like to propose some
> better text, I am open to suggestion.

What about?:

  In order to do this, when a node begins serving as the home agent it
  MUST multicast onto the home link a Neighbor Advertisement message
  [20] on behalf of the mobile node. This can only be done after having
  verified using DAD that the home address is not already in use on the
  Home Network (as specified in Section 10.3.1).


>>>    While a node is serving as a home agent for some mobile node, the
>>>    home agent uses IPv6 Neighbor Discovery [20] to intercept unicast
>>>    packets on the home link addressed to the mobile node.  In order to
>>>    intercept packets in this way, the home agent MUST act as a proxy for
>>>    this mobile node and reply to any received Neighbor Solicitations for
>>>    it.  When a home agent receives a Neighbor Solicitation, it MUST
>>>    check if the Target Address specified in the message matches the
>>>    address of any mobile node for which it has a Binding Cache entry
>>>    marked as a home registration.
>>>     
>>
>> Need for a link to 4389 here too?
>>   
>
> I still didn't exactly see why...

For the reader to be aware it exists. But this is not critical.


>>> 10.4.2.  Processing Intercepted Packets
>>>
>>>    For any packet sent to a mobile node from the mobile node's home
>>>    agent (in which the home agent is the original sender of the packet),
>>>    the home agent is operating as a correspondent node of the mobile
>>>    node for this packet and the procedures described in Section 9.3.2
>>>    apply.  The home agent then uses a routing header to route the packet
>>>    to the mobile node by way of the primary care-of address in the home
>>>    agent's Binding Cache.
>>>
>>>    While the mobile node is away from home, the home agent intercepts
>>>    any packets on the home link addressed to the mobile node's home
>>>    address, as described in Section 10.4.1.  In order to forward each
>>>    intercepted packet to the mobile node, the home agent MUST tunnel the
>>>    packet to the mobile node using IPv6 encapsulation [9].  When a home
>>>    agent encapsulates an intercepted packet for forwarding to the mobile
>>>    node, the home agent sets the Source Address in the new tunnel IP
>>>    header to the home agent's own IP address and sets the Destination
>>>    Address in the tunnel IP header to the mobile node's primary care-of
>>>    address.  When received by the mobile node, normal processing of the
>>>    tunnel header [9] will result in decapsulation and processing of the
>>>    original packet by the mobile node.
>>>
>>>    However, packets addressed to the mobile node's link-local address
>>>    MUST NOT be tunneled to the mobile node.  Instead, these packets MUST
>>>    be discarded and the home agent SHOULD return an ICMP Destination
>>>    Unreachable, Code 3, message to the packet's Source Address (unless
>>>    this Source Address is a multicast address).
>>>     
>>
>> I am certainly missing something here, but what is the point for the HA
>> in defending the IP then?
>>   
>
> So that no other node will steal the mobile node's link-local address.
> The mobile node would like to have it back when it returns to the home
> network.

Thanks for the clarification.


>>>    where MaxMobPfxAdvInterval is as defined in Section 12.  Then compute
>>>    the final delay for the advertisement:
>>>
>>>
>>>      RAND_ADV_DELAY = MinMobPfxAdvInterval +
>>>            (rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval))
>>>
>>>    Here rand() returns a random integer value in the range of 0 to the
>>>    maximum possible integer value.  This computation is expected to
>>>    alleviate bursts of advertisements when prefix information changes.
>>>    In addition, a home agent MAY further reduce the rate of packet
>>>    transmission by further delaying individual advertisements, when
>>>    necessary to avoid overwhelming local network resources.  The home
>>>    agent SHOULD periodically continue to retransmit an unsolicited
>>>    Advertisement to the mobile node, until it is acknowledged by the
>>>    receipt of a Mobile Prefix Solicitation from the mobile node.
>>>     
>>
>> seems weird.
>>   
>
> As I remember, this was considered very cool at the time.
> I don't remember why, but unless there is a need for change
> I'd rather not go back and figure it out.

ok. Let's keep it that way.


>>> 11.  Mobile Node Operation
>>>
>>> 11.1.  Conceptual Data Structures
>>>
>>>  
>>>
>>>    o  The remaining lifetime of that binding.  This lifetime is
>>>       initialized from the Lifetime value sent in the Binding Update and
>>>       is decremented until it reaches zero, at which time this entry
>>>       MUST be deleted from the Binding Update List.
>>>     
>>
>> Updated by the BA.
>>
>>   
> But, I think the BA can only decrease the lifetime, right?  So it would
> still be a further decrementation.

yes, exactly.


>>> 11.3.2.  Interaction with Outbound IPsec Processing
>>>
>>> ...
>>>
>>>    The Key Management Mobility Capability (K) bit in Binding Updates and
>>>    Acknowledgements can be used to avoid the need to rerun IKE upon
>>>    movements.
>>>     
>>
>> Considering the mechanism is implemented and such an interface needed to
>> support that, 3775bis could at least point MIGRATE doc given below as an
>> informational reference document. This clarifies the need and gives a
>> possible solution.
>>
>>  http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00
>>   
>
> Can we do this safely without having the citation to be
> considered normative?

What about changing the K bit description in 6.1.7 from


   Key Management Mobility Capability (K)

      If this bit is cleared, the protocol used for establishing the
      IPsec security associations between the mobile node and the home
      agent does not survive movements.  It may then have to be rerun.
      (Note that the IPsec security associations themselves are expected
      to survive movements.)  If manual IPsec configuration is used, the
      bit MUST be cleared.


to that:


   Key Management Mobility Capability (K)

      If this bit is cleared, the protocol used for establishing the
      IPsec security associations between the mobile node and the home
      agent does not survive movements.  It may then have to be
      rerun. If manual IPsec configuration is used, the bit MUST be
      cleared. 

      Note that the transport mode IPsec security associations
      themselves are expected to survive movements. A possible solution
      regarding the update of IKE SA (Phase 1 for IKEv1, IKE_SA for
      IKEv2) update and optional tunnel mode IPsec SP/SA update is
      described in [MIGRATE].


>>> 11.4.3.  Receiving Mobile Prefix Advertisements
>>>
>>>    Section 10.6 describes the operation of a home agent to support boot
>>>    time configuration and renumbering a mobile node's home subnet while
>>>    the mobile node is away from home.  The home agent sends Mobile
>>>    Prefix Advertisements to the mobile node while away from home, giving
>>>    "important" Prefix Information options that describe changes in the
>>>    prefixes in use on the mobile node's home link.
>>>
>>>    The Mobile Prefix Solicitation is similar to the Router Solicitation
>>>    used in Neighbor Discovery [20], except it is routed from the mobile
>>>    node on the visited network to the home agent on the home network by
>>>    usual unicast routing rules.
>>>
>>>    When a mobile node receives a Mobile Prefix Advertisement, it MUST
>>>    validate it according to the following test:
>>>
>>>    o  The Source Address of the IP packet carrying the Mobile Prefix
>>>       Advertisement is the same as the home agent address to which the
>>>       mobile node last sent an accepted home registration Binding Update
>>>       to register its primary care-of address.  Otherwise, if no such
>>>       registrations have been made, it SHOULD be the mobile node's
>>>       stored home agent address, if one exists.  Otherwise, if the
>>>       mobile node has not yet discovered its home agent's address, it
>>>       MUST NOT accept Mobile Prefix Advertisements.
>>>
>>>    o  The packet MUST have a type 2 routing header and SHOULD be
>>>       protected by an IPsec header as described in Section 5.4 and
>>>       Section 6.8.
>>>
>>>    o  If the ICMP Identifier value matches the ICMP Identifier value of
>>>       the most recently sent Mobile Prefix Solicitation and no other
>>>       advertisement has yet been received for this value, then the
>>>       advertisement is considered to be solicited and will be processed
>>>       further.
>>>
>>>       Otherwise, the advertisement is unsolicited, and MUST be
>>>       discarded.  In this case the mobile node SHOULD send a Mobile
>>>       Prefix Solicitation.
>>>     
>>
>> I tried and raise a clarification on that point:
>>
>> See   http://permalink.gmane.org/gmane.ietf.mip6/9433
>>
>> but got no response. IMHO, clarifying things a bit would help.
>>   
>
> How about:
>
>      Otherwise, the advertisement is unsolicited, and MUST be
>      discarded.  In this case the mobile node SHOULD send a Mobile
>      Prefix Solicitation, using the same ICMPv6 identifier that was
>      used for the previous Solicitation.

ok.


>>> 11.5.2.  Home Link Detection
>>>
>>>    When an MN detects that it has arrived on a new link using the
>>>    movement detection algorithm in use (Section Section 11.5.1,) it
>>>    performs the following steps to determine if it is on the home link.
>>>
>>>    o  The MN performs the procedure described in Section 11.5.2x and
>>>     
>>
>>                                                     s/11.5.2x/11.5.2/
>>
>> Then, it seems that 11.5.2 is current section. Weird.
>>
>>   
>
> I reckon this ought to be 11.5.3.
>
>>>       configures an address.  It also keeps track of all the on-link
>>>       prefix(es) received in the RA along with their prefix lengths.
>>>
>>>    o  If the home prefix has not been statically configured the MN uses
>>>       some form of bootstrapping procedure (e.g.  RFC5026 [25]) to
>>>       determine the home prefix.
>>>
>>>    o  Given the availability of the home prefix, the MN checks whether
>>>       or not the home prefix matches one of the prefixes received in the
>>>       RA.  If it does, the MN concludes that it has returned home.
>>>     
>>
>> It should be stated here or in the "Security Considerations" section
>> that this procedure is insecure and may have security impact, as we rely
>> on basic ND and undergo associated threats. This is documented:
>>
>> http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00
>>   
>
> I could put some advice in the Security Considerations section and a
> cross reference here.  If you happen to have a short paragraph of text that
> you wanted to contribute for that purpose, it would be appreciated.

Is that ok?:

  The Home Link Detection mechanism described in section 11.5.2 and used
  by the MN to detect it is at home relies on Neighbor Discovery
  [20]. When IPsec is used by the MN for protecting data traffic
  exchanged with the Home Agent from foreign networks, relying on this
  mechanism may have security implications. This is discussed in [hld-sec].


>>>    the previously registered care-of address.
>>>
>>>    In this home registration, the mobile node MUST set the Acknowledge
>>>    (A) and Home Registration (H) bits, set the Lifetime field to zero,
>>>    and set the care-of address for the binding to the mobile node's own
>>>    home address.  The mobile node MUST use its home address as the
>>>    source address in the Binding Update.
>>>     
>>
>> Processing for receiver allows either lft=0 or CoA == HoA; so what's the
>> point in that MUST.
>>   
>
> Well, it's been there for a long time, and I don't know if it
> would be worthwhile to change.  It might break various
> interoperability tests, for one thing.

Well, if a HA receives a dereg BU with the lft not set to 0, then it is
from a non compliant implementation. And if the HA does not accept such
a BU sent by a non-compliant implementation, it would fail an
interoperability test.

Also note that for the MN to send a BU with the HoA as source address in
the IPv6 header (i.e. no HAO), this requires the MN to have detected it
is on its Home Network. In that case, it would purposely not set the
lifetime to 0 do deregister?

But I agree that this is some kind of historical weirdness we need to
keep.

>>> 15.  Security Considerations
>>>     
>>
>> Considering this is documented:
>>
>> http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00
>>
>> the possible specific insecurity of the Home Link Detection mechanism
>> could be referenced in that section.
>>
>>   
>>
>>
>>   
>>> 15.7.  Tunneling via the Home Agent
>>>
>>>
>>>    When site local home addresses are used, reverse tunneling can be
>>>    used to send site local traffic from another location.
>>>    Administrators should be aware of this when allowing such home
>>>    addresses.  In particular, the outer IP address check described above
>>>    is not sufficient against all attackers.  The use of encrypted
>>>    tunnels is particularly useful for these kinds of home addresses.
>>>     
>>
>> In previous paragraph, reference to site local (deprecated) should be
>> replaced by a reference to Unique Local Addresses (RFC4193).
>>   
>
> O.K.
>
>>   
>>> 16.  Contributors
>>>
>>>    Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark,
>>>    and Michael Thomas worked on the return routability protocols
>>>    eventually led to the procedures used in this protocol.
>>>     
>>
>> In previous sentence, s/worked/work/ 
>>
>>
>>   
>
> I think some other people were involved -- and this was a very
> contentious time in the working group.

Sorry, I may have been unclear. The first sentence has 2 verbs: 'worked'
and 'led' but only one subject.

I think there is either a missing 'which' or 'worked' need to be changed
in 'work' i.e. one of the following would be valid:

    Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark,
    and Michael Thomas worked on the return routability protocols which
    eventually led to the procedures used in this protocol.

or 

    Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark,
    and Michael Thomas work on the return routability protocols
    eventually led to the procedures used in this protocol. 

>   Work done by Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander,
>   Erik Nordmark, and Michael Thomas on the return routability protocols
>   shaped the procedures used in this protocol.

that would be ok too.

Cheers,

a+