Crypto-based host identifiers

[<mbagnulo@ing.uc3m.es>]

I have some questions about this psposal:

Why do you set the group bit to "group"? i mean, it is not a multi-cast 
address, right?

I still don't understand the need for a new public registry.
You also mention the need to use the DNS, wouldn't be enough to use 
only the DNS?
If i understnd correctly, you need the new registry, because in order 
to avoid collisions, right?
But a collision means that someone else has the private key that 
matches the hash of 
someone else's public key. This situation by itself it is a 
vulnerability 
to the solution isn't it?, since if it has such a private key it can 
impersonate 
the original holder, right?
So, in order to overcome this, you propose the usage of the DNS, is 
this correct?
My question is then, why don't you use only the DNS and avoid the new 
registry?
The new public registry may not be so simple than just a list of 
allocted site prefixes, 
i mean, you have to protect from several type of attacks, for instance 
depletion attacks, 
where a malicious part starts registering site prefixes in a bulk 
fashion.
You can address this charging a fee, but as you see things get more 
complicated.

Another question, how do you generate the host part of the CBHI? i 
can't find it in 
the document. I guess it would be a hash of its own public key.

My question then is why do you want a site key and a host key? i don't 
see any benefit of 
its usage in the current document. Why don't you just use a host key, 
just a regular CGA?
Another issue related to this, what is the benefit of using 64 bits 
long identifiers. I mean,
TCP and other ULP use 128 bit long identifiers so you will have to 
complete the 128 bits or 
modify the ULP. I guess that you will complete the 128 bits, so why 
don't you just use them all
to contain a key. I guess that the benefit would be that you can carry 
both the locator and 
the identifier in the address field of the IPv6 packet and that you can 
obtain them in a regular
DNS AAAA query, but i don't know how important is this. First you don't 
really need to carry
the identifier in all packets, once that the context is set up, you 
just carry the locators 
and things should work, i guess. Second, storing the 128 bit long in 
the DNS as a new RR 
wouldn't be complex, and it could be used to distinguish host that 
support the new mechanism 
form those who don't. 
Besides, using 64 bit only for the id really introduces some 
limitations as the ones mentioned 
above, so i still don't see clearly why this is a good option.

Another issue is related to section 6 turning site id into prefixes.
Why don't you use a Hinden Haberman local scope address prefix insted 
of asking for 
a new address range for this usage?

About the addres authentication section.
I don't understand some parts of the procedure, for instance in step 7 
(the 7th -) you say that
B also looks up B's site identifier in the DNS, shouldn' B already know 
its own site id?
or is that B looks A's site identifier in the DNS? the same question 
about the next sub-step (*)
about B checking B's public keys.

As a final observation, this proposal uses public key crypto and DNS 
querys to provide security, 
(and if i understand correctly, it imposes a DNS query to the target 
node (B) which is not 
currently needed in a communication i.e. it is like imposing that A 
performs a DNS query, 
which would mean that when A performs the regular AAAA query it would 
also obtain additioanl info, 
such as a new RR), besides it also requires a new public registry.
So in brief this seems lika a pretty expensive mechanism to me, 
couldn't you provide some similar 
level of security using just one of them, for instance just public key 
crypto like HIP? 
In other words, what are the benefits obtaine after incurring in all 
these additional costs? 


Thanks, marcelo