Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)
draft-ietf-hip-hiccups-05

[Ballot discuss]
Updated:

#2) In Section 6: Where is the mechanism defined that allows these policies to enforce authorization to join the overlay?  If it's out-of-scope or not defined please add that.

[Ballot comment]
Thank you for addressing my earlier discusses and comments. One more issue resulting from the most recent change:

5.3.1. Handling of SEQ_DATA in a Received HIP DATA packet


  The following steps define the conceptual processing rules for
  handling a SEQ_DATA parameter in a received HIP DATA packet.

  The system MUST verify the SIGNATURE in the HIP DATA packet.  If the
  verification fail, the packet SHOULD be dropped and an error message
  logged.

  If the value in the received SEQ_DATA and MIC value received
  PAYLOAD_MIC corresponds to a HIP DATA packet that has recently been
  processed, the packet is treated as a retransmission.  The SIGNATURE
  verification (next step) MUST NOT be skipped.

This sentence needs to be deleted, because you've reordered paragraphs as I suggested earlier.

  (A byte-by-byte
  comparison of the received and a stored packet would be adequate,
  though.)  It is recommended that a host cache HIP DATA packets sent
  with ACKs to avoid the cost of generating a new ACK packet to respond
  to a retransmitted HIP DATA packet.  The host MUST acknowledge,
  again, such (apparent) HIP DATA packet retransmissions but SHOULD
  also consider rate-limiting such retransmission responses to guard
  against replay attacks.

[Ballot comment]
The Gen-ART Review by Elwyn Davies on 15 June 2010 offers many minor
  comments and editorial nits.  Please consider them.

    http://www.softarmor.com/rai/temp-gen-art/
    draft-ietf-hip-hiccups-02-davies.txt

[Ballot discuss]
I'm trying to get HIP.

#1) draft-ietf-hip-bone says "Before two HIP hosts exchange upper-layer traffic, they perform a four-way handshake that is referred to as the HIP base exchange" and now this I-D says that the DATA packet can be used to convey (in a secure and reliable way) protocol messages to a remote host without running the HIP base exchange between them.  So am I to infer that the contents of the DATA packet is not upper-layer traffic?  Nope at the end of Section 4 it says "Upper-layer protocol messages, such as overlay network control traffic, sent in HIP DATA messages ..." Is one of the documents wrong or is some rewording needed?

#2) In Section 6: Where is the mechanism defined that allows these policies to enforce authorization to join the overlay?  If it's out-of-scope or not defined please add that.

[Ballot comment]
The Introduction says...

  The HIP_DATA packet is not aimed to be a
  replacement for ESP transport instead it SHOULD only be used to
  exchange few packets between the peers.

I find this woolly on three counts.

1. "not aimed" Is it or is it not?
2. "SHOULD only" Feels like you need to flip this to a "SHOULD NOT"
  For example: "SHOULD NOT be used to exchange more than..."
3. "exchange [a] few packets" Your opinion of "a few" may differ from
  mine. What is the real 2119 constraint here?

---

Would be helpful to explain what a MAC is in section 2.

---

Is it the intention that new HIP implementations should include support for the DATA packet? If so, doesn't this I-D update 5201?

---

Section 4 appears to use some form of syntax to define the DATA packet. You should probably include a reference to the definition of that syntax.

[Ballot discuss]
I'm trying to get HIP.

#1) draft-ietf-hip-bone says "Before two HIP hosts exchange upper-layer traffic, they perform a four-way handshake that is referred to as the HIP base exchange" and now this I-D says that the DATA packet can be used to convey (in a secure and reliable way) protocol messages to a remote host without running the HIP base exchange between them.  So am I to infer that the contents of the DATA packet is not upper-layer traffic?  Nope at the end of Section 4 it says "Upper-layer protocol messages, such as overlay network control traffic, sent in HIP DATA messages ..." Is one of the documents wrong or is some rewording needed?

#2) In Section 6: Where is the mechanism defined that allows these policies to enforce authorization to join the overlay?  If it's out-of-scope or not defined please add that.

[Ballot discuss]
I'm trying to get HIP.

#1) draft-ietf-hip-bone says "Before two HIP hosts exchange upper-layer traffic, they perform a four-way handshake that is referred to as the HIP base exchange" and now this I-D says that the DATA packet can be used to convey (in a secure and reliable way) protocol messages to a remote host without running the HIP base exchange between them.  So am I to infer that the contents of the DATA packet is not upper-layer traffic?  Nope at the end of Section 4 it says "Upper-layer protocol messages, such as overlay network control traffic, sent in HIP DATA messages ..." Is one of the documents wrong or is some rewording needed?

#2) In Section 6: Where is the mechanism defined that allows these policies to enforce authorization to join the overlay?  If it's out-of-scope or not defined please add that.

[Ballot discuss]
I'm trying to get HIP.

#1) draft-ietf-hip-bone says "Before two HIP hosts exchange upper-layer traffic, they perform a four-way handshake that is referred to as the HIP base exchange" and now this I-D says that the DATA packet can be used to convey (in a secure and reliable way) protocol messages to a remote host without running the HIP base exchange between them.  So am I to infer that the contents of the DATA packet is not upper-layer traffic?  Nope at the end of Section 4 it says "Upper-layer protocol messages, such as overlay network control traffic, sent in HIP DATA messages ..." Is one of the documents wrong or is some rewording needed?

#2) In Section 6: Where is the mechanism defined that allows these policies to enforce authorization to join the overlay?  If it's out-of-scope or not defined please add that.

[Ballot comment]
Agreeing with Peter's DISCUSS (at least agreeing that we should have a discussion).


In Section 5.3.1: suggestion to reorder paragraphs to make processing order more logical. I.e. SIGNATURE processing first, then PAYLOAD_MIC processing, then SEQ_DATA processing.
Similar comment regarding 5.3.2.

[Ballot discuss]
The following issues are probably trivial, but I think they still need to be fixed before I can recommend approval of this document.

5.1.  Handling of SEQ_DATA and ACK_DATA

  A HIP DATA packet contains zero or one ACK_DATA parameters.  The ACK
  parameter echoes the SEQ_DATA sequence number of the HIP DATA packet
  packet being ACKed.  One ACK_DATA parameter MUST contain one more
  sequence numbers of the HIP DATA packets being ACKed.

"one or more"?

The definition of ACK_DATA Parameter in Section 4.2 doesn't seem to allow
for multiple acknowledged sequence numbers. At least the format doesn't show multiple values.

5.2.  Generation of a HIP DATA packet

  5.  If the DATA timer expires, the HIP DATA packet is resent.  The
      HIP DATA packet can be resent DATA_RETRY_MAX times.  The DATA
      timer SHOULD be exponentially backed off for subsequent
      retransmissions.  If no acknowledgment is received from the peer
      after DATA_RETRY_MAX times, the delivery of the HIP DATA packet
      is considered unsuccessful and the application is notified about
      the error.  The DATA timer is canceled upon receiving an ACK from
      the peer that acknowledges receipt of the HIP DATA packet.

Where DATA_RETRY_MAX defined?

8.  IANA considerations

  This document updates the IANA Registry for HIP Packet types by
  introducing new packet type for the new HIP_DATA (Section 4) packet.
  This document updates the IANA Registry for HIP Parameter Types by
  introducing new parameter values for the SEQ_DATA (Section 4.1),
  ACK_DATA (Section 4.2), and PAYLOAD_MIC (Section 4.3) parameters.

This doesn't mention TRANSACTION_ID defined in Section 4.4.

[Ballot discuss]
I'm fine with this draft as an Experimental RFC, however, there were
a couple of points where the draft was not clear enough to the reader:

1. My understanding is that with this mechanism, it will be possible
to provide data origin authentication (via the signature) and integrity
protection (via the MIC and the signature). But not confidentiality.
This seems like a difference to the base HIP functionality that should
be highlighted, along with DoS protection.

2. The draft does not explain when the HOST_ID parameter can be
omitted (it is listed as optional in Section 4). How would the
verification of the signature happen without the sender's HOST_ID?
Presumably you can omit it if there's reason to assume the receiver
already has it, but the specification does not tell us how we can
determine that, or what the recourse is if that assumption fails.

3. I did not understand how to use PAYLOAD_MIC. Quoting the draft:

  The
  PAYLOAD_MIC contains the checksum of the payload following after the
  HIP DATA.
  ...
  The payload
  that is protected by the PAYLOAD_MIC parameter has been linked to the
  appropriate upper-layer protocol by storing the upper-layer protocol
  number, 8 bytes of payload data, and by calculating a hash sum (MIC)
  over the data.
  ...
  Next Header      Identifies the data that protected by this MIC.
                    The values for are defined by IANA "Assigned
                    Numbers".
  Payload Data      8 last bytes of the payload data over which the
                    MIC is calculated. This field is used to
                    uniquely bind PAYLOAD_MIC parameter to next header,
                    in case there are multiple copies of same type.
  Payload MIC      MIC computed over the data to which the Next
                    Header and Payload Data points to.
  ...
  If there is multiple next header types
  which the host wants to protect it SHOULD create separate
  PAYLOAD_MIC parameter for each of these.

I guess you are assuming that the last 8 bytes of payload data are
unique, right? If so, say so and indicate that as a limitation of what
traffic can be carried. Not that I can think of any case where that
would practically not be the case, but theoretically... Otherwise I may
be missing what you intend to do here.

[Ballot discuss]
Despite various warnings in the spec and the fact that it is Experimental, this seems to be a bad idea. Why are we encouraging implementers to bypass normal HIP authentication handshakes to convey arbitrary protocol messages? Isn't that similar to, say, SIP INFO (which we're madly working to stamp out)? Five years from now, will we be writing a spec entitled "HIP DATA Packets Considered Harmful"? The shepherd writeup says of the WG that "there was strong consensus on this document", but did the WG also consider whether this extension would be harmful to the Internet?

[Ballot discuss]
The content of the DISCUSS is based in part on the OPS-DIR review performed by Bernard Aboba.

1. I think that this document (and the other hip documents) need to included a short explanation of the reasons for which the WG was chartered to issue Experimental RFCs, what kind of experimentation should be planned for the protocol extension, what are the expected results, and whether there are deployment concerns or limitations that need to be taken into consideration by operators. If this information can be found in some other hip document a reference would be fine.

2. Section 6 makes the following recommendations related to the usage of the HIP DATA packet:

>  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.

However, experience hows 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. 

3. There is a possible concern for backwards compatibility which is not sufficiently explored. 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. I am not sure however how this situation is detected in advance.

4. The document doesn't describe how an implementation would
determine what traffic will be sent using HIP DATA packets.  For example,
one might expect a filter model to be used, similar to that in use for
IPsec.

[Ballot discuss]
The content of the DISCUSS is based in part on the OPS-DIR review perfromed by Bernard Aboba.

1. I think that this document (and the other hip documents) need to included a short explanation of the reasons for which the WG was chartered to issue Experimental RFCs, what kind of experimentation should be planned for the protocol extension, what are the expected results, and whether there are deployment concerns or limitations that need to be taken into consideration by operators. If this information can be found in some other hip document a reference would be fine.

2. Section 6 makes the following recommendations related to the usage of the HIP DATA packet:

>  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.

However, experience hows 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. 

3. There is a possible concern for backwards compatibility which is not sufficiently explored. 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. I am not sure however how this situation is detected in advance.

4. The document doesn't describe how an implementation would
determine what traffic will be sent using HIP DATA packets.  For example,
one might expect a filter model to be used, similar to that in use for
IPsec.

[Ballot discuss]
Section 4., paragraph 0:
>    4.  The hosts sends the created HIP DATA packet and starts a DATA
>        timer.  The default value for the timer is 2 * RTT estimate.

  DISCUSS: Most often, the sending host will not have an RTT estimate
  for the recipient. Even when there is an RTT estimate taken during
  some previous packet exchanges, the question is whether that is still
  accurate enough after some time. Suggest to do instead what TCP does
  for SYN retransmissions and make this timer 3 seconds.


Section 5., paragraph 0:
>    5.  If the DATA timer expires, the HIP DATA packet is resent.  The
>        HIP DATA packet can be resent DATA_RETRY_MAX times.  The DATA
>        timer SHOULD be exponentially backed off for subsequent
>        retransmissions.

  DISCUSS: The exponential backoff needs to be a MUST and not just a
  SHOULD.

IANA questions/comments:

QUESTION: In section 4.4. you define a TRANSACTION_ID, but you don't
tell us to register it. Should you be registering the TRANSACTION_ID?

Action 1:

Upon approval of this document, IANA will make the following assignment
in the "Host Identity Protocol (HIP) Parameters" registry located at
http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml
sub-registry "Packet Types"

Value Packet Type Reference
----- ---------- ---------
TBD HIP_DATA [RFC-hip-hiccups-02]


Action 2:

Upon approval of this document, IANA will make the following assignments
in the "Host Identity Protocol (HIP) Parameters" registry located at
http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml
sub-registry "Parameter Types"

Value Parameter Type Length Reference
----- -------------- ------ ---------
TBD SEQ_DATA 4 [RFC-hip-hiccups-02]
TBD ACK_DATA variable [RFC-hip-hiccups-02]
TBD PAYLOAD_MIC variable [RFC-hip-hiccups-02]


We understand the above to be the only IANA Actions for this document.

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

David Ward is the sheperd for this document. He believes it is ready.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document has been adequately reviewed.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

The are no concerns about this document and no IPR has been filed.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

It represents the consensus of the whole WG.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

The document passes ID nits.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The document has both normative and informative references. All
normative references are RFCs.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

The IANA considerations section is appropriate.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

The document does not use formal language.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary

            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

  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.

          Working Group Summary

            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

There was strong consensus on this document.

          Document Quality

            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

There are prototype implementations of this spec. A few vendors have
expressed interest in implementing this in the context of HIP BONE
overlays.

          Personnel

            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

David Ward is the document shepherd for this document. Ralph Droms is
the responsible AD for this document.