Re: [Hipsec] Mirja Kühlewind's No Objection on draft-ietf-hip-rfc5206-bis-13: (with COMMENT)

[Mirja Kühlewind <[e-mail]>]

Hi Tom,

please see inline.

On 15.09.2016 06:48, Tom Henderson wrote:
> On 09/12/2016 07:28 AM, Mirja Kuehlewind wrote:
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-hip-rfc5206-bis-13: No Objection
>
> Mirja, thank you for the review; responses inline below.
>
> - Tom
>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Some concrete comments:
>> 1) Can you further explain the scenario assumed in these sentences! What
>> is the middblebox supposed/expected to do?
>> "In this case, the OLD SPI and NEW SPI parameters
>>        both are set to the value of the preexisting incoming SPI; this
>>        ESP_INFO does not trigger a rekeying event but is instead
>>        included for possible parameter-inspecting middleboxes on the
>>        path. "
>> and
>> "An additional potential benefit of performing address verification is
>>    to allow middleboxes in the network along the new path to obtain the
>>    peer host's inbound SPI."
>
> These scenarios are explained further in an informational RFC from a few years back (5207).
>
> https://tools.ietf.org/html/rfc5207
>
> In brief, firewalls may wish to authenticate the HIP message exchanges and then limit access to the SPIs involved in the association.
>
> How about adding an informational reference to RFC 5207 when we raise such issues in this document?
Yes, please. Maybe a sentence or two what the main points of rfc5207 are 
would be good as well. I would even recommend to not talk about "middleboxes" 
in general but "NAT and firewall traversal" as rfc5207 does.

>
>>
>> 2) Section 3.2.1. step 2: I guess the peer would also need to retransmit
>> the UPDATE+ECHO_REQUEST if it doesn't get a reply in time? (Didn't check
>> RFC7401...)
>
> Yes, in RFC 7401, the UPDATE messages are protected by a retransmission timer:
> https://tools.ietf.org/html/rfc7401#section-6.11

I would also recommend to spell this out (because it's done for the previous 
step)

>
>>
>> 3) section 4: Can you give any hints how large the lifetime typically
>> should be? Can only the original address have an unbounded lifetime (see
>> section 5) or can I also set the lifetime value in a certain way to
>> declare the lifetime of this address of unbounded?
>
> Effectively unbounded lifetimes can be set by setting the 32-bit field to the maximum value.

Okay that's not spelled out in the doc.

>  In practice, I don't know of any guidance to offer, other than perhaps aligning it with lifetimes of the addresses such as DHCP leased addresses.

That means like useful guidance.
>
> I guess that we could add a statement that an 'effectively unbounded' lifetime can be set by setting the field to the maximum (unsigned) value.

Would you then also need to talk about risks when doing so...?
>
>>
>> 4) section 4/5: maybe state more clearly that a 'new' LOCATOR_SET
>> replaces the old one and therefore if a hosts sens a LOCATOR_SET is MUST
>> include all active addresses. I believe that's what you are doing from
>> the description in section 5 but it's never really spelled out...
>
> Yes, I agree it could be stated more clearly.  Perhaps early in Section 5.2, on sending LOCATOR_SET parameters, we could add a sentence such as "The sending of a new LOCATOR_SET parameter replaces the locator information from any previously sent LOCATOR_SET parameter, and therefore if a host sends a new LOCATOR_SET parameter, it MUST continue to include all active locators."  Later in the text regarding processing of the received LOCATOR_SET parameter, it clearly states to deprecate locators that are no longer present.

Yes, thanks.
>
>>
>> 5) section 5.4: How long will an address be in UNVERIFIED state in case
>> the verification is not successful (no reply). Is there a timer? How
>> often will the peer retry the verification test? How long does the peer
>> wait until resending the verification packet?
>
> This point is somewhat implied, but the verification is expected to be conducted using HIP UPDATE packet exchanges, which are protected by timers and a maximum retry count (RFC7401).  Perhaps this can be stated more clearly such as
> "A typical verification that is protected by retransmission timers is to include an ECHO REQUEST within an UPDATE sent to the new address."

Yes, please.

>
>>
>> 6) section 5.6: The proposed  Credit-Based Authorization  seems quite
>> complicated for me. First please state clearly the goal: I guess the
>> scenario is that that you send data to the host and the host switches to
>> new address. To be able to keep sending data with the same rate during
>> the "switch-over 3-way-handshake" you need this credit system. So, what
>> you actually need is to estimate the current sending rate in packets per
>> RTT and take this number of packets as your credit. If you know the RTT
>> you can simply count the packets. You can probably always estimate the
>> RTT during the initial HIP 'handshake'/UPDATE exchange. If you don't have
>> a way to update this RTT estimate during the connection, you might just
>> use 2xRTT or 3xRTT to be safe...
>
> I just reviewed the text again.  Yes, the goal is as you stated, to provide for data transfer during this transient handshake period while minimizing the potential for abuse.
>
> The text doesn't offer any specific guidance on how to set the credit limit, but we could consider to add a heuristic such as you sketched out above.

For me that would make sense! Also state the goal make clear, so people know 
what to optimize for if they implement their own heuristic.
>
>>
>> And more general comments:
>> 1) Did you see any deployment problems because you don't expose a port
>> number (at a know location above the IP header) with e.g. NATs?
>
> Well, to traverse legacy NATs requires UDP encapsulation (e.g. RFC 5770); I am not sure there is much experience with any NAT that is HIP aware or permissive in this regard.

I think a reference to rfc5207/rfc5770 would be good.

>
>>
>> 2) Usually documents that obsolete another rfc have a "changes from
>> RFCXXXX" section. Not sure if this is needed in this case when you move
>> from experimental to proposed stanadard but given the rather larger
>> number of changes, I would find it helpful.
>
> Someone else also recently suggested this section; I will add one to the next version.

Thx. It seems even required ;-)
>
>>
>> 3) I believe reading would be easier for me if section 4 would have been
>> first but not sure...
>
> I'm not sure about reordering sections without more specific change proposals.

Or you could add a paragraph in the intro explaining where to find what.

>
>>
>> 4) This docuemnt states several times that mutlihoming is out of scope
>> and only the handover case is described. I think it would be better to
>> state this clearly at the very beginning and remove the other cases (I
>> believe these are anyway kind of left-overs from the previous document.)
>
> Can you point to what you would like to have removed or changed?  Early on, we moved most of this material to the other draft, and in scanning it again just now, I am not sure what more to take out or rephrase.  It is hard to completely avoid the topic of having multiple addresses in this draft, particularly since we are defining the LOCATOR_SET parameter that is used in the multihoming specification.
>
Maybe just grab from the word multihoming and double-check if you really need 
it there. For me it somtimes showed up at place there I thought it's actually 
not needed to mentioned that again.
But that's nothing big...

Mirja