Re: [Hipsec] Feedback for 4423bis

[Miika Komu <[e-mail]>]

Hi,

On 10/10/2012 10:05 PM, Sasu Tarkoma wrote:
> 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.

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
> Host Identity over several physical computers, HIP provides for
> 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!