Host Identity Protocol
draft-ietf-hip-base-10

[Note]: 'After Sam''s discuss is cleared, I need one more position recorded from Dan, Jon or Cullen to have the 2/3 necessary to approve these specs.' added by Mark Townsley

Email thread with basis for IESG note

-------- Original Message --------
Subject: Re: your DISCUSS on the HIP spec
Date: Tue, 25 Sep 2007 22:27:05 +0300
From: Gonzalo Camarillo
To: Mark Townsley
CC: Sam Hartman , Petri Jokela , "Henderson, Thomas R" , hip-chairs@tools.ietf.org, Jari Arkko , Pekka Nikander
References: <77F357662F8BFA4CA7074B0410171B6D0404975A@XCH-NW-5V1.nw.nos.boeing.com> 


Mark,

could you please take the text below, including Sam's suggestions, fix
the grammar (also per Sam's suggestion), and produce the IESG note we need?

Thanks,

Gonzalo


Sam Hartman wrote:
>>>>>> "Petri" == Petri Jokela  writes:
>
>    >> -----Original Message----- From: Sam Hartman
>    >> [mailto:hartmans-ietf@mit.edu] Sent: 5. syyskuuta 2007 22:48
>    >> To: Henderson, Thomas R Cc: hip-chairs@tools.ietf.org; Jari
>    >> Arkko; Mark Townsley; Pekka Nikander; Petri Jokela (JO/LMF)
>    >> Subject: Re: your DISCUSS on the HIP spec
>    >>
>    >> Hi.
>    >>
>    >> I look forward to the IESG note; I'd like to see hip get
>    >> published.
>
>    Petri> Hi,
>
>    Petri> here is an initial proposal for an IESG note. This is now
>    Petri> divided into base and esp draft sections; maybe they should
>    Petri> be combined and included in all the documents? I don't know
>    Petri> the usual procedure.
>
> We can do it either way.
>
>    Petri> /Petri
>
>
>
>    Petri> draft-ietf-hip-base
>
>
>    Petri> These issues describe the IESG concerns in this
>    Petri> document. It is expected that this list will be taken into
>    Petri> account when future versions of HIP are designed.
> s/taken into account/addressed
>
>    Petri> This document doesn't currently define support for
>    Petri> parameterized (randomized) hashing in signatures, support
>    Petri> for negotiation of a key derivation function, or support
>    Petri> for combined encryption modes.
>
>    Petri> HIP defines the usage of RSA mandatory in signing and
>    Petri> encrypting data. Current recommendations propose usage of
>    Petri> e.g. RSA OAEP/PSS for these operations. Changing the
>    Petri> algorithms for more recent ones needs to be considered.
> s/operations/operations in new protocols/
>
>    Petri> The current specification is currently using HMAC for
>    Petri> message authentication. This is considered to be acceptable
>    Petri> for experimental RFC, but future versions have to define a
>    Petri> more generic way allowing also other MAC algorithms to be
>    Petri> used.
>
>    Petri> SHA-1 is not any longer the preferred hashing
>    Petri> algorithm. This is noted also by authors but it is used for
>    Petri> this experimental version of HIP. Future versions must
>    Petri> consider other, more secure, hashing algorithms.
>
>    Petri> In incoming traffic handling it is specified that the
>    Petri> incoming packet's IP address is ignored. In simple cases
> How about but when there are security policies based on incoming interface
> or IP address rules
>
>    Petri> this can be done, but when there are e.g. different
>    Petri> security policies on different interfaces, the situation
>    Petri> changes. The handling of data needs to be enhanced to cover
>    Petri> different types of network and security configurations.
>
> Add and to meet local security policies.
>
>
>
>    Petri> draft-ietf-hip-esp
>
>    Petri> These issues describe the IESG concerns in this
>    Petri> document. It is expected that this list will be taken into
>    Petri> account when future versions of HIP are designed.
> see above
>
>    Petri> In case of complex SPDs and co-existence of HIP and
>    Petri> e.g. IKE, there may be unspecified conditions. For example

Email about items left for version -09

-------- Original Message --------
Subject: RE: your DISCUSS on the HIP spec
Date: Wed, 26 Sep 2007 13:59:06 +0200
From: Petri Jokela
To: Gonzalo Camarillo , Mark Townsley , Jari Arkko
CC: Sam Hartman , Henderson, Thomas R , , Pekka Nikander
References: <77F357662F8BFA4CA7074B0410171B6D0404975A@XCH-NW-5V1.nw.nos.boeing.com>    <46F96109.1050606@ericsson.com>


Hi,

In addition to the IESG note, there are few fixes that are needed in the

base draft: few typos in parameters, small mistake in state diagram and
few
pieces of text that were agreed to be included during discussions.

One thing that is still missing is the analysis on the Opportunistic
mode.
Jari was willing to help with the text so I hope he can provide
something
for me to be added in the draft.

Thus, there is a need to submit one more version of the draft (-09)
where
all these are fixed. In practise, I have everything ready, just the
opportunistic mode analysis is missing.

/petri

[Ballot discuss]
[revised to clarify issue with 6.2]

Hi.  I've evaluated this document set and held it to a higher level of
quality than I would normally hold an experimental publication to.
I'm assuming there is some reasonable chance that this will be the
basis of important internet architecture.
I'd rather identify issues now than when a successor to this version of HIP goes to proposed.
As such, many of my issues may be handled by documenting (in an IESG note?) as things that must be fixed before going to proposed.

HIP is missing several important features I'd expect a new
cryptographic protocol designed starting today to have: support for
parameterized (randomized) hashing in signatures; support for
negotiation of a key derivation function; support for combined
encryption modes.  By support I mean it should be possible to add
these in the future, more than that I'd expect them to be used now.
Support for randomized hashing seems most difficult.  I think these
will become more important in the future and HIP should be modified
now or should expect to be modified before it could become a standard.
If HIP were a completely new protocol today I'd expect it to use RSA
OAEP/PSS; this is probably forgivable.  Another significant problem is
that HIP is too tightly bound to HMAC.  There are several MACs these
days that are strong and not based on hashes.  I don't understand why
HIP needs to use an HMAC rather than a MAC.  It's fine if you choose
to use sha family hmacs today.  The security area is recommending when
people choose one hash today that it be stronger than sha-1.  If this
were not experimental you would need to use something stronger; as is,
I strongly recommend you use sha-256 for a hash.  It's not such a big
deal inside a HMAC.

HIP's handling of lost state seems insufficient to guarantee
interoperability.  Section 6.16 allows a HIP node to drop state at any
time.  However there is no mandatory to implement mechanism to recover
other than waiting for a potentially very long timeout.
Implementations MAY send ICMP messages; implementations may respond to
these messages.  But there is not actually a mechanism that people
have to make available to solve this.

Opportunistic mode is described sufficiently to implement but is not
analyzed from a security standpoint.  I think that you either need to
do the things you say are coming in another document, remove
opportunistic mode or do at least enough analysis to show that it is
not less secure than the Internet today.

Section 6.2 of the base spec needs to require that the HIT of the
incoming packet be checked to confirm that it is the expected HIT.

The base spec says that the IP address a packet
arrives/is sent on should be ignored.  The problem with this approach
is that different interfaces have different security properties.  I
may well be willing to send data without confidentiality protection
over a interface internal to a corporation but not over an external
interface.  This interaction would need to be carefully explored and
reasonable controls added before HIP would be appropriate as a
standard.
Thinking about HIP interacts with mandatory access control in the SPD is also going to be challenging.
I discuss one case of this below.

Section 6.3 needs to describe what key material to use.  It's implied
later, but whenever you describe a keyed cryptographic operation you
need to say what keys to use.  Similarly, the description of what data
is MACed and signed is not sufficient to meet the requirements of
id-nits.  Please show a diagram showing the header and data especially
for the hmac_2 parameter.  The procedure as described is too specific
to existing hip parameters.  The rules would break if you added some
new signature or mac related parameters and would be ambiguous if you
added new parameters that were not covered by the signature/mac.  You
should say something general like the signature/mac covers everything
before itself and nothing after.  (Obviously hip_signature_2 is more complicated)

Base document Section 6..6:
>Furthermore, upon timeout, the
>  implementation MUST refrain from sending the same I1 packet to
>  multiple addresses.

What does this mean?


Section 6.9:

>  11.  The implementation SHOULD also verify that the Initiator's HIT
>        in the I2 corresponds to the Host Identity sent in the I2.

Why is this a SHOULD not a MUST?


In the ESP document , how does HIP interact with the SPD?  Suppose I
have an SPD entry saying that traffic to 18/8 needs to be protected.
Suppose that I contact a machine via HIP whose HIT happens to resolve
to something in 18/8.  Do I expect double encapsulation? 

The ESP document does not make it clear what ipsec mode is being used.  It sounds like beet is desired, but beet is not a normative reference.  How is the mode indicated and what is the mandatory to implement mode?

In a discussion with secdir, Pekka N said that one of the motivations
behind the unsigned echo and echo response is for middleboxes.  I
don't think this is well defined enough to be interoperable as only
one of these parameters can exist in a packet.  What happens if a
middle box wants to add one of these and cannot do so because it
already exists?


I found no issues in the registration document and did not get a
chance to review the mobility document.

[Ballot comment]
draft-ietf-hip-mm-05,  Section 1:

    Finally, making
  underlying IP mobility transparent to the transport layer has
  implications on the proper response of transport congestion control,
  path MTU selection, and QoS.  Transport-layer mobility triggers, and
  the proper transport response to a HIP mobility or multihoming
  address change, are outside the scope of this document.

This is a important issue with mobility. I expect that there are some real considerations and hopefully solutions on this if and when HIP goes from experimental to standards track. But I do understand that it is likely to requrie also work on the transport side.

[Ballot comment]
draft-ietf-hip-mm-05,  Section 1:

    Finally, making
  underlying IP mobility transparent to the transport layer has
  implications on the proper response of transport congestion control,
  path MTU selection, and QoS.  Transport-layer mobility triggers, and
  the proper transport response to a HIP mobility or multihoming
  address change, are outside the scope of this document.

This is a potential important issue with mobility. I expect that there are some real consideration on this if and when HIP goes from experimental to standards track.

[Ballot comment]
It is possible to run vanilla IPsec and HIP on the same node and get
  the intended security services applied to the intended traffic if one
  is careful about configuration.  The security services are present,
  and it appears to be possible to use a HIP-unaware IPsec to do the HIP
  ESP processing.  One should worry about whether there is a possibility
  of a HIT conflicting with an actual IPv6 address as the technique
  advocated for a HIP-unaware IPsec implementation apparently has HITs
  masquerade as IPv6 addresses for IPsec processing.

  Since HIP and IPsec share a common SPI space, and traffic on any HIP
  SPI completely bypasses IPsec policy.  (Think about Steve Kent's usual
  rant about IPsec being more than just a means to apply cryptographic
  security mechanisms to traffic.)  The assurances that IPsec provides
  are easily broken with HIP, since inbound HIP traffic bypasses the
  IPsec SPD and gets handed directly to HIP, which logically has its
  own SPD.

  It is not clear to me exactly how to avoid this situation, or what to
  add to the document to warn about this security consideration.  A
  long discussion may be needed.  Since the document is intended for
  Experimental RFC, this may be an acceptable situation, but this must
  be resolved for this document to transition to the standards track.

[Ballot comment]
A lot of effort is spent supporting middleboxes that want to verify
HIP packets: signatures are required after key material is available
and especially on update packets.  As an option this seems like a
reasonable design choice.  However as a requirement this seems poorly
considered as it significantly increases the computational complexity
of HIP.  NATs get along today without verifying state.  I think there
are many cases where state verification will not be required for HIP.





I'd like to thank the HIP community for an excellent set of documents
for spending a lot of time working with the security directorate to
get their comments resolved.  I'd also like to thank the many security
directorate members who provided reviews.

[Ballot comment]
A lot of effort is spent supporting middleboxes that want to verify
HIP packets: signatures are required after key material is available
and especially on update packets.  As an option this seems like a
reasonable design choice.  However as a requirement this seems poorly
considered as it significantly increases the computational complexity
of HIP.  NATs get along today without verifying state.  I think there
are many cases where state verification will not be required for HIP.

[Ballot discuss]
Hi.  I've evaluated this document set and held it to a higher level of
quality than I would normally hold an experimental publication to.
I'm assuming there is some reasonable chance that this will be the
basis of important internet architecture.
I'd rather identify issues now than when a successor to this version of HIP goes to proposed.
As such, many of my issues may be handled by documenting (in an IESG note?) as things that must be fixed before going to proposed.

HIP is missing several important features I'd expect a new
cryptographic protocol designed starting today to have: support for
parameterized (randomized) hashing in signatures; support for
negotiation of a key derivation function; support for combined
encryption modes.  By support I mean it should be possible to add
these in the future, more than that I'd expect them to be used now.
Support for randomized hashing seems most difficult.  I think these
will become more important in the future and HIP should be modified
now or should expect to be modified before it could become a standard.
If HIP were a completely new protocol today I'd expect it to use RSA
OAEP/PSS; this is probably forgivable.  Another significant problem is
that HIP is too tightly bound to HMAC.  There are several MACs these
days that are strong and not based on hashes.  I don't understand why
HIP needs to use an HMAC rather than a MAC.  It's fine if you choose
to use sha family hmacs today.  The security area is recommending when
people choose one hash today that it be stronger than sha-1.  If this
were not experimental you would need to use something stronger; as is,
I strongly recommend you use sha-256 for a hash.  It's not such a big
deal inside a HMAC.

HIP's handling of lost state seems insufficient to guarantee
interoperability.  Section 6.16 allows a HIP node to drop state at any
time.  However there is no mandatory to implement mechanism to recover
other than waiting for a potentially very long timeout.
Implementations MAY send ICMP messages; implementations may respond to
these messages.  But there is not actually a mechanism that people
have to make available to solve this.

Opportunistic mode is described sufficiently to implement but is not
analyzed from a security standpoint.  I think that you either need to
do the things you say are coming in another document, remove
opportunistic mode or do at least enough analysis to show that it is
not less secure than the Internet today.

Section 6.2 of the base spec says that the IP address a packet
arrives/is sent on should be ignored.  The problem with this approach
is that different interfaces have different security properties.  I
may well be willing to send data without confidentiality protection
over a interface internal to a corporation but not over an external
interface.  This interaction would need to be carefully explored and
reasonable controls added before HIP would be appropriate as a
standard.
Thinking about HIP interacts with mandatory access control in the SPD is also going to be challenging.
I discuss one case of this below.

Section 6.3 needs to describe what key material to use.  It's implied
later, but whenever you describe a keyed cryptographic operation you
need to say what keys to use.  Similarly, the description of what data
is MACed and signed is not sufficient to meet the requirements of
id-nits.  Please show a diagram showing the header and data especially
for the hmac_2 parameter.  The procedure as described is too specific
to existing hip parameters.  The rules would break if you added some
new signature or mac related parameters and would be ambiguous if you
added new parameters that were not covered by the signature/mac.  You
should say something general like the signature/mac covers everything
before itself and nothing after.  (Obviously hip_signature_2 is more complicated)

Base document Section 6..6:
>Furthermore, upon timeout, the
>  implementation MUST refrain from sending the same I1 packet to
>  multiple addresses.

What does this mean?


Section 6.9:

>  11.  The implementation SHOULD also verify that the Initiator's HIT
>        in the I2 corresponds to the Host Identity sent in the I2.

Why is this a SHOULD not a MUST?


In the ESP document , how does HIP interact with the SPD?  Suppose I
have an SPD entry saying that traffic to 18/8 needs to be protected.
Suppose that I contact a machine via HIP whose HIT happens to resolve
to something in 18/8.  Do I expect double encapsulation? 

The ESP document does not make it clear what ipsec mode is being used.  It sounds like beet is desired, but beet is not a normative reference.  How is the mode indicated and what is the mandatory to implement mode?

In a discussion with secdir, Pekka N said that one of the motivations
behind the unsigned echo and echo response is for middleboxes.  I
don't think this is well defined enough to be interoperable as only
one of these parameters can exist in a packet.  What happens if a
middle box wants to add one of these and cannot do so because it
already exists?


I found no issues in the registration document and did not get a
chance to review the mobility document.

-------- Original Message --------
Subject: Re: I-D ACTION:draft-ietf-hip-base-03.txt
Date: Thu, 23 Jun 2005 20:00:45 -0400
From: Bruce Lilly
Reply-To: ietf@ietf.org
Organization: Bruce Lilly
To: ietf@ietf.org
CC: petri.jokela@nomadiclab.com, rgm@icsalabs.com, thomas.r.henderson@boeing.com
References:


On Thu June 23 2005 18:50, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Host Identity Protocol Working Group of the IETF.
>
> Title : Host Identity Protocol
> Author(s) : R. Moskowitz, et al.
> Filename : draft-ietf-hip-base-03.txt
> Pages : 96
> Date : 2005-6-23
>
> This memo specifies the details of the Host Identity Protocol (HIP).
>    HIP provides a rapid exchange of Host Identities (public keys)
>    between hosts and uses a Sigma-compliant [REF] Diffie-Hellman key
>    exchange to establish shared secrets between such endpoints.  The
>    protocol is designed to be resistant to Denial-of-Service (DoS) and
>    Man-in-the-middle (MitM) attacks, and when used together with another
>    suitable security protocol, such as Encapsulated Security Payload
>    (ESP) [24], it provides encryption and/or authentication protection
>    for upper layer protocols such as TCP and UDP, while enabling
>    continuity of communications across network layer address changes.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-hip-base-03.txt

Brief comments:

1. The Abstract isn't supposed to contain references.

2. It is helpful to indicate a suggested forum for discussion
  (the Abstract is a good place)

3. Numeric references are deprecated
  http://www.rfc-editor.org/pipermail/rfc-interest/2005-January/000235.html

4. The introduction refers to an architecture document, reference #25:
  [25]  Moskowitz, R., "Host Identity Protocol Architecture",
        draft-moskowitz-hip-arch-03 (work in progress), May 2003.

  Given the date, I strongly suspected expiration; I checked the I-D
  database:
  https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=4950
  which shows a -06 version as the latest, also expired, and therefore no
  link to retrieve the document.  Dead End.

5. Appendices (the draft's contain reference citations) should appear
  before the Normative/Informative references.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

[Note]: 'One remaining issue with ORCHID document that is normatively referenced from here. Requested authors to remove as many dependencies as possible (no duplicate information in multiple documents) and move forward (letting the normative reference alone be a holdup, and no longer needing to sync between the two documents). Waiting for new docs, and then should be ready to go on telechat.' added by Mark Townsley

[Note]: 'Awaiting new document with (1) Resolution of HIT issue (as documented in attached email from chair), (2) GEN-ART review comments (mostly editorial), and (3) outcome of secdir review. Pinged authors/chairs/sec-ads 1/15/2007' added by Mark Townsley

-------- Original Message --------
Subject: Re: Your new charter was approved
Date: Sat, 28 Oct 2006 12:45:25 +0300
From: Gonzalo Camarillo
To: Mark Townsley
CC: hip-chairs@tools.ietf.org
References: <4540F284.8030607@cisco.com>


Hi Mark,

there are ongoing discussions on the prefix to be used for HITs (Host
Identity Tags), which act as host identifiers. Ted had some concerns and
we may need a new IETF LC. Those discussions affect the base HIP spec.

Then, we have sent you all the remaining documents, which are ready for
IETF LC.

Regarding the new milestones, we have initial documents for all of them.

If you need further info, let us know.

Cheers,

Gonzalo

[Note]: 'Awaiting new document with (1) Resolution of HIT issue (as documented in attached email from chair), (2) GEN-ART review comments (mostly editorial), and (3) outcome of secdir review.' added by Mark Townsley

IANA Last Call Comments:

Upon approval of this document IANA understands that three
IANA Actions are required.

First, IANA will assign a protocol number for HIP in the
following registry:
http://www.iana.org/assignments/protocol-numbers
The document specifies the protocol number 253 which is
currently reserved for experimental use.

Second, IANA will assign a new 128-bit value in the CGA
Message Type Name Space which is located at:
http://www.iana.org/assignments/cga-message-types
The new value will be:
0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA

Third, IANA will create a new HIP Parameters Name Space
with the following seven Name Spaces within it:

- Packet Type
- HIP Version
- Parameter Type
- Group ID
- Suite ID
- DI-Type
- Notify Message Type

Each of these new Name Spaces will be instantiated with
the values and new value assignment rules documented in
the IANA Considerations section. IANA will use the
instructions on pages 86 through 90 to create the new
HIP Parameters Name Space.

IANA understands these three actions to be the only
actions required for this document.

PROTO Write-up

    (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?

Gonzalo Camarillo, who is the shepherd for this document and co-chairs the HIP WG, has reviewed this document and 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 reviewed thoroughly. The reviews performed included a Belovin-Rescorla security analysis.


    (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, the shepherd does not have any concerns.


    (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 those issues have been discussed in the WG and the
          WG has indicated that it still wishes to advance the document,
          detail those concerns here.

No, the shepherd does not have any concerns.


    (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?

The whole WG is behind this document.


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

There have been discussions on the length of the IPv6 prefix to be allocated for this experiment. The document normatively references the draft entitled "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers  (ORCHID)", which at this point defines a /28 prefix. It seems that now, all the parties involved in the discussion are happy with this length.


    (1.g)  Has the Document Shepherd 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.

The document has two missing references: RFC2536 and RFC3110. This detail can be resolved along with other IETF last call comments once its IETF last call ends.


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

Yes, the references have been separated and there are normative references to Internet Drafts. Among these, the reference that could potentially delay the publication of this document could be the ORCHID draft (See 1.f). The HIP WG will request the publication of the draft entitled "Using ESP transport format with HIP" at the same time as this document. They should be processed together by the IESG.


    (1.i)  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 memo specifies the details of the Host Identity Protocol (HIP).
    HIP allows consenting hosts to securely establish and maintain shared
    IP-layer state, allowing separation of the identifier and locator
    roles of IP addresses, thereby enabling continuity of communications
    across IP address changes.  HIP is based on a Sigma-compliant Diffie-
    Hellman key exchange, using public-key identifiers from a new Host
    Identity name space for mutual peer authentication.  The protocol is
    designed to be resistant to Denial-of-Service (DoS) and Man-in-the-
    middle (MitM) attacks, and when used together with another suitable
    security protocol, such as Encapsulated Security Payload (ESP), it
    provides integrity protection and optional encryption for upper layer
    protocols, suchs as TCP and UDP.  Discussion related to this document
    is going on at the IETF HIP Working Group mailing list.


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

    Consensus was strong 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?

    There are several known implementations of this specification.


Thanks,

Gonzalo
HIP co-chair