Subject: [Hipsec] (corrected) preview of draft-ietf-hip-mm-00 for review

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 6 Oct 2004 10:23:19 -0700

> -----Original Message-----
> From: Henderson, Thomas R 
> Sent: Monday, October 04, 2004 9:56 PM
> To: [email-masked]
> Subject: [Hipsec] preview of draft-ietf-hip-mm-00 for review
> 
> 
> I plan to submit this draft as WG version -00 in a few days,
> but have put it up for any early comments:
> 
> http://hip4inter.net/documentation/drafts/draft-nikander-hip-mm-02.txt
> 

I made a mistake and provided Petri with only a partially updated
draft.  He has now posted the draft I originally intended to preview
post (open issues list is the same):

http://hip4inter.net/documentation/drafts/draft-ietf-hip-mm-00.txt

Below are the diffs from what was originally posted-- I haven't
yet processed the comments that have been coming on the list.

Key to this diff file:

< Previously posted, modified draft-nikanker-hip-mm-02
> Updated version at new URL above (draft-ietf-hip-mm-00)

12c12
<                         draft-nikander-hip-mm-02
---
>                           draft-ietf-hip-mm-00
350,352c350,352
<    In the HIP base protocol specification [3], it is defined how two
<    hosts exchange their Host Identifiers and establish a pair of ESP
<    Security Associations (SA).  
---
>    The HIP base protocol specification [3] defines how two hosts
>    exchange their Host Identifiers and establish a pair of ESP Security
>    Associations (SA).  
528a529,531
>    It is not specified how a host knows whether or not middleboxes might
>    lie on its path, so a conservative assumption may be to always
>    include the SPI parameter.
544a547,553
>    In general, when multiple addresses are used for a session, there is
>    the question of using multiple addresses for failover only or for
>    load-balancing.  Due to the implications of load-balancing on the
>    transport layer that still need to be worked out, this draft assumes
>    that multiple addresses are used primarily for failover.  An
>    implementation may use ICMP interactions, reachability checks, or
>    other means to detect the failure of an address.
639c639
<    about changes of IP addresses on one of its SPIs.  The readdressing
---
>    about changes of IP addresses on affected SPIs.  The readdressing
744a745,748
>    Hosts that use link-local addresses as source addresses in their HIP
>    handshakes may not be reachable by a mobile peer host unless a
>    globally routable address is provided either in the initial handshake
>    or via the REA parameter.
791c795
<    implicitly affiliated with different addresses.
---
>    implicitly affiliated with different source addresses.
803a808,813
>    When rekeying in a multihoming situation in which there is an
>    asymmetric number of SAs between two hosts, a respondent to the NES/
>    UPDATE procedure may have some ambiguity as to which inbound SA it
>    should update in response to the peer's UPDATE.  In such a case, the
>    host SHOULD choose an SA corresponding to the inbound interface on
>    which the UPDATE was received.
881,890d890
< 5.7  Initiating the protocol in R1 or I2
< 
<    A Responder host MAY include one or more REA parameters in the R1
<    packet that it sends to the Initiator.  These parameters MUST be
<    protected by the R1 signature.  If the R1 packet contains REA
<    parameters, the Initiator SHOULD send the I2 packet to the new
<    preferred address.  The Responder MUST make sure that the puzzle
<    solution is valid BOTH for the initial IP destination address used
<    for I1 and for the new preferred address.  The I1 destination address
<    and the new preferred address may be identical.
899a900,908
> 5.7  Initiating the protocol in R1 or I2
> 
>    A Responder host MAY include one or more REA parameters in the R1
>    packet that it sends to the Initiator.  These parameters MUST be
>    protected by the R1 signature.  If the R1 packet contains REA
>    parameters, the Initiator SHOULD send the I2 packet to the new
>    preferred address.  The I1 destination address and the new preferred
>    address may be identical.
> 
1040c1096,1098
<    each of them must be matched with a NES parameter:
---
>    and at least one of the REA parameters is matched with a NES
>    parameter, then each REA must be matched with a NES parameter, to
>    avoid ambiguity:
1112c1168
<    a REA with the SPI field within the REA set to the new address, and
---
>    a REA with the SPI field within the REA set to the new SPI, and also
1181a1238,1239
>    5.  Mark all addresses at the address group that were NOT listed in
>        the REA parameter as DEPRECATED.
1252c1324
<        ICMP erro messages arrive that deprecate the preferred address,
---
>        ICMP error messages arrive that deprecate the preferred address,
1377c1433
<    return routability check provides some assurance that the given
---
>    address reachability check provides some assurance that the given
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Mika Kousa <[email-masked]>
Date: Thu, 7 Oct 2004 15:15:08 +0300 (EEST)

5.7 Initiating the protocol in R1 or I2:

Should there be some explicit notes about the KEYMAT index to be used when 
retrieving keying materials for the SA(s) if the R1 or I2 contains 
(multiple) REA(s) ? Or do we just assume that the implementors know what 
they are doing without telling them. That is, they use the current KEYMAT 
index right after when the HIP keys were drawn.
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec