- Tom
Detailed comments below:
Section 1 (Introduction)
There is exactly one Host Identifier for each Host Identity.
This document does not talk about replacing Host Identifiers over time; should
it? Also, couldn't multiple keys be associated with the same Identity
(computing stack)? I wonder whether this statement is too restrictive,
especially since one can imagine times in which keys are replaced and two Host
Identifiers may be active at the same time.
Section 2 (Terminology)
(Public key) Used as a publicly known identifier for cryptographic identity
authentication.
Does it need to be publicly known? See later "Unpublished Host Identifier" definition.
Suggest "(typically publicly known)" instead.
Section 3 (Background)
IP numbers
suggest "IP addresses" instead (many places in this section)
Section 4 (Host Identity namespace)
As will be specified in the Host Identity Protocol Base EXchange (BEX)
[RFC5201-bis] specification
Suggest instead: "As specified in the Host Identity Protocol [RFC5201-bis]
specification
Section 4.1 (Host Identifiers)
The actual Host Identities are never directly used in any Internet
protocols.
I believe that this should instead be Identifier (Identities are abstract).
Section 4.2 (Host Identity Hash)
It is possible to for the two Hosts in the HIP exchange to use different hashes.
Suggest "It is possible for the two hosts..."
Section 4.3 (Host Identity Tag)
s/perfers/prefers
Section 5 (New stack architecture)
As discussed above, the IP addresses can be seen to be a confounding of routing
direction vectors and interface names.
Is it routing direction vectors, or endpoint (or stack) names? Is "routing
direction vector" terminology used elsewhere; if so, suggest to add a reference, if
not, suggest to change to end-point names.
Section 7 (HIP and ESP)
As adding a new naming layer allows one to potentially add a new forwarding
layer (see Section 9, below), it is very important that the HIP provides
mechanisms for middlebox authentication.
Perhaps add reference to RFC 5207 here?
s/consistant/consistent
It should be noted that there are already BITW implementations.
Perhaps a clarification here: "It should be noted that there are already BITW
implementations of HIP providing virtual private network (VPN) services."
Section 10 (Multicast)
Since its inception, a few studies have looked at how HIP might affect
IP-layer or application-layer multicast.
IMO, this section should be expanded with some more commentary about how HIP
applies to multicast. In particular, how amenable are multicast key management
protocols and security associations to being able to leverage HIP? Would HITs
ever be put into source or destination address fields of multicast datagrams?
Section 13 (Changes from RFC 4423)
This section is not yet completed. Either complete or delete.
Section 14 (Security considerations)
There are more details on this process in the Host Identity Protocol under
development.
Suggest to strike "under development" since the HIP protocol has now been
developed.
There has been no attempt to develop a secure method to issue the HIT
revocation notice.
This is no longer true due to draft-irtf-hiprg-revocation-05; suggest to
rephrase.
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
