Subject: [Hipsec] Addressing WG LC comments on draft-ietf-hip-arch

From: Pekka Nikander <[email-masked]>
Date: Thu, 16 Dec 2004 14:00:05 +0200

Lars,

I have now tried to address your WG LC comments (the only ones!)
on draft-ietf-hip-arch-00.txt.

http://honor.trusecure.com/pipermail/hipsec/2004-October/001069.html
http://honor.trusecure.com/pipermail/hipsec/2004-October/001074.html

The result is now available at

   http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec16.txt
   http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec16.html
   http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec16.xml

Diffs to the previous version are available at

http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec16- 
chbar.txt
    
http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec16- 
diff.html

Would you please check that I have addressed your comments to
your satisfaction.

Once we have your comments addressed, I think that the draft is ready
to be shipped to the IESG for consideration to be published as  
Informational.

--Pekka

_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Lars Eggert <[email-masked]>
Date: Mon, 20 Dec 2004 18:54:29 +0100

> Would you please check that I have addressed your comments to

Generally looks good, some other very minor issues below.

> Abstract
...
>    protocols are defined.  The memo describes the thinking of the
>    authors as of Fall 2003.

Fall 2004? (Here and at several other places later.)

> 2.  Introduction
...
>    The proposed Host Identity namespace fills an important gap between
>    the IP and DNS namespaces.  The Host Identity namespace consists of
>    Host Identifiers (HI).  A Host Identifier is cryptographic in its
>    nature; it is the public key of an asymmetric key-pair.  Each host
>    will have at least one Host Identity, but it will typically have more
>    than one.  Each host identity uniquely identifies a single host,
>    i.e., no two hosts have the same host identity.  The Host Identity,
>    and the corresponding Host Identifier, can either be public (e.g.
>    published in the DNS), or unpublished.  Client systems will tend to
>    have both public and unpublished Identities.

"Host Identity" is not capitalized twice - oversight?

>    When HIP is used, the actual payload traffic between two HIP hosts is
>    typically, but not necessarily, protected with IPsec.  The Host
>    Identities are used to create the needed IPsec Security Associations
>    (SA) and to authenticate the hosts.  When IPsec is used, the actual

s/(SA) and to authenticate/(SAs) to authenticate/

>    payload IP packets do not differ in any way from standard IPsec
>    protected IP packets.

What do you mean by "payload IP packets?"

Maybe rephrase as: "IPsec-protected HIP payload packets do not differ in 
any way from IPsec-protected IP packets."

>    | Public key   | The public key from an asymmetric cryptographic    |
...
>    | Private key  | The private or secret key from an asymmetric       |

s/from an/of an/

>    |              |                                                    |
>    | Public key   | An asymmetric cryptographic key pair consisting of |
>    | pair         | a public and private keys. For example,            |

s/of a public/of public/

>    | Unpublished  | A Host Identifier that is not placed in any public |
>    | Host         | directory, and the corresponding Host Identity.    |
>    | Identifier   | Unpublished Host Identities are typically short    |
>    | and Identity | living in nature, being often replaced and         |
>    |              | possibly used just once.                           |

s/short living/short lived/

> 4.  Background
...
>    infrastructure, and services (applications).  The Internet exists to
>    service two principal components: people and robotic services

s/service/serve/

I would also not capitalize "Domain Names" in the remainder of section 4.

>    IP numbers name networking interfaces, and typically only when the
>    interface is connected to the network.  Originally IP numbers had

s/Originally /Originally, /

>    long-term significance.  Today, the vast number of interfaces use
>    ephemeral and/or non-unique IP numbers.  That is, every time an

s/every time/everytime/

> 4.1  A desire for a namespace for computing platforms
...
>    o  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 TCB).  This may require

TCB? TCP Control Block? (Again later in the section.)

>       changes to the current APIs.  In the long run, it is probable that
>       some new APIs are needed.

s/probable/possible/

>    In this document, a new namespace approaching these ideas is called
>    the Host Identity namespace.  Using Host Identities requires its own
>    protocol layer, the Host Identity Protocol, between the
>    internetworking and transport layers.  The names are based on
>    public-key cryptography to supply authentication services.  Properly
>    designed, it can deliver all of the above stated requirements.

First sentence is clunky, maybe: "This document introduces a new 
namespace to support these ideas. It is called the Host Identity namespace."

s/above stated requirements/above requirements/

> 5.  Host Identity namespace
...
>    'well known', some unpublished or 'anonymous'.  A system may self
>    assert its own identity, or may use a third-party authenticator like
>    DNSSEC, PGP, or X.509 to 'notarize' the identity assertion.  It is
>    expected that the Host Identifiers will initially be authenticated
>    with DNSSEC and that all implementations will support DNSSEC as a
>    minimal baseline.

s/self assert/self-assert/

Do we really want the last sentence about DNSSEC in there? (And if we 
do, we shoud cite it.)

> 5.1  Host Identifiers
> 
>    Host Identity adds two main features to Internet protocols.  The

s/Host Identity/The Host Identity Protocol/

>    authentication.  Because the Host Identifier is a public key, this
>    key can be used to authenticate security protocols like IPsec.

s/can be used to authenticate/can be used for authentication in/

> 5.2  Storing Host Identifiers in DNS
> 
>    The public Host Identifiers should be stored in DNS; the unpublished
>    Host Identifiers should not be stored anywhere (besides the
>    communicating hosts themselves).  The (public) HI is stored in a new
>    RR type, to be defined.  This RR type is likely to be quite similar
>    to the IPSECKEY RR [5].

I guess we can't cite Julien's DNS ID in an RFC to-be?

> 5.3  Host Identity Tag (HIT)
> 
>    A Host Identity Tag is an 128-bit representation for a Host Identity.

s/an 128-bit/a 128-bit/
s/for a/of a/

>    the Host Identifier in protocols.  Firstly, its fixed length makes
>    for easier protocol coding and also better manages the packet size
>    cost of this technology.  Secondly, it presents the identity in a

Clunky. Maybe: "First, a fixed-length hash simplifies protocol 
implementation and reduces per-packet overhead."

>    universe as long as it is being used.  In the extremely rare case
>    that a single HIT happens to map to more than one Host Identity, the

s/that a single HIT happens to map/of a single HIT mapping/

>    Host Identifiers (public keys) will make the final difference.  If

s/will make the final difference/differentiate between the two/

> 5.4  Local Scope Identifier (LSI)
...
>    Examples of how LSIs can be used include: as the address in a FTP

s/a FTP/an FTP/

> 6.  New stack architecture
> 
>    One way to characterize Host Identity is to compare the proposed new

s/Host Identity/the Host Identity Protocol/

> 6.1  Transport associations and end-points
> 
>    Architecturally, HIP provides for a different binding of

s/for a/a/

> 7.  End-host mobility and multi-homing
...
>    reassignments, or a NAT device remapping its translation.  Likewise,
>    a system is considered multi-homed if it has more than one globally
>    routable IP address at the same time.  HIP links IP addresses

Why "globally routable?" Can't I be multi-homed through two NATs? Maybe 
say "connects to the Internet via multiple different interfaces?"

>    changes are rather straightforward.  The peer of the mobile node can
>    just accept a HIP or an integrity protected IPsec packet from any
>    address and totally ignore the source address.  However, as discussed

s/totally//

> 7.1  Rendezvous mechanism
> 
>    Making a contact to a mobile node is slightly more involved.  In
>    order to start the HIP exchange, the initiator node has to know how
>    to reach the mobile node.  Although infrequently moving HIP nodes
>    could use Dynamic DNS to update their reachability information in the

cite Dynamic DNS

> 7.2  Protection against flooding attacks
> 
>    distributed flooding attack an attacker opens high volume HIP

s/high volume/high-bandwidth/

> 8.  HIP and IPsec
...
>    active transport is also maintained.  Thus, real world conditions

s/real world/real-world/

> 10.  Multicast
> 
>    Back in the fall of 2003, there was little if any concrete thoughts
>    about how HIP might affect IP-layer or application-layer multi-cast.

s/multi-cast/multicast/

> 12.  Benefits of HIP
...
>    This is why many systems on the internet are not registered in the
>    DNS; they do not have services of interest to other Internet hosts.

s/internet/Internet/

>    IP and DNS namespaces.  An interesting thing about the HI is that it
>    actually allows one to give-up all but the 3rd network-layer

s/give-up/give up/

-- 
Lars Eggert                                     NEC Network Laboratories

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 21 Dec 2004 14:05:05 +0200

> "Host Identity" is not capitalized twice - oversight?

Bug, fixed.  Thanks.

> s/(SA) and to authenticate/(SAs) to authenticate/

Fixed.

> What do you mean by "payload IP packets?"

Packets that carry traffic, i.e., not signalling.  Pretty much using  
the standard meaning of the word, e.g., according to Merriam-Webster  
online, meaning 1:

http://www.m-w.com/cgi-bin/dictionary?payload%20

> Maybe rephrase as: "IPsec-protected HIP payload packets do not differ  
> in any way from IPsec-protected IP packets."

That would be definitely wrong, as "HIP payload" is confusing.  Do you  
mean packets that carry HIP signalling, i.e. payload from HIP point of  
view, or application payload?

I have to admit that I am puzzled here of why do you find the  
expression confusing.  The paragraph already before refers to "actual  
payload traffic", and you don't seem to have any problems with that.

> s/from an/of an/

Changed.  However, I can't tell which is better.

> s/of a public/of public/

Fixed.

> s/short living/short lived/

Fixed.

>>    service two principal components: people and robotic services

"service" is a transitive verb, in addition to a noun.
As this text originates from Bob, I'd rather not change.

> I would also not capitalize "Domain Names" in the remainder of section  

As this text originates from Bob, I'd rather not change.

> s/Originally /Originally, /

Fixed.

> s/every time/everytime/

M-W does not recognise "everytime", nor does my spell checker.

> TCB? TCP Control Block? (Again later in the section.)

Actually Transport Control Block, as it may also apply to UDP.
Now spelled out on first occurrence.

>>       some new APIs are needed.

I agree with Tom here.  It looked probable back then, and almost  
certain now.

> namespace to support these ideas. It is called the Host Identity  

I agree, but as it is part of Bob's writing style, I'd rather not touch.

> s/above stated requirements/above requirements/

I don't agree with that.  "requirements above" would be OK, but I don't  
know if it is any better.  Google finds some 4500 occurrences of "the  
above stated requirements", if that is of any indication.

> s/self assert/self-assert/

Fixed.

> Do we really want the last sentence about DNSSEC in there? (And if we  

I agree with Tom that we thought so back then.  Reference added.

> s/Host Identity/The Host Identity Protocol/

As this text originates from Bob, I'd rather not change.

> s/can be used to authenticate/can be used for authentication in/

Changed.

> I guess we can't cite Julien's DNS ID in an RFC to-be?

No, and that didn't exist back then.

> s/an 128-bit/a 128-bit/

Fixed.

> s/for a/of a/

Both seem to be proper English.  Didn't change.

> implementation and reduces per-packet overhead."

Part of Bob's style.  I'd rather not change.

> s/that a single HIT happens to map/of a single HIT mapping/

Fixed.

> s/will make the final difference/differentiate between the two/

I find the existing easier to understand, though admittedly less formal.
Not changed.

> s/a FTP/an FTP/

Fixed.

> s/Host Identity/the Host Identity Protocol/

See above.  NOt changed.

>>    Architecturally, HIP provides for a different binding of

In my opinion, it is "provides for".  HIP does not do it by itself,  
small changes are also required elsewhere.

> Why "globally routable?" Can't I be multi-homed through two NATs?  
> Maybe say "connects to the Internet via multiple different  
> interfaces?"

If you connect through two NATs, you do have two globally routable  
addresses, one at each NAT.  I'd rather not change.  Besides, the case  
of multi-homing through NATs is still not clear in detail, and  
certainly wasn't a year ago.

>>    address and totally ignore the source address.  However, as  

Fixed, though I don't understand exactly why.

> cite Dynamic DNS

Added reference to RFC 2136.

> s/high volume/high-bandwidth/

IMHO volume is more accurate here.

> s/real world/real-world/

Fixed.

> s/multi-cast/multicast/

Fixed.

> s/internet/Internet/

Fixed.

> s/give-up/give up/

Fixed.

Overall, thanks for your very thorough proof reading.
I hope we can converge on the remaining few points soon.

The new version is available at:

http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec21.txt
http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec21.html
http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec21.xml

Diffs to -01:

http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec21- 
chbar.txt
http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec21- 
diff.html

--Pekka

---

From: Lars Eggert <[email-masked]>
Date: Tue, 21 Dec 2004 13:22:39 +0100

> I hope we can converge on the remaining few points soon.

I think we are converged, it's up to you as editor to decide on 
editorial comments :-)

Some further comments below, but I don't feel strongly about any of them.

> view, or application payload?

No, I mean that it's a HIP-generated IPsec packet that carries 
application payload. (Same as you I think.) Anyway, minor point.

>> Maybe say "connects to the Internet via multiple different  interfaces?"
> 

The NATs do, but the heading says this is about end host multi-homing, 
and the end hosts don't have global addresses.

But since the memo describes a past understanding, that may be fine.

> Fixed, though I don't understand exactly why.

Slang. Everytime I read "totally" I hear it with an LA valley girl accent...

Lars

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 21 Dec 2004 14:30:18 +0200

> I think we are converged, it's up to you as editor to decide on 

Ok, fine.  I'll submit the draft and let the chairs to decide if it is 
ready for the IESG or if further clean ups are needed.

--Pekka