Re: [Hipsec] Feedback for 4423bis

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:
> 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
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
>