Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt

From: Alberto Garcia <[email-masked]>
Date: Wed, 14 Mar 2007 13:41:35 +0200

Dear colleagues and friends,

Since I'm new in this mailing list I'd like to introduce myself. I'm Alberto
García and I recently started working at HIIT. I just reviewed the draft:
http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-00.txt

In my opinion, the draft is well written and the issue covered is appropriate,
therefore it is mature to proceed forward. However, I could give some minor
comments or suggestions:

1) In principle, it looks sensible to give the complete names in the first
instance of the acronyms, even when we are already familiar with them. E.g.: in
"1. Introduction" could be "Application Programming Interface (API)" or "Host
Identity Tag (HIT)".

2) In "2. Terminology", I would suggest the introduction of:
"Host Identifier (HI): A public key of an asymmetric key pair used as a name for
a Host Identity. More details are available in [1]."
Then, the next item could be:
"Host Identity Tag (HIT): A 128-bit quantity formed by the hash of a HI.  More
details are available in [1]."

3) In general, there is some ambiguity in the usage of the terms host identity,
host identifier and host identity tag. Some examples:
3.1.  Using IP addresses in applications
[...] The mapping of IP address to host identity may be implemented [...]
s/host identity/HI
[...] If the responder has host identities registered in the forward DNS
zone[...]
s/host identities/HIs
3.2.  Using DNS
[...] If host identities are bound to domain names [...]
s/host identities/HIs

4)In "3.1.  Using IP addresses in applications"
[...]  They have weaker security properties than the approaches outlined in
Section 3.2 and Section 3.3, however, because the binding between host identity
and address is weak and not visible to the application or user. [...]
s/however, because /since

[...]   In fact, the semantics of the application's "connect(ip)" call  [...]
s/application's "connect(ip)"/command "connect(ip)"launch by the application

5)In "3.2.  Using DNS":
It seems strange the repetition of the same title just three paragraphs before. 
I could suggest "3.2. Returning HIs directly from the name resolution process",
or something similar.
[...] to return a Local Scope Identifier (LSI) or Host Identity Tag (HIT) rather
than an IP [...]
s/Local Scope Identifier (LSI) or Host Identity Tag (HIT)/LSI or HIT    -- as
they are defined in section 2.
[...] It may be possible for an LSI or HIT to be routable or resolvable, but
such a case may not have the level of security in the binding to host identity
that a HIT has with the host identity. [...]
This sentence is somehow confusing, please consider rewriting it.

6) In "3.3.  Connecting directly to a HIT"
[...] the use of IP addresses and and LSIs as local handles [...]
s/and and/and
[...] (else the initial connect() would fail), the problem may be instead if the
peer host supports HIP but is not able to perform HIT resolution for some
reason.[...]
s/connect()/"connect()"
s/may be instead if /may not be whether   -- or some other re-arrange

7) In "4.  Security Considerations"
[...] the system's security is comparable [...]
s/system's security/security of the system
[...] stored in the reverse MAP) and the [...]
s/MAP/DNS record
[...] Using the forward DNS to map a DNS name into an LSI[...]
s/DNS name/domain or host name
[...] the application makes a connect(HIT) system call [...]
s/connect(HIT)/"connect(HIT)"

8) In "6.  References", some references should be updated. Reference [4] needs
small changes according to the article I found in the Internet:

[4]     Salz, J., Snoeren, A., and Balakrishnan, H, "TESLA:  A
        Transparent, Extensible Session-Layer Architecture for End-to-
        end Network Services",  Proceedings of the 4th USENIX Symposium on
        Internet Technologies and Systems (USITS), pages 211-224, March 2003.

I hope these notes are helpful in some way. In my opinion, the draft is fine to
proceed.

BR,

Alberto García

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Alberto Garcia <[email-masked]>
Date: Thu, 15 Mar 2007 16:04:41 +0200

Hello again Tom,

I'm glad that you're interested in my comments. So now I'd like to discuss some
of your responses:

> > host identifier and host identity tag.
> I do not think there is ambiguity here, but perhaps inconsistency in use of
> acronym?  I am not sure all of these need to be compacted, since it seems to
> read better to me to spell out "host identities" sometimes.

I think I didn't explain it correctly. Actually "ambiguity" was not the right
word to use here. What I meant is that in http://www.ietf.org/rfc/rfc4423.txt ,
page 5, it is defined:
"Host Identity: An abstract concept assigned to a 'computing platform'.  See
'Host Identifier', below."
"Host Identifier: A public key used as a name for a Host Identity."
In my opinion we should avoid using Host Identity for something else than the
host itself, since it is "an abstract concept". Then I suggest to use the term
Host Identifier or HI -previously defined in section 2-  when talking about
mapping IP addresses into HI, and things related to DNS.

> How about "Using DNS names in applications" to parallel 3.1's title?

How about in 3.1:  "Using DNS to map IPs to HIs"?
As you know, the difference between 3.1 and 3.2 is that:
- in 3.1: domain name -> IP address -> HI
- in 3.2: domain name -> HI
Symbol -> means mapping. I think this difference should be clearly stated in the
section titles.

> At this point in the text, LSI acronym has not yet been used.  I agree that
> HIT doesn't need to be spelled out here.

Actually LSI can be defined in section 2: "Local Scope Identifier (LSI): A 32-
or 128-bit quantity locally [...]".

> How about changing this paragraph:
>
> "   It may be possible for an LSI or HIT to be routable or resolvable,
>    but such a case may not have the level of security in the binding to
>    host identity that a HIT has with the host identity.  For example, a
>    special IP address that has some location invariance is the
>    identifier-address discussed in [6].  In general, LSIs and HITs
>    considered to date for HIP have been non-routable."
>
> to this:
>
> "  It may be possible for an LSI or HIT to be routable or resolvable,
>    either directly or on an overlay.  For example, a
>    special IP address that has some location invariance is the
>    identifier-address discussed in [6].  A term other than LSI may be
>    needed for these routable identifiers, since they would
>    no longer be locally scoped.  When using DNS, returning a routable
>    identifier would avoid the aforementioned problems with referrals.
>    However, the cost of routability may be that the hash binding
>    between the routable identifier and the host identity would be
>    weakened, since more bits may be allocated to the hierarchy."

Yes, much clearer now. BTW, here, the term "host identity" is applicable in my
opinion.

> OK
> How about:
> s/may be instead if/may otherwise be that

For me it sounds better my suggestion, however yours is fine too; choose the one
you prefer.

> s/DNS name/domain name

OK

The draft is quite fine already and I'm glad I can help a little.

BR,

Alberto García