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(_at_)huawei(_dot_)com
Subject: Operations Directorate Review of draft-ietf-hip-hiccups-02 by
2010-06-11
To: bernard_aboba(_at_)hotmail(_dot_)com
CC: rbonica(_at_)juniper(_dot_)net; dromasca(_at_)avaya(_dot_)com
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(_at_)ietf(_dot_)org) 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
http://merlot.tools.ietf.org/tools/art/opsdir/index.cgi/t=4904/welcome
You could update the wiki page when you finish the
review.
Thank you,
Tina
http://tinatsou.weebly.com/contact.html
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf