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!
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
