RE: [Hipsec] some comments for mm-03

["Henderson, Thomas R" <[e-mail]>]

Miika, resuming the response to your detailed coments:

> -----Original Message-----
> From: Miika Komu [mailto:[e-mail]] 
> Sent: Monday, April 03, 2006 2:30 PM
> To: [e-mail]
> Subject: Re: [Hipsec] some comments for mm-03
> 
> > Some comments for mm-03, part 1/2 (I'll send the rest later this
> > evening).
> 
> Here we go again.. decided to split the email on separate 
> sections. Here
> is (the end of section three and) section 4.
> 
> > 3.3.4.  Interaction with Security Associations
> >
> > This document specifies a new HIP protocol parameter, the LOCATOR
> > parameter (see Section 4), that allows the hosts to 
> exchange information
> > about their locator(s), and any changes in their locator(s).
> 
> This document specifies a new HIP protocol parameter, the LOCATOR
> parameter (see Section 4), that allows the hosts to exchange
> information about changes their locator(s).

disagree with this editorial suggestion, since it is not only changes
that
can be conveyed in LOCATOR.

> 
> > The relation between these entities for an association negotiated as
> > defined in the base specification [2] and ESP transform [5] is
> > illustrated in Figure 11.
> 
> What entities? There is also something other fishy with this sentence.
> 
s/entities/levels
s/negotiated/constructed

> > The addresses addr1a and addr2a are the source addresses 
> that each host
> > uses in the base HIP exchange.
> 
> The addresses addr1a and addr2a are the source addresses that 
> the hosts
> use in the base HIP exchange.

OK

> 
> > These are the "preferred" (and only) addresses conveyed to 
> the peer for
> > each SA; even though packets sent to any of the hosts' 
> interfaces can
> > arrive on an inbound SPI, when a host sends packets to the 
> peer on an
> > outbound SPI, it knows of a single destination address 
> associated with
> > that outbound SPI (for host1, it sends a packet on SPI2a to 
> addr2a to
> > reach host2), unless other mechanisms exist to learn of new 
> addresses.
> 
> * Perhaps you just replace the SA with SPI because SA is not really
>   illustrated in the figure.
> * This is an overly long sentence, suggest splitting into 2-3 
> sentences.
> * I think that "arrive on SPI", "send to peer SPI" and
>   "send packet on SPI" could be said in a better way.

performed some cleanup as you suggested

> 
> > In this figure, a host can have multiple inbound SPIs (and, 
> not shown,
> > multiple outbound SPIs) between itself and another host.
> 
> s/between/associated with/
> 
s/between itself and/associated with/

> > These addresses bound to an SPI are not used as SA selectors.
> 
> (I suggested writing the term "SA selector" to the terminology in the
> beginning)

acutally, on a message from Wed. Mar 22, 2006 to the list, Francis
Dupont
corrected my usage of "SA selector"-- should be "SA lookup".  Have
made the appropriate changes (do not use the term selector in the
document
anymore).

> 
> > The LOCATOR parameter allows for IP addresses and SPIs to 
> be combined to
> > form generalized locators.
> 
> I am not sure if "generalized" is the right term, but rather 
> "locators for
> suitable for IPsec use" etc. In any case, this sentence can be removed
> from here as it is repeated elsewhere.

removed

> 
> > Figure 12
> 
> This figure reminds me that is it possible to have both SPI1 and SPI2
> mapping to the same ADDR21?

Yes, in general, there may be different source addresses and hence 
different paths to the same destination address.

> 
> > The main purpose of having multiple SPIs is to group the 
> addresses into
> > collections that are likely to experience fate sharing.
> 
> The main purpose of having multiple SPIs with a peer is to group the
> addresses into collections that are likely to experience fate sharing.

OK
> 
> > For this reason, HIP provides a mechanism to affiliate destination
> > addresses with inbound SPIs, if there is a concern that anti-replay
> > windows might be violated otherwise.
> 
> s/if/when/
> s/otherwise//
> 
OK

> > Moreover, even if the destination addresses used for a 
> particular SPI
> > are held constant, the use of different source interfaces 
> may also cause
> > packets to fall outside of the ESP anti-replay window, 
> since the path
> > traversed is often affected by the source address or interface used.
> 
> s/if/when
> 

OK

> > A host has no way to influence the source interface on 
> which a peer uses
> > to send its packets on a given SPI.
> 
> A host has no way to influence the source interface on which 
> a peer sends
> its packets using a given SPI.
> 

OK

> > Hosts SHOULD consistently use the same source interface and 
> address when
> > sending to a particular destination IP address and SPI.
> 
> s/Hosts/A host/
> 
OK

> > If the LOCATOR parameter is sent in an UPDATE packet, then the
> > receiver will respond with an UPDATE acknowledgment.
> 
> When the LOCATOR parameter is sent in an UPDATE packet, then the
> receiver responds with an UPDATE acknowledgment.

OK

> 
> > If the LOCATOR parameter is sent in a NOTIFY, I2, or R2 
> packet, then the
> > recipient may consider the LOCATOR as informational, and 
> act only when
> > it needs to activate a new address.
> 
> If the LOCATOR parameter is sent in a NOTIFY, I2, or R2 packet, the
> recipient MUST consider the LOCATOR as informational, and act 
> only when it
> needs to activate a new address.
> 
> What does "act" mean here?

First, there is an error here-- R2 should be R1.  We corrected this
elsewhere in last draft version, but this is a loose end that needs 
changed.

This also allows me to comment on a suggestion in your previous mail:
>
> > > > Even if the I2 packet contains LOCATOR parameters, the Responder
> > > > MUST still send the R2 packet to the source address of the I2.
> > >
> > > I1 and I2 source address must be the same?
> >
> > What does it matter?  I1 state is not kept by responder.
> 
> Cookies might get burned if the indexing is affected by the 
> IP addresses
> :)
> 
I1 and I2 source addresses can be different, because the responder
can include a new preferred address in the R1 LOCATOR, and the 
change in responder address might require a change in initiator
source address.

Now, back to the text at hand.  NOTIFY perhaps should be separated
from the R1/I2 cases.  It may be the case that a LOCATOR in an I2
can override the preferred address used for the base exchange, so
saying that it is informational may mean that the receiver can ignore
it.  The issue is really with NOTIFY, which could be replayed.  What
may work better here is to treat NOTIFY as informational, which means
that it cannot drive any particular state change (this also just
discussed in the Bellovin-Rescorla analysis thread).

Perhaps this wording is better:

"       When the LOCATOR parameter is sent in an UPDATE packet, then the
        receiver will respond with an UPDATE acknowledgment.  When the
        LOCATOR parameter is sent in an R1 or I2 packet, the base
exchange
        retransmission mechanism will confirm its successful delivery.  
        LOCATORs may experimentally be used in NOTIFY packets; in this
case,
        the recipient MUST consider the LOCATOR as informational and not
        immediately change the current preferred address, but can test
the 
        additional locators when the need arises.  The use of LOCATOR 
        in a NOTIFY message may not be compatible with middleboxes."

> 
> > The use of LOCATOR in a NOTIFY message may not be compatible with
> > middleboxes.
> 
> > 4.  LOCATOR parameter format
> 
> Is there are specific reason why the reserved field cannot be 
> just flags?

I do not understand this request.  Aren't undefined flags the same
as reserved bits?

> 
> > Length: Length in octets, excluding Type and Length fields, and
> > excluding padding.
> 
> Minimum length (is a locator without any address allowed)? 

I would say yes, and this corresponds to moving all addresses to
DEPRECATED.

Suggest:  
       "A LOCATOR contaning zero Locator fields
       is permitted but has the effect of DEPRECATING all addresses."

> Maximum length?

There is already a maximum for HIP Parameters field.

> 
> > Locator Length: Defines the length of the Locator field, in units of
> > 4-byte words (Locators up to a maximum of 4*255 bytes are 
> supported).
> 
> s/bytes/octets/

OK

> 
> > Locator: The locator whose semantics and encoding are 
> indicated by the
> > Locator Type field.  All Locator sub-fields are integral 
> multiples of
> > four bytes in length.
> 
> It is slightly confusing that there is LOCATOR and Locator :) 
> Perhaps this
> should be noted in the terminology.

Added.

> 
> s/bytes/octets/


OK

> 
> > The address is expected to become deprecated when the 
> specified number
> > of seconds has passed since the reception of the message.
> 
> Also, CLOSE can be used for premature expiration of addresses.

Ignoring this one based on previous discussion.

> 
> > A deprecated address SHOULD NOT be used as an destination 
> address if an
> > alternate (non-deprecated) is available and has sufficient scope.
> 
> In the case of many alternatives, the host chooses according to
> local host policies.

I don't think this sentence is really needed here since the issue
of picking among multiple addresses is dealt with elsewhere.

> 
> > 4.1.  Traffic Type and Preferred Locator
> >
> > The "P" bit, when set, has scope over the corresponding Traffic Type
> > that precedes it.
> 
> s/precedes it//

OK

> 
> > That is, if a "P" bit is set for Traffic Type "2", for example, that
> > means that the locator is preferred for data packets.
> 
> That is, when a "P" bit is set for Traffic Type "2", for 
> example, it means
> that the locator is preferred for data packets.

OK

> 
> > If there is a conflict (for example, if P bit is set for an 
> address of
> > Type "0" and a different address of Type "2"), the more 
> specific Traffic
> > Type rule applies.
> 
> If there is a conflict (for example, if P bit is set for an address of
> Type "0" and a different address of Type "2"), the more 
> specific Traffic
> Type rule applies (in this case it was "2").

OK

> 
> This seems to complicate the processing rules. Unless there 
> is a special
> reason for doing this, it migth be easier to forbid mixing 
> type 0 locators
> with type 1 or 2 locators.

Since we do not presently define multiple LOCATORs in a single packet, 
this would mean that we cannot handle different interfaces differently.
It may be that one interface requires the separation of signaling and
data, while another does not.  So I'd slightly prefer to keep it open.
I don't see it as seriously complicating things.

> 
> > 4.2.  Locator Type and Locator
> 
> > 0:  An IPv6 address or an IPv4-in-IPv6 format IPv4 address [7] (128
> >     bits long).
> 
> Suggest adding: Currently, mostly for non-ESP based usage.
> 

This locator type is defined primarily for non-ESP-based usage.

> > 1:  The concatenation of an ESP SPI (first 32 bits) followed by an
> >     IPv6 address or an IPv4-in-IPv6 format IPv4 address (an 
> additional
> >     128 bits).
> 
> Suggest adding: Recommend for ESP based usage.
> 
This locator type is defined primarily for ESP-based usage.

> > 4.3.  UPDATE packet with included LOCATOR
> 
> Add to this section some text about the correspondence 
> between ESP_INFO
> and Type 1 LOCATORS.

   The relationship between the
   announced Locators and any ESP_INFO parameters present in the packet
   is defined in Section 5.2.
 

_______________________________________________
Hipsec mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hipsec