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
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
