RE: [Hipsec] some comments for mm-03

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

 

> -----Original Message-----
> From: Miika Komu [mailto:[e-mail]] 
> Sent: Monday, April 17, 2006 12:17 PM
> To: Henderson, Thomas R
> Cc: [e-mail]
> Subject: RE: [Hipsec] some comments for mm-03
> 
> > > > 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.
> 
> Maybe this could be also mentioned briefly in the text. It is 
> not obvious
> from figure or text.

I have looked at this and am not sure whether there is an easy way to
add this without complicating the description more than necessary-- I
would be willing to consider a specific proposal, though.

> 
> > > > > > 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.
> 
> Let me further illustrate my original point. In the Appendix A. (Using
> Responder Puzzles) of base draft, an example puzzle algorithm is
> illustrated. Even though the algorithm is only illustrative, I believe
> that any DoS resistant puzzle algo will use the I1 and I2 source IP
> address as part of the indexing scheme in practice, and this will most
> probably cause the base exchange to fail. The initiator keeps
> retransmitting I2 packets from I2_SENT state and responder 
> just drops them
> due to failed cookie solutions. I believe that this is a very 
> practical
> and real problem; I've encountered similar problems many times in our
> implementation, albeit on when implementing other things (NAT, rvs).

I see your practical point.  It seems to me that a host sending a R1
LOCATOR should not use the algorithm in Appendix A in the base draft
without some modification.  Maybe there should be a note to that effect.

> 
> > 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 wording is better, but I claim that there is still a 
> practical problem
> and important problem with cookie indexing. Perhaps we can 
> just mention
> somewhere in the text (3.2.8. Initiating the protocol in R1 or I2?)
> something like this:
> 
> I1 and I2 may be arriving from the different source addresses if the
> LOCATOR parameter is present in R1. In this case, 
> implementations using
> pre-created R1 indexed with IP addresses may be failing 
> cookie solutions
> of I2 packets inadvertly. As a solution, the responder's R1 indexing
> mechanism must be flexible enough to accomodate the situation when R1
> includes a LOCATOR parameter.

I am willing to add this-- thanks for pointing it out.

> 
> > > > 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?
> 
> Effectively yes. However, now thinking this again, the 
> difference in using
> "reserved bits" rather than "undefined flags" may be that 
> reserved bits
> could be allocated as a type field rather than single bit flags. As a
> consequence, it is more modular. So I am fine with this as it 
> is, it seems
> to be case also in the base draft.

OK, will leave it as is.

> 
> > > > 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.
> 
> Suggest adding the proposed hints for the sake of 
> ease-of-readability. If
> I recall correctly, I started to wonder the difference between the
> locator types at this point. After reading the whole draft, I 
> just added
> the sentences that would have satisfied my curiousity on the 
> first reading
> round.

I did add those hints-- in my response, I should have made it clearer by
enclosing them in quotes.

> 
> > > > 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.
> 
> This was a readability note because the text references 
> something that has
> not been discussed yet.
> 

Ditto-- I actually added the above sentence, but didn't enclose it in
quotes, so you misunderstood my comment.  (i.e., it is now in there)

Tom 

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