Apologies to the hipsec list administrator. If we have more exchanges
I'll subscribe to the list.
Tom Taylor
On 30/06/2014 7:09 PM, Tom Henderson wrote:
On 06/30/2014 10:46 AM, Tom Taylor wrote:
Comments below marked with [PTT].
Tom Taylor
On 28/06/2014 1:53 PM, Tom Henderson wrote:
Hi all, we received a number of comments during the IESG evaluation of
RFC 5201-bis. Below are the non-editorial comments. There were also
several IANA questions that I plan to handle in a separate message.
I'll plan to post an updated draft version 15 that addresses the
editorial comments received, then once we give people a chance to review
the below, publish another new version with additional revisions.
Please review the below suggested resolutions (there is one issue for
which I am not sure whether we should make any changes).
Minor issues (pointed out by Gen-ART reviewer Tom Taylor)
---------------------------------------------------------
1) Section 4.3 (Error Processing) final case: if the receiving host does
not send some sort of response (e.g., ICMP) to the sender, the sender
may have no way of knowing that the HIP session has failed. The state
transitions from ESTABLISHED in Table 6 time out on no packet
"sent/received" for a given period of time. If the sending application
doesn't expect a response, it could be sending packets that are ignored
at the other end for an indefinitely long time. At the least, this point
should be brought out in the text of that error case, and possibly the
ICMP response should be RECOMMENDED.
Discussion: Sending ICMP packets in response to this situation could
also possibly be abused for DoS, so sending of ICMP should be
rate-limited in this case. I'm proposing some text to try to balance
these concerns; any comments or other suggestions?
OLD TEXT:
Optionally, the receiving host MAY send an ICMP packet, with
the type Parameter Problem, to inform the sender that the HIP
association does not exist (see Section 5.4), and it MAY
initiate a new HIP BEX. However, responding with these
optional mechanisms is implementation or policy dependent.
SUGGESTED NEW TEXT:
Optionally, the receiving host MAY send an ICMP packet, with
the type Parameter Problem, to inform the sender that the HIP
association does not exist (see Section 5.4), and it MAY
initiate a new HIP BEX. However, responding with these
optional mechanisms is implementation or policy dependent.
If the sending application doesn't expect a response, the
system could possibly send a large number of packets in this
state, so for this reason, the sending of one or more ICMP
packets is recommended. However, any such responses should
be rate-limited to prevent abuse (see Section 5.4).
[PTT]
s/recommended/RECOMMENDED/ in the second-last line
Why "should" at the end of that line rather than MUST?
OK, if I change to capitalized RECOMMENDED, should the first sentence
also be changed from MAY to RECOMMENDED (i.e. are MAY and RECOMMENDED
incompatible terms)?
[PTT2] Yes, good catch. I sent the E-mail off in a hurry because someone
wanted my attention, and failed to review the whole paragraph. So the
paragraph could start: "The receiving host SHOULD send an ICMP packet
...". SHOULD and RECOMMENDED are equivalent, and definitely not
compatible with MAY.
I would be fine with changing the last line to a MUST.
[PTT2] Good.
...
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
