Subject: Operations Directorate Review of draft-ietf-hip-hiccups-02

From: Bernard Aboba <[email-masked]>
Date: Wed, 9 Jun 2010 04:55:30 -0700

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: [email-masked]
Subject: Operations Directorate Review of draft-ietf-hip-hiccups-02 by 2010-06-11
To: [email-masked]
CC: [email-masked]; [email-masked]

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
([email-masked]) 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