|
I reviewed the document draft-ietf-hip-hiccups-02.txt in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Experimental This document defines a new HIP (Host Identity Protocol) packet type called DATA. HIP DATA packets are used to securely and reliably convey arbitrary protocol messages over the Internet and various overlay networks, without running the HIP base exchange beforehand. This results in the HIP DATA packet requiring less overhead but without the DoS protection afforded by the base exchange. Is the document readable? Yes. Does it contain nits? idnits 2.12.04 tmp/draft-ietf-hip-hiccups-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- == You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/) Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (March 4, 2010) is 97 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 1 warning (==), 1 comment (--). Is the document class appropriate? Yes. Is the problem well stated? Section 6 describes the rationale for use of the HIP DATA packet: HIP currently requires always that the four-message base exchange is executed at the first encounter of hosts that have not communicated before. This may add additional RTTs (Round Trip Time) to protocols based on a single message exchange. However, the four-message exchange is essential to preserve the half-stateless DoS protection nature of the base exchange. The use of the HIP DATA packet defined in this document reduces the initial overhead in the communications between two hosts at the expense of decreasing DoS protection. Therefore, applications SHOULD NOT use HIP DATA packets in environments where DoS attacks are believed to be an issue. For example, a HIP-based overlay may have policies in place to control which nodes can join the overlay. Any particular node in the overlay may want to accept HIP DATA packets from other nodes in the overlay given that those other were authorized to join the overlay. However, the same node may not want to accept HIP DATA packets from random nodes that are not part of the overlay. The type of data to be sent is also relevant to whether the use of a HIP DATA packet is appropriate. HIP itself does not support fragmentation but relies on underlying IP-layer fragmentation. This may lead to reliability problems in the case where a message cannot be easily split over multiple HIP messages. Therefore, applications in environments where fragmentation could be an issue SHOULD NOT generate too large HIP DATA packets that may lead to fragmentation. The implementation SHOULD check the MTU of the link before sending the packet and if the packet size is larger than MTU it SHOULD signal to the upper-layer protocol if the packet results in to a ICMP error message. Note that there are environments where fragmentation is not an issue. For example, in some HIP-based overlays, nodes can exchange HIP DATA packets on top of TCP connections that provide transport-level fragmentation and, thus, avoid IP-level fragmentation. Is the problem really a problem? Yes. In situations where a host will be intiating transactions with hosts it has not communicated with before on a frequent basis, the existing HIP base exchange will have unacceptable overhead. Is the solution really a solution? No. We know from experience that the kind of use restrictions referred to above are difficult to maintain in practice, because it is difficult to determine the situations in which a DoS attack will not be an issue. For example, even though HIP DATA might be designed to be used in a closed network not connected to the Internet, something unexpected could happen (e.g. one or more hosts become infected, the "closed" network gets connected unexpectedly, etc.). Also with respect to MTU/fragmentation issues, a request might not cause fragmentation, but a response might. The classic case is a DNS response carrying DNSSEC information. In such a situation, it seems that the HIP DATA packet could cause failures that would be difficult to diagnose. Does the document consider existing solutions? Yes. The document has analyzed the issues with the HIP base exchange. Does the solution break existing technology? Possibly. As noted above, it seems possible that HIP DATA will not work reliably in some situations. Also, implementations which rely on the HIP DATA packet for essential functionality will not interoperate with existing implementations which rely on the HIP base exchange. To prevent this, it's necessary for the document to state that an implementation must use the HIP base exchange in situations where the other peer doesn't support HIP DATA. Does the solution preclude future activity? In theory, no. However, in practice, I'm concerned that the HIP DATA packet will be extensively used in situations not envisaged by this specification, and this will complicate future standardization efforts. Is the solution sufficiently configurable? Possibly not. The document doesn't describe how an implementation would determine what traffic will be sent using HIP DATA packets. For example, I might expect a filter model to be used, similar to that in use for IPsec. Can performance be measured? How? Yes. For example, the latency of a HIP DATA exchange can be compared against the HIP base exchange based on packet traces. Does the solution scale well? Yes. The HIP DATA packet is designed to perform well in situations where the HIP base exchange would have unacceptable overhead. Is Security Management discussed? Yes. Section 6 describes the tradeoffs in usage of the HIP DATA packet. Date: Thu, 3 Jun 2010 10:03:43 +0800 From: tena@xxxxxxxxxx Subject: Operations Directorate Review of draft-ietf-hip-hiccups-02 by 2010-06-11 To: bernard_aboba@xxxxxxxxxxx CC: rbonica@xxxxxxxxxxx; dromasca@xxxxxxxxx Hello,
As a member of the Operations Directorate you are being asked to review the following draft which is in IETF last call for it's operational impact. IETF Last Call:
The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-hip-hiccups-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19354&rfc_flag=0 Please provide comments and review to the Ops-dir mailing
list
(ops-dir@xxxxxxxx) before 2010-06-11, and include the authors of the draft as well. For a list of questions to be answered in an OPS-DIR
review see Appendix A
in RFC 5706. Note that not all questions may apply to all documents, and some other items may be identified by the OPS-DIR reviews. The status of Operations Directorate Review could be
found
http://trac.tools.ietf.org/area/ops/trac/wiki/Directorates or
You could update the wiki page when you finish the
review.
Thank you,
|
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf