Subject: [Hipsec] Comments on architecture draft

From: [email-masked] (Petri Jokela)
Date: Tue Oct 14 07:37:01 2003

Hi,

Some comments related to the architecture draft follows. They are more
or less clarifications to the text.

My text proposals may be awful, but I hope that they describe what I had
in mind while writing those comments.

/petri

Section 3
=========
Paragraph 1
last sentence

DNSSEC is a "SHOULD" implement authenticator for the Host Identity
namespace.
=>
The Host Identity namespace authentication SHOULD be implemented with
DNSSEC.

Paragraph 3
first sentence

Too strong statement.

... a public key of a 'public key' pair makes the best Host Identifiers.
=>
... a public key of a 'public key' pair makes the best Host Identifiers
from the current selection of possible identifiers.

Not maybe with those words, but I hope it clarifies what I
mean. However, maybe the rest of the paragraph makes this clarification
already.

Section 3.1
===========
Paragraph 2
last sentence

"It the private key..." => "If the private key..."
 ^^
 
Last paragraph
LSI part

The advantage of the size of the LSI mentioned before there is any
reference to the length of the LSI. This may be ok, but it just felt
funny because the advantage was first mentioned before any knowledge
about the size.

"The advantage of this 32-bit long LSI over the HIT is its size; its
disadvantage is its local scope."

Section 3.3
===========
first paragraph
Last sentence

".. presents a consistent format to the protocol..."
=>
".. presents a consistent format of the identity to the protocol
independent of the underlying technology."

Section 5.1
===========

first paragraph
second sentence

"... the mobile node is to start..." ->

reformat the sentence (at least I read that sentence constantly in
a wrong way)

Section 6.
==========

paragraph 3

NAT: Tracking between HIT (or SPI) and the IP address. 

If the NAT can allocate an external address for each of the nodes inside
(IPv6 ok, IPv4, well, rarely), the NAT does require mapping only between
the internal and external addresses. SPI nor HIT is not needed.

I would suggest to make the paragraph less restrictive in wording.

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]

---

From: [email-masked] (Pekka Nikander)
Date: Thu Oct 16 13:48:01 2003

Petri,

> or less clarifications to the text.

Thanks for these comments.  Since these are minor one and haven't
induced any discussion, I will simply add a new issue #5 for
these, and address them in this message.  I hope we can close
this pretty soon.

> Section 3, Paragraph 1, last sentence
> 

Good catch.  In fact, there is no use to use RFC2119 language
in this kind of an architecture document.  That was the last
instance of RFC2119 language; thanks for pointing it out.

I changed the text that it now reads as follows:

       It is expected that the Host Identifier namespace will
       initially be authenticated with DNSSEC and that all
       implementations will support DNSSEC as a minimal baseline.

Ok?

> Paragraph 3, first sentence
> 
> Too strong statement.
> 

Well, this is certainly something that we could debate, and
indeed should if we had a working group however.  Fortunately :-),
I am planning to submit the document to the IESG before a WG
is formed, and therefore I revised the text so that it now
reads as follows:

       In theory, any name that can claim to be 'statistically globally
       unique' may serve as a Host Identifier.  However, in the
       authors' opinion, a public key of a 'public key pair' makes the
       best Host Identifiers.

Do you have an opinion on this?

> Section 3.1, Paragraph 2, last sentence
> 

Thanks, fixed.

> Last paragraph, LSI part

I moved the last sentence to the HIP section, but didn't change it.  Ok?

> Section 3.3, first paragraph, Last sentence
> 

Changed to

         Secondly, it presents the identity in a consistent format to
         the protocol independent of the whatever underlying
         technology is used.

Ok?

> Section 5.1, first paragraph, second sentence
> 

Changed to

         In order to start the HIP exchange, the initiator
         node has to know how to reach the mobile node.

Ok?

> Section 6, paragraph 3

Well, what you say is obvious to anyone who knows NATs.  On the
other hand, the ability to track HITs and SPIs is not.  Furthermore,
the paragraph ony talks about what a NAT can do (based on the protoco
design), not really on what it should or must do (by protocol design).
Hence, I don't see any real need to change the paragraph.  Was there
something particular that stroke you?

--Pekka

---

From: [email-masked] (Petri Jokela)
Date: Mon Oct 20 01:50:04 2003

On Thu, 16 Oct 2003, Pekka Nikander wrote:

Hi,

I think that the changes you propose are ok. 

> something particular that stroke you?

I read it like "You have to use SPI for making the address translation.".
For some reason, it looks now different :-). I suppose the text is ok.

/petri

---

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 20 02:19:01 2003

>>>NAT: Tracking between HIT (or SPI) and the IP address. 
...
> For some reason, it looks now different :-). I suppose the text is ok.

Ok.  I have now marked the issue closed.

--Pekka