Subject: [Hipsec] Feedback for 4423bis

From: Sasu Tarkoma <[email-masked]>
Date: Wed, 10 Oct 2012 22:05:47 +0300

Hi all,

I read the latest HIP architecture draft (4423bis-05) and it looks
very good. Below you will find some observations that I made
when reading the draft.

Best regards,
- Sasu

------

- Architecture and implementation details are partly
 intertwined here. Perhaps the generic model can
be summarised first and then the implementation
specific details. Theory of HI is mentioned in the 
beginning, but I think it is not clear for all readers what 
is meant by this. 

- It is stated that the model is general and it does not require 
public key crypto; however, this is not really elaborated. Also
it is stated that the model can be applied at any
layer, but this is not explained. The description assumes
that Host Identity decouples internetworking and
transport layers.

- The draft does not discuss architecture and protocol
deployment issues. This is one practical requirement given
the momentum of the current solutions.

- The description of the HIP protocol is quite light in this
draft. The introductory part to section 5 could briefly state the
key components of HIP including BEX, mobility/multihoming support,
and rendezvous that are covered by the following subsections.

- In section 5, it is stated that:
"Similarly, if it is possible to distribute the processing of a single
   Host Identity over several physical computers, HIP provides for
   cluster based services without any changes at the client end-point."

I think the base specification and implementation do not directly
support this, but additional management extensions are needed.

- Computational puzzle does not appear to be mentioned.

- Extensions (new hash functions) are not elaborated. This is
related to a general requirement that a protocol should be evolvable. 

- p. 17 section 10 needs a reference

- p. 21 the downgrade attack should be elaborated.

- Typo: p. 5 Identfier

---

From: Miika Komu <[email-masked]>
Date: Fri, 19 Oct 2012 00:38:54 +0300

Hi,

> very good. Below you will find some observations that I made

looks good to me too but I have also some suggestions for improvement. 
Here's the first batch of comments, I'll send the remaining ones later.

> 1. Introduction
> ...
> Although the Host Identifiers could be used in many authentication
> systems, such as IKEv2 [RFC4306], the presented architecture
> introduces a new protocol, called the Host Identity Protocol (HIP),
> and a cryptographic exchange, called the HIP base exchange; see also
> Section 7.  The HIP protocols provide for limited forms of trust
> between systems, enhance mobility, multi-homing and dynamic IP
> renumbering, aid in protocol translation / transition, and reduce
> certain types of denial-of-service (DoS) attacks.

(The HIP protocols provide -> HIP provides)

based on offline discussions with a few people, I'd suggest adding 
something like the following:

Back-to-My-Mac [RFC6281] from Apple comes pretty close to the 
functionality of HIP. Unlike HIP, it is based on non-cryptographic 
identifiers and is based on a collection of protocols rather than a 
single one like HIP. As an analogy to UNIX software, Back-to-My-Mac 
could be considered as command line tools combined using piping. In 
contrast, HIP takes the approach that the bandwidth and latency of the 
"pipe", that is the network, is constrained resource, and combines 
multiple functionalities to a single protocol.

> Much has been learned about HIP since [RFC4423] was published.  This
> document expands Host Identities beyond use to enable IP connectivity
> and security to general interhost secure signalling at any protocol
> layer.  The signal may establish a security association between the
> hosts, or simply pass information within the channel.

Much has been learned... I would suggest to add an information reference 
to the experiment report (RFC6538).

> 2.1. Terms common to other documents

You talk about RSA and DSA, perhaps you could mention also ECC.

> 3. Background
> ...
> (silicon based people, if you will).  All these components need to be
> ..

silicon-based people

> Secondly, anonymity is not provided in a consistent, trustable manner.

Yes, blind extensions support anonymity but I think the point here 
should be about confidentiality rather than anonymity.

> 3.1. A desire for a namespace for computing platforms
>
> * The namespace should fully decouple the internetworking layer from
>   the higher layers.  The names should replace all occurrences of IP
>   addresses within applications (like in the Transport Control
>   Block, TCB).  This may require changes to the current APIs.  In
>   the long run, it is probable that some new APIs are needed.

I would suggest to replace the last two sentences with the following:

While HIP is compatible with legacy applications [RFC5338], developers 
trying to harness to full benefits of HIP should employ APIs for 
HIP-aware applications [RFC6317].

(Both references should be informative)

> * Sometimes the names may contain a delegation component.  This
>  is the cost of resolvability.

Please elaborate, this is too vague. Are referring to the referral 
issues, please see section 4.2 in RFC6538. Or process migration and 
delegation?

> 4. Host Identity namespace
> ..
> However, in the authors'
> opinion, a public key of a 'public key pair' makes the best Host
> Identifier.

Suggest replacing with:

In the HIP architecture, the public key of a private-public key pair has 
been chosen as the Host Identifier because it can be self managed and 
computationally difficult to forge.

> There is on-going research in challenge puzzles to use
> non-cryptographic HI, like RFIDs, in an HIP exchange
> tailored to the workings of such challenges.

is on-going -> has been past (should you reference to rfid draft?)

> The actual Host Identifiers are never directly used in any Internet
> protocols

At least, not intentionally (referral issues). Or what you mean by 
"Internet protocols"?

> 4.2. Host Identity Hash (HIH)

where does intermediary term "HIH" comes from? I think it's not 
necessary (is it in the other RFCs?)

> The Host Identity Hash is the cryptographic hash used in producing
> the HIT from the HI.

hash -> hash algorithm

> It is possible to for the two hosts in the HIP exchange to use
> different hashes.

hashes -> hash algorithms

> 4.3. Host Identity Tag (HIT)
> ..
> There can be multiple HITs per Host Identifier when multiple hashes
> are supported.  An Initator may have to initially guess which HIT to
> use for the Responder, typically based on what it prefers, until it
> learns the appropriate HIT through the HIP exchange.

Isn't this information directly in the OGA bits?

> 4.4. Local Scope Identifier (LSI)

I would add in the end of the last paragraph that "LSIs make it possible 
for an IPv4-based application to communicate with an IPv6-based 
application".

> 4.5. Storing Host Identifiers in Directories
>
> Alternatively, or in addition to storing Host Identifiers in the DNS,
> they may be stored in various other directories (e.g.  LDAP, DHT) or
> in a Public Key Infrastructure (PKI)

Please add an informational reference to RFC6537 just after the DHT.

> 5.1. Transport associations and end-points
> ..
> It is possible that a single physical computer hosts several logical
> end-points.  With HIP, each of these end-points would have a distinct
> Host Identity.  Furthermore, since the transport associations are
> bound to Host Identities, HIP provides for process migration and
> clustered servers.  That is, if a Host Identity is moved from one
> physical computer to another, it is also possible to simultaneously
> move all the transport associations without breaking them.
> Similarly, if it is possible to distribute the processing of a single
> cluster based services without any changes at the client end-point.

I think there was also some other comments about this. This text is not 
in good shape and it needs to written. It mixes two separate topics into 
a single paragraph:

* Distributing HI processing - sounds like a nice research idea but it's 
badly explained and lacks a reference. I'd suggest removing.
* Process migration is way more complicated than the text implies 
(suggest removing).

Btw, the best reference for HIP-based process migration with delegation 
is this:

S. Herborn, A. Huber, R. Boreli, and A. Seneviratne. Secure host 
identity delegation for mobility. In COMSWARE. IEEE, 2007.

(Talking about clusters and process migration is a bit old fashioned 
since nowadays as cloud computing and VM migration are more fashionable :)

> 6. End-host mobility and multi-homing
> ..
> However, as discussed in
> Section 6.2 below, a mobile node must send a HIP readdress packet to
> inform the peer of the new address(es), and the peer must verify that
> the mobile node is reachable through these addresses.

readdress -> UPDATE

Remaining comments later!

P.S. Please add also "Aalto University" and "RWTH Aachen" to the 
acknowledgement list, thanks!

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 19 Oct 2012 00:24:53 -0400

I want to thank both of you for these comments.

Updating 4423 has been hard; there is a historical prospective that has 
needed to be addressed, and I missed a number of points. Note that 
4423-bis NEEDs to remain an architectual document, and not a protocol 
document. This is a fine line to tread; particularly here in the IETF 
where protocols are our life. But it needs to reflect the current state 
of the art, not a forecast of where the art is going. This means that 
there are many items that were TBDs back when 4423 was penned, but are 
now finished. Likewise, HIP-RFID is still work in progress.

So my goal is to work up the next version for mid-next week. I will be 
posting some text here for review purposes.

On 10/18/2012 05:38 PM, Miika Komu wrote:
> Much has been learned... I would suggest to add an information 
> reference to the experiment report (RFC6538).
>
> In the HIP architecture, the public key of a private-public key pair 
> has been chosen as the Host Identifier because it can be self managed 
> and computationally difficult to forge.
>
> I would add in the end of the last paragraph that "LSIs make it 
> possible for an IPv4-based application to communicate with an 
> IPv6-based application".
>
> I think there was also some other comments about this. This text is 
> not in good shape and it needs to written. It mixes two separate 
> topics into a single paragraph:
>
> * Distributing HI processing - sounds like a nice research idea but 
> it's badly explained and lacks a reference. I'd suggest removing.
> Btw, the best reference for HIP-based process migration with 
> delegation is this:
>
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Miika Komu <[email-masked]>
Date: Sun, 21 Oct 2012 18:21:33 +0300

Hi,

> Here's the first batch of comments, I'll send the remaining ones later.

the second batch is here, I'll send the third and final later.

> 6.2. Protection against flooding attacks
>
> HIP includes an address check mechanism

(or return routability test)

> 7. HIP and ESP
>
 > The preferred way of implementing HIP is to use ESP to carry the
 > actual data traffic.  As of today, the only completely defined method
 > is to use ESP Encapsulated Security Payload (ESP) to carry the data
 > packets [I-D.ietf-hip-rfc5202-bis].  In the future, other ways of
 > transporting payload data may be developed, including ones that do
 > not use cryptographic protection.

Several comments:
* I would start the discussion by mentioning that the data plane 
encapsulation is not fixed and can be negotiated during the key exchange.
* ESP offers confidentiality protection or integrity protection, or 
both, and this is negotiable
* More precisely, the default ESP mode is BEET (tunnel mode semantics 
but transport mode syntax) to reduce the overhead of tunneling but 
transport and tunnel mode are negotiable by further extensions.
* Other encapsulations have been proposed: 
http://tools.ietf.org/html/draft-tschofenig-hiprg-hip-srtp-01

 > In practice, the HIP base exchange uses the cryptographic Host
 > Identifiers to set up a pair of ESP Security Associations (SAs) to
 > enable ESP in an end-to-end manner.  This is implemented in a way
 > that can span addressing realms.

How? Unless you want to explain, please just reference RFC 5770 or the 
draft:

http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal

Informal reference is fine.

 > First, IKE (and IKEv2) were not designed with middle boxes in mind.

Yes, historically, but also IKE has UDP encapsulation nowadays and 
products can even fake TCP/HTTP encapsulation. This sentence actually a 
bit ambiguous since IKE(v2) is actually *is* a middlebox (gateway) based 
solution (where as the end-to-end mode is the default for HIP). Please 
rephrase and I would also urge to stick to the state of art rather than 
history.

 > Originally, as HIP is designed for host usage, not for gateways or so
 > called Bump-in-the-Wire (BITW) implementations, only ESP transport
 > mode is supported.

Again, let's just focus on the state of the art; you start the 
description with "originally" and never describe "presently". Also, the 
most popular mode is the BEET, not transport.

 > An ESP SA pair is indexed by the SPIs and the two
 > HITs (both HITs since a system can have more than one HIT).

Yes, internally for hosts, but externally on the wire it's just the SPI 
when BEET mode is applied. HITs are not included in the packet.

 > Thus, real-world conditions
 > like loss of a PPP connection and its re-establishment or a mobile
 > handover will not require a HIP negotiation or disruption of
 > transport services [Bel1998].

Yet another historical reference. Bel1998 points to a slide set which is 
not really the best type of reference you can have. I would suggest 
omitting the reference since it's rather unimportant.

> 8. HIP and MAC Security

Does this count as MAC-based security scheme:

http://tools.ietf.org/html/draft-henderson-hip-vpls

> 9. HIP and NATs
 > This may happen, ..

This may occur,

 > For a HIP-based flow, a HIP-aware NAT or NAT-PT system tracks the
 > mapping of HITs, and the corresponding ESP SPIs, to an IP address.
 > The NAT system has to learn mappings both from HITs and from SPIs to
 > IP addresses.  Many HITs (and SPIs) can map to a single IP address on
 > a NAT, simplifying connections on address poor NAT interfaces.  The
 > NAT can gain much of its knowledge from the HIP packets themselves;
 > however, some NAT configuration may be necessary.

You're missing a reference:

http://dl.acm.org/citation.cfm?id=1128500

Also, you're giving an impression that HIP-aware NATs are typically used 
but this is not really the case. As a concrete way to improve the text, 
please start with the RFC5770 reference and only then describe the above 
mentioned SPINAT draft.

Regarding to RFC5770, I would suggest to mention that also Teredo (RFC 
4380) has been successfully experimented with HIP:

http://dl.acm.org/citation.cfm?id=1719793

In a nutshell, Teredo has more infrastructure but some additional 
overhead naturally results from additional tunneling.

 > HIP provides for 'Distributed NAT', and uses the HIT or the
 > LSI as a placeholder for embedded IP addresses.

Suggestion:

HIP provides for 'Distributed NAT' operating between network and upper 
layers, and uses the HIT or the LSI as a placeholder for embedded IP 
addresses. For this reason, HIP is able to support communications 
between an IPv4 and IPv6-based application.

 > An experimental HIP and NAT traversal is defined in [RFC5770].

Or...

http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal

?

> 9.1. HIP and Upper-layer checksums
>  ..

> 10. Multicast

The discussion is really void without any references:

http://dl.acm.org/citation.cfm?id=277744
http://dl.acm.org/citation.cfm?id=2006035
http://dl.acm.org/citation.cfm?id=2006035

> 11. HIP policies
> ..
 > Opportunistic mode (where the initator starts a HIP exchange without
 > prior knowledge of the responder's HI) presents a policy tradeoff.

the most detailed reference for this is:

http://dl.acm.org/citation.cfm?id=1700740

But feel free to reference also the experiment report:

http://tools.ietf.org/html/rfc6538#section-2.3.2

 > It provides some security benefits but may be subject to MITM.

At the expense of being subject to MITM attacks, the opportunistic mode 
allows the initiator learn the the identity of the responder during 
communications rather than from an external directory.

A good reference for opportunistic mode is:

V. Pham and T. Aura. Security Analysis of Leap-of-Faith Protocols. In
Seventh ICST International Conference on Security and Privacy for Com-
munication Networks, Sept. 2011.

> 12. Benefits of HIP

Please add a section for drawbacks:

* Additional management complexity by additional indirection layer and 
namespace
* Any tunneling mechanism causes some extra latency and bandwidth 
limitations for the data plane
* Referrals (which are already a problem due to NATs)

 > In the beginning, the network layer protocol (i.e., IP) had the
 > following four "classic" invariants:

What's your reference for the classic invariants? I suggest also 
switching to numbered bullets when listing them because you then later 
reference them by number.

 > IPv6 is an attempt to reinstate the first invariant.

What about NAT64?

 > Few systems on the Internet have DNS names that are meaningful.

Few client-side systems...

 > Although each namespace can be stretched (IP
 > with v6, DNS with KEY records), neither can adequately provide for
 > host authentication or act as a separation between internetworking
 > and transport layers.

URIs and URLs also extend the DNS namespace and are more common than KEY 
records.

 > The Host Identity (HI) namespace fills an important gap between the
 > IP and DNS namespaces.  An interesting thing about the HI is that it
 > actually allows one to give up all but the 3rd network-layer
 > invariant.  That is to say, as long as the source and destination
 > addresses in the network-layer protocol are reversible, then things
 > work ok because HIP takes care of host identification, and
 > reversibility allows one to get a packet back to one's partner host.
 > You do not care if the network-layer address changes in transit
 > (mutable) and you don't care what network-layer address the partner
 > is using (non-omniscient).

Actually, even the third invariant is lost due to NATs that involve the 
transport layer ports, but HIP can be used even in such a case.

The invariants are not "given up", they just shifted to the HIP layer 
for proper handling.

> 12.1. HIP's answers to NSRG questions
>
 > 1.  How would a stack name improve the overall functionality of the
 >     Internet?
 >
 >     HIP decouples the internetworking layer from the transport
 >     layer, allowing each to evolve separately.  The decoupling
 >     makes end-host mobility and multi-homing easier, also across
 >     IPv4 and IPv6 networks.  HIs make network renumbering easier,
 >     and they also make process migration and clustered servers
 >     easier to implement.  Furthermore, being cryptographic in
 >     nature, they provide the basis for solving the security
 >     problems related to end-host mobility and multi-homing.

You're missing IPv6 interoperability at the *application* layer.

 > 3.  What is its lifetime?
 >
 >     HIP provides both stable and temporary Host Identifiers.
 >     Stable HIs are typically long lived, with a lifetime of years
 >     or more.  The lifetime of temporary HIs depends on how long
 >     the upper-layer connections and applications need them, and
 >     can range from a few seconds to years.

Advancements in crypto analysis may also reduce the lifetime of the 
Identifiers because they are bound to cryptographic algorithms.

 > 4.  Where does it live in the stack?
 >
 >     The HIs live between the transport and internetworking layers.

...but are referenced by the application and transport layers.

 > 6.  What administrative infrastructure is needed to support it?
 >
 >     In some environments, it is possible to use HIP
 >     opportunistically, without any infrastructure.

again, the most detailed reference for this is:

http://dl.acm.org/citation.cfm?id=1700740

But feel free to reference also the experiment report:

http://tools.ietf.org/html/rfc6538#section-2.3.2

 >     However, to
 >     gain full benefit from HIP, the HIs must be stored in the DNS
 >     or a PKI, and a new rendezvous mechanism is needed
 >     [I-D.ietf-hip-rfc5205-bis].

LDAP (RFC4510) is missing, this has been used successfully.

 > 8.  What additional security benefits would a new naming scheme
 >     offer?
 >
 >     HIP reduces dependency on IP addresses, making the so called
 >     address ownership [Nik2001] problems easier to solve.  In
 >     practice, HIP provides security for end-host mobility and
 >     multi-homing.  Furthermore, since HIP Host Identifiers are
 >     public keys, standard public key certificate infrastructures
 >     can be applied on the top of HIP.

You're missing a reference to RFC6253.

 > 9.  What would the resolution mechanisms be, or what characteristics
 >     of a resolution mechanisms would be required?
 >
 >     For most purposes, an approach where DNS names are resolved
 >     simultaneously to HIs and IP addresses is sufficient.

Typically, a locally installed DNS proxy has been deployed at the 
client-side host to support this for legacy applications.

 >     However, if it becomes necessary to resolve HIs into IP
 >     addresses or back to DNS names, a flat resolution
 >     infrastructure is needed.  Such an infrastructure could be
 >     based on the ideas of Distributed Hash Tables, but would
 >     require significant new development and deployment.

Missing a DHT reference to RFC 6537.

Actually, the ORCHID prefix for HIP could be delegated to an 
organization, and look ups distributed within the servers of the 
organization. DHT is not the only solution, we can stick to DNS:

http://tools.ietf.org/html/draft-ponomarev-hip-hit2ip-00

---

From: Miika Komu <[email-masked]>
Date: Thu, 25 Oct 2012 21:09:29 +0300

Hi,

> the second batch is here, I'll send the third and final later.

the third and final batch is now here. Sorry for the delay.

> 14. Security considerations
> ..
> There are more details on this process in the Host Identity Protocol.

I think we're pretty much done with the details.

> HIP optionally supports opportunistic negotiation.  That is, if a
> host receives a start of transport without a HIP negotiation, it can
> attempt to force a HIP exchange before accepting the connection.
> This has the potential for DoS attacks against both hosts.  If the
> method to force the start of HIP is expensive on either host, the
> attacker need only spoof a TCP SYN.  This would put both systems into
> the expensive operations.  HIP avoids this attack by having the
> responder send a simple HIP packet that it can pre-build.  Since this
> packet is fixed and easily replayed, the initiator only reacts to it
> if it has just started a connection to the responder.

send a simple HIP packet -> send a simple R1 packe

I think this text tries to describe a SHIM6-like upgrade feature that is 
poorly defined by any of the RFCs for HIP. The description is difficult 
to understand (for instance, "opportunistic" can be confused with 
opportunistic mode) and a bit too research oriented for this document.

> If the responder's HI is
> retrieved from a signed DNS zone or secured by some other means, the
> initiator can use this to authenticate the signed HIP packets.

secure -> securely obtained

> The need to support multiple hashes for generating the HIT from the
> HI affords the MitM a potentially powerful downgrade attack due to
> the a-priori need of the HIT in the HIP base exchange.

...MitM to *mount* a...

> However, since this only
> happens in an attack scenario and since the attack can be handled (so
> it is not interesting to mount anymore), we assume the additional
> messages are not a problem at all.

happens -> occurs

> However, since this only
> happens in an attack scenario and since the attack can be handled (so
> it is not interesting to mount anymore), we assume the additional
> messages are not a problem at all.

..the *potentially* additional..

.. are not a *security* problem at all..

> This might seem to make it
> easier for an attacker, but ESP with replay protection is already as
> well protected as possible, and the removal of the IP address as a
> check should not increase the exposure of ESP to DoS attacks.

make it easier for an attacker -> make attacking easier

> Since not all hosts will ever support HIP, ICMPv4 'Destination
> Unreachable, Protocol Unreachable' and ICMPv6 'Parameter Problem,
> Unrecognized Next Header' messages are to be expected and present a
> DoS attack.  Against an initiator, the attack would look like the
> responder does not support HIP, but shortly after receiving the ICMP
> message, the initiator would receive a valid HIP packet.  Thus, to
> protect against this attack, an initiator should not react to an ICMP
> message until a reasonable time has passed, allowing it to get the
> real responder's HIP packet.  A similar attack against the responder
> is more involved.

I would clarify that the attack scenario is MitM here.

..get the real.. -> ..receive the real..

> A HIP packet is
> not used because it would either have to have unique content, and
> thus difficult to generate, resulting in yet another DoS attack, or
> just as spoofable as the ICMP message.

Suggest rewriting the beginning to avoid passive voice:

In this scenario, the attacker would not use a HIP control packet
because ...

Why would it create yet another DoS attack? Are mixing the R1 counter to 
the discussion here (I suggest not doing this).

> Like in the previous case,
> the defense against this attack is for the initiator to wait a
> reasonable time period to get a valid HIP packet.

Like -> Similarly as
get -> receive

If one does not
> come, then the initiator has to assume that the ICMP message is
> valid.

come -> arrive or appear

Since this is the only point in the HIP base exchange where
> this ICMP message is appropriate, it can be ignored at any other
> point in the exchange.

this -> an

> 14.1. HITs used in ACLs
 >
 > It is expected that HITs will be used in ACLs.

(they have already been used for such purposes)

"At end-hosts, HITs can be used in IP-based access control lists at the 
application and network layers".

 > Future firewalls can use HITs to control egress and ingress to
 > networks, with an assurance level difficult to achieve today.

"At middleboxes, HIP-aware firewalls [FW] can use HITs or public keys to 
control both ingress and egress access to networks or individual hosts, 
even in the presence of mobile devices because the HITs and public keys 
are topologically independent".

[FW] Janne Lindqvist, Essi Vehmersalo, Miika Komu and Jukka Manner.
Enterprise Network Packet Filtering for Mobile Cryptographic Identi-
ties. International Journal of Handheld Computing Research (IJHCR),
Volume 1, Issue 1, pp. 79-94, ISSN 1947-9158, January 2010.

 > The signatures in HIP packets allow a capable firewall
 > to ensure that the HIP exchange is indeed happening between two known
 > hosts.

happening -> occurring

 > A potential of HITs in ACLs is their 'flatness' means they cannot be
 > aggregated and this could result in large table searches

"A potential drawback of HITs in ACLs is their 'flatness' means
they cannot be aggregated ,and this could potentially result in large 
table searches in HIP-aware firewalls. However, all hosts are treated as 
individuals in HIP, meaning that it is also easier to exclude individual 
hosts out simply by removing the corresponding HIT from the firewall ACL".

 > A host can keep track of all of its partners that might use its HIT
 > in an ACL by logging all remote HITs.  It should only be necessary to
 > log responder hosts.  With this information, the host can notify the
 > various hosts about the change to the HIT.  There has been no attempt
 > to develop a secure method to issue the HIT revocation notice.

untrue, you're missing an (informal) reference to here:

http://tools.ietf.org/html/draft-irtf-hiprg-revocation-05

 > HIP-aware NATs, however, are transparent to the HIP aware systems by
 > design.  Thus, the host may find it difficult to notify any NAT that
 > is using a HIT in an ACL.  Since most systems will know of the NATs
 > for their network, there should be a process by which they can notify
 > these NATs of the change of the HIT.  This is mandatory for systems
 > that function as responders behind a NAT.  In a similar vein, if a
 > host is notified of a change in a HIT of an initiator, it should
 > notify its NAT of the change.  In this manner, NATs will get updated
 > with the HIT change.

NAT is a middlebox that does address translation. It should not be 
concerned with access control, besides that they typically drop inbound 
data flows due to absence of mappings. I think you should be rather 
talking about passive, on-path HIP-aware firewalls  such as described in 
[FW], or this text should be removed.

> 14.2. Alternative HI considerations

 > The definition of the Host Identifier states that the HI need not be
 > a public key.  It implies that the HI could be any value; for example
 > a FQDN.  This document does not describe how to support such a non-
 > cryptographic HI.  A non-cryptographic HI would still offer the
 > services of the HIT or LSI for NAT traversal.  It would be possible
 > to carry HITs in HIP packets that had neither privacy nor
 > authentication.

RFID version of HIP could maybe cited (as informational) as an example 
of such a compromise?

http://tools.ietf.org/html/draft-irtf-hiprg-rfid-06

 > Since such a mode would offer so little additional
 > functionality for so much addition to the IP kernel, it has not been
 > defined.  Given how little public key cryptography HIP requires, HIP
 > should only be implemented using public key Host Identities.

I suggest rephrasing the last sentence because the cryptography may be 
just too much some constrained devices.

> 15. IANA considerations

 > Finally,
 > Lars Eggert, Spencer Dawkins and Dave Crocker provided valuable input
 > during the final stages of publication, most of which was
 > incorporated but some of which the authors decided to ignore in order
 > to get this document published in the first place.

What were the issues?

> 16. Acknowledgments

Please add Aalto University, University of Helsinki and RWTH Aachen.

> 17.2. Informative references

Consider adding the following reference, for example, in the 
introduction of the draft if seem fit:

P. Nikander, A. Gurtov, T. Henderson, Host Identity Protocol (HIP): 
Connectivity, Mobility, Multi-homing, Security, and Privacy over IPv4 
and IPv6 networks, IEEE Communications Surveys and Tutorials, 12 (2), 2010.

http://www.cs.helsinki.fi/u/gurtov/papers/hip_survey.pdf