Subject: [Hipsec] WG LC on architecture draft

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 16 Oct 2004 10:49:42 +0300

Folks,

I would like to start the WGLC on the architecture draft. This WGLC will 
finish on November 15th. The draft will appear shortly in the archives. 
In the meantime, you can fetch it from:

http://hip.piuha.net/drafts/draft-ietf-hip-arch-00.txt

A few words on the scope of this WGLC. This draft was originally 
intended to be published before WG formation, but it has been delayed 
for a number of reasons.

As the draft states, the purpose of the document is to document the 
architectural reasoning as it was stated during the time of WG 
formation, and therefore the draft is informational or almost historical 
in nature. Hence, we ask people for clarifications, so that the content 
is understandable and easy to comprehend. However, asking for new 
argumentation (that did not exist back in fall 2003) or inclusion of new 
text may not be appropriate.

Please, send you comments to the authors and to the mailing list.

Thanks,

Gonzalo
HIP co-chair

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

---

From: Lars Eggert <[email-masked]>
Date: Tue, 19 Oct 2004 16:38:04 +0200

Gonzalo,

> http://hip.piuha.net/drafts/draft-ietf-hip-arch-00.txt
...
> text may not be appropriate.

what are we shooting for here, standards track or other?

Thanks,
Lars
-- 
Lars Eggert                                     NEC Network Laboratories

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 19 Oct 2004 22:32:45 +0300

> what are we shooting for here, standards track or other?

Informative, or if not even that is possible, Historical.

AFAIK, nothing from HIP WG is currently chartered for
Standards Track.  The base spec etc. are chartered for
Experimental, but with standards track quality; the reason
for Experimental being that we don't understand the
consequences of id/loc split.

--Pekka

---

From: Lars Eggert <[email-masked]>
Date: Wed, 20 Oct 2004 15:02:26 +0200

...
> Please, send you comments to the authors and to the mailing list.

I have some comments and some editing nits. I'll summarize the comments 
below, the attached diff has both them and the nits.

Section 2, 2nd paragraph: "A Host Identity is assigned to each host. 
Each host will have at least one Host Identity..." So does it get a 
single one, or at least one? I think the latter, and would just remove 
the first sentence.

Section 2, 2nd paragraph: "which can either be public (e.g. published in 
DNS), or unpublished." If one is "public", shouldn't we call the other 
kind "private" instead of "unpublished?"

Section 2, 4th paragraph: A sentence on why we didn't go with IKE may be 
useful.

Page 8: "Sometimes the names may contain a delegation component." 
Formatting is weird. Is this a new bullet or belongs to the previous one?

Section 8, last paragraph: Uses upper-case "MAY" without referring to 
RFC 2119. We should probably change all RFC 2119 terms to lower case for 
this document.

Section 9, third pararaph: "For a HIP-based flow, a HIP-aware NAT or 
NAT-PT system tracks the mapping of HITs and the corresponding IPsec 
SPIs to an IP address." Not sure what this sentence is supposed to mean.

All section headings: Use consistent capitalization througout the document.
-- 
Lars Eggert                                     NEC Network Laboratories
--- draft-ietf-hip-arch-00.txt	Wed Oct 20 15:00:26 2004
+++ draft-ietf-hip-arch-00-le.txt	Wed Oct 20 14:59:55 2004
@@ -40,15 +40,15 @@
 
 Copyright Notice
 
-   Copyright (C) The Internet Society (2004).
+   Copyright (C) The Internet Society (2004.)
 
 Abstract
 
    This memo describes a snapshot of the reasoning behind a proposed new
    namespace, the Host Identity namespace, and a new protocol layer, the
-   Host Identity Protocol, between the internetworking and transport
-   layers.  Herein are presented the basics of the current namespaces,
-   strengths and weaknesses, and how a new namespace will add
+   Host Identity Protocol, between the network and transport
+   layers.  It describes the Internet's current namespaces, their
+   strengths and weaknesses, and how the new Host Identity namespace integrates with them.

@@ -57,8 +57,7 @@
 Internet-Draft    Host Identity Protocol Architecture       October 2004

-   completeness to them.  The roles of this new namespace in the
-   protocols are defined.  The memo describes the thinking of the
+   The memo describes the thinking of the
    authors as of Fall 2003.
 
 Table of Contents
@@ -118,28 +117,27 @@
    The purpose of this memo is to provide a stable reference point in
    the development of the Host Identity Protocol architecture.  This
    memo describes the thinking of the authors as of Fall 2003; their
-   thinking may have evolved since then.  In occasions, this memo may be
+   thinking may have changed since then.  Occasionally, this memo may be
    confusing or self-contradicting.  That is (partially) intentional,
    and reflects the snapshot nature of this memo.
 
 2.  Introduction
 
-   The Internet has created two important global namespaces: Internet
+   The Internet has two important global namespaces: Internet
    Protocol (IP) addresses and Domain Name Service (DNS) names.  These
-   two namespaces have a set of features and abstractions that have
-   powered the Internet to what it is today.  They also have a number of
-   weaknesses.  Basically, since they are all we have, we try and do too
+   two namespaces have sets of features and abstractions that have
+   enabled the growth of the Internet to this day.  They also have a number of
+   weaknesses.  Basically, because they are all we have, we try to do too
    much with them.  Semantic overloading and functionality extensions
-   have greatly complicated these namespaces.
+   have greatly complicated interactions with or changes to these namespaces.
 
    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.  A Host
-   Identity is assigned to each host.  Each host will have at least one
-   Host Identity and a corresponding Host Identifier, which can either
-   be public (e.g.  published in DNS), or unpublished.  Client systems
-   will tend to have both public and unpublished Identities.
+   Host Identifiers (HI.)  A Host Identifier is cryptographic;
+   it is the public key of an asymmetric key-pair.  Each host will have at least one
+   Host Identity and at least one corresponding Host Identifier, which can either
+   be public (e.g.,  published in DNS), or private.  Client systems
+   will tend to have both public and private Identities.
 
    There is a subtle but important difference between Host Identities
    and Host Identifiers.  An Identity refers to the abstract entity that
@@ -284,10 +282,10 @@
 4.  Background
 
    The Internet is built from three principal components: computing
-   platforms (end-points), packet transport (i.e.  internetworking)
-   infrastructure, and services (applications).  The Internet exists to
+   platforms (end-points), packet transport (i.e.,  internetworking)
+   infrastructure, and services (applications.)  The Internet exists to
    service two principal components: people and robotic services
-   (silicon based people, if you will).  All these components need to be
+   (silicon based people, if you will.)  All these components need to be
    named in order to interact in a scalable manner.  Here we concentrate
    on naming computing platforms and packet transport elements.
 
@@ -298,7 +296,7 @@
    IP numbers are a confounding of two namespaces, the names of a host's
    networking interfaces and the names of the locations ('confounding'
    is a term used in statistics to discuss metrics that are merged into
-   one with a gain in indexing, but a loss in informational value).  The
+   one with a gain in indexing, but a loss in informational value.)  The
    names of locations should be understood as denoting routing direction
    vectors, i.e., information that is used to deliver packets to their
    destinations.
@@ -345,7 +343,7 @@
    This could support rapid readdressing of the internetworking layer
    because of mobility, rehoming, or renumbering.
 
-   If the namespace for computing platforms is based on public key
+   If the namespace for computing platforms is based on public-key
    cryptography, it can also provide authentication services.  If this
    namespace is locally created without requiring registration, it can
    provide anonymity.
@@ -359,7 +357,7 @@
 
    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
+      addresses within applications (like in the TCB.)  This may require
       changes to the current APIs.  In the long run, it is probable that
       some new APIs are needed.
 
@@ -369,7 +367,7 @@
 
    o  The names should have a fixed length representation, for easy
       inclusion in datagram headers and existing programming interfaces
-      (e.g the TCB).
+      (e.g the TCB.)
 
    o  Using the namespace should be affordable when used in protocols.
       This is primarily a packet size issue.  There is also a
@@ -409,7 +407,7 @@
    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
+   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.
 
@@ -430,11 +428,11 @@
    unique' may serve as a Host Identifier.  However, in the authors'
    opinion, a public key of a 'public key pair' makes the best Host
    Identifier.  As documented in the Host Identity Protocol
-   specification [4], a public key based HI can authenticate the HIP
-   packets and protect them for man-in-the-middle attacks.  Since
+   specification [4], a public-key-based HI can authenticate the HIP
+   packets and protect them for man-in-the-middle attacks.  Because
    authenticated datagrams are mandatory to provide much of HIP's
    denial-of-service protection, the Diffie-Hellman exchange in HIP has
-   to be authenticated.  Thus, only public key HI and authenticated HIP
+   to be authenticated.  Thus, only public-key HI and authenticated HIP
    messages are supported in practice.  In this document, the
    non-cryptographic forms of HI and HIP are presented to complete the
    theory of HI, but they should not be implemented as they could
@@ -462,7 +460,7 @@
    The only completely defined structure of the Host Identity is that of
    a public/private key pair.  In this case, the Host Identity is
    referred to by its public component, the public key.  Thus, the name
-   representing a Host Identity in the Host Identity namespace, i.e.
+   representing a Host Identity in the Host Identity namespace, i.e.,
    the Host Identifier, is the public key.  In a way, the possession of
    the private key defines the Identity itself.  If the private key is
    possessed by more than one node, the Identity can be considered to be
@@ -491,12 +489,12 @@
 
    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
+   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].
 
    Alternatively, or in addition to storing Host Identifiers in the DNS,
-   they may be stored in various kinds of Public Key Infrastructure
+   they may be stored in various kinds of public-key infrastructure

@@ -505,7 +503,7 @@
 Internet-Draft    Host Identity Protocol Architecture       October 2004

-   (PKI).  Such a practice may allow them to be used for purposes other
+   (PKI.)  Such a practice may allow them to be used for purposes other
    than pure host identification.
 
 5.3  Host Identity Tag (HIT)
@@ -590,14 +588,14 @@
 
 6.1  Transport associations and end-points
 
-   Architecturally, HIP provides for a different binding of transport
-   layer protocols.  That is, the transport layer associations, i.e.,
+   Architecturally, HIP provides for a different binding of transport-
+   layer protocols.  That is, the transport-layer associations, i.e.,
    TCP connections and UDP associations, are no longer bound to IP
    addresses but to Host Identities.
 
    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
+   Host Identity.  Furthermore, because 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
@@ -621,7 +619,7 @@
 
    HIP decouples the transport from the internetworking layer, and binds
    the transport associations to the Host Identities (through actually
-   either the HIT or LSI).  Consequently, HIP can provide for a degree
+   either the HIT or LSI.)  Consequently, HIP can provide for a degree
    of internetworking mobility and multi-homing at a low infrastructure
    cost.  HIP mobility includes IP address changes (via any method) to
    either party.  Thus, a system is considered mobile if its IP address
@@ -643,7 +641,7 @@
    that the mobile node is reachable through these addresses.  This is
    especially helpful for those situations where the peer node is
    sending data periodically to the mobile node (that is re-starting a
-   connection after the initial connection).
+   connection after the initial connection.)
 
 7.1  Rendezvous mechanism
 
@@ -655,7 +653,7 @@
    new static infrastructure to facilitate rendezvous between HIP nodes.
 
    The mobile node keeps the rendezvous infrastructure continuously
-   updated with its current IP address(es).  The mobile nodes must trust
+   updated with its current IP address(es.)  The mobile nodes must trust
    the rendezvous mechanism to properly maintain their HIT and IP
    address mappings.
 
@@ -678,7 +676,7 @@
 
 7.2  Protection against Flooding Attacks
 
-   While the idea of informing about address changes by simply sending
+   Although the idea of informing about address changes by simply sending
    packets with a new source address appears appealing, it is not secure
    enough.  That is, even if HIP does not rely on the source address for
    anything (once the base exchange has been completed), it appears to
@@ -717,7 +715,7 @@
    enable ESP in an end-to-end manner.  This is implemented in a way
    that can span addressing realms.
 
-   While it would be possible, at least in theory, to use some existing
+   Although it would be possible, at least in theory, to use some existing
    cryptographic protocol, such as IKEv2 together with Host Identifiers,
    to establish the needed SAs, HIP defines a new protocol.  There are a
    number of historical reasons for this, and there are also a few
@@ -729,16 +727,15 @@
 Internet-Draft    Host Identity Protocol Architecture       October 2004

-   architectural reasons.  First, IKE (and IKEv2) were not design with
-   middle boxes in mind.  As adding a new naming layer allows one to
+   architectural reasons.  First, IKE (and IKEv2) were not designed with
+   middleboxes in mind.  Because adding a new naming layer allows one to
    potentially add a new forwarding layer (see Section 9, below), it is
-   very important that the HIP protocols are friendly towards any middle
-   boxes.
+   very important that the HIP protocols can traverse any middleboxes.
 
    Second, from a conceptual point of view, the IPsec Security Parameter
    Index (SPI) in ESP provides a simple compression of the HITs.  This
    does require per-HIT-pair SAs (and SPIs), and a decrease of policy
-   granularity over other Key Management Protocols, such as IKE and
+   granularity over other key-management protocols, such as IKE and
    IKEv2.  In particular, the current thinking is limited to a situation
    where, conceptually, there is only one pair of SAs between any given
    pair of HITs.  In other words, from an architectural point of view,
@@ -748,24 +745,24 @@
    may provide for more granularity and creation of several ESP SAs
    between a pair of HITs.
 
-   Since HIP is designed for host usage, not for gateways or so called
-   Bump-in-the-Wire (BITW) implementations, only ESP transport mode is
+   Because HIP is designed for host usage, not for gateways or so called
+   bump-in-the-wire (BITW) implementations, only ESP transport mode is
    supported.  An ESP SA pair is indexed by the SPIs and the two HITs
-   (both HITs since a system can have more than one HIT).  The SAs need
+   (both HITs, because a system can have more than one HIT.)  The SAs need
    not to be bound to IP addresses; all internal control of the SA is by
    the HITs.  Thus, a host can easily change its address using Mobile
    IP, DHCP, PPP, or IPv6 readdressing and still maintain the SAs.
-   Since the transports are bound to the SA (via an LSI or a HIT), any
+   Because the transports are bound to the SA (via an LSI or a HIT), any
    active transport is also maintained.  Thus, real world conditions
    like loss of a PPP connection and its re-establishment or a mobile
    handover will not require a HIP negotiation or disruption of
-   transport services.  [12]
+   transport services [12].
 
-   Since HIP does not negotiate any SA lifetimes, all lifetimes are
+   Because HIP does not negotiate any SA lifetimes, all lifetimes are
    local policy.  The only lifetimes a HIP implementation MUST support
    are sequence number rollover (for replay protection), and SA
-   timeout[4].  An SA times out if no packets are received using that
-   SA.  Implementations MAY support lifetimes for the various ESP
+   timeout [4].  An SA times out if no packets are received using that
+   SA.  Implementations may support lifetimes for the various ESP
    transforms.
 
 9.  HIP and NATs
@@ -785,35 +782,35 @@
 Internet-Draft    Host Identity Protocol Architecture       October 2004

-   In a network environment where the identification is based on the IP
+   In a network environment where identification is based on IP
    addresses, identifying the communicating nodes is difficult when NAT
-   is used.  With HIP, the transport layer end-points are bound to the
+   is used.  With HIP, the transport-layer end-points are bound to 
    Host Identities.  Thus, a connection between two hosts can traverse
    many addressing realm boundaries.  The IP addresses are used only for
-   routing purposes; the IP addresses may be changed freely during
+   routing purposes; IP addresses may be changed freely during
    packet traversal.
 
-   For a HIP based flow, a HIP-aware NAT or NAT-PT system tracks the
+   For a HIP-based flow, a HIP-aware NAT or NAT-PT system tracks the
    mapping of HITs and the corresponding IPsec SPIs to an IP address.
    Many HITs can map to a single IP address on a NAT, simplifying
    connections on address poor NAT interfaces.  The NAT can gain much of
    its knowledge from the HIP packets themselves; however, some NAT
    configuration may be necessary.
 
-   The NAT systems cannot touch the datagrams within the IPsec envelope,
-   thus application specific address translation must be done in the end
+   NAT systems cannot touch datagrams within the IPsec envelope,
+   thus application-specific address translation must be done in the end
    systems.  HIP provides for 'Distributed NAT', and uses the HIT or the
-   LSI as a place holder for embedded IP addresses.
+   LSI as a placeholder for embedded IP addresses.
 
-9.1  HIP and TCP Checksum
+9.1  HIP and TCP Checksums
 
-   There is no way for a host to know if any of the IP addresses in the
+   There is no way for a host to know if any of the IP addresses in an
    IP header are the addresses used to calculate the TCP checksum.  That
    is, it is not feasible to calculate the TCP checksum using the actual
    IP addresses in the pseudo header; the addresses received in the
    incoming packet are not necessarily the same as they were on the
-   sending host.  Furthermore, it is not possible to recompute the upper
-   layer checksums in the NAT/NAT-PT system, since the traffic is IPsec
+   sending host.  Furthermore, it is not possible to recompute the upper-
+   layer checksums in the NAT/NAT-PT system, because the traffic is IPsec
    protected.  Consequently, the TCP and UDP checksums are calculated
    using the HITs in the place of the IP addresses in the pseudo header.
    Furthermore, only the IPv6 pseudo header format is used.  This
@@ -821,16 +818,16 @@
 
 10.  Multicast
 
-   Back in fall 2003, there was little if any concrete thoughts about
-   how HIP might affect IP or application layer multi-cast.
+   Back in the fall of 2003, there were little if any concrete thoughts about
+   how HIP might affect IP or application-layer multicast.
 
 11.  HIP Policies
 
-   There are a number of variables that will influence the HIP exchanges
+   There are a number of variables that influence the HIP exchanges
    that each host must support.  All HIP implementations should support
    at least 2 HIs, one to publish in DNS and an unpublished one for
    anonymous usage.  Although unpublished HIs will be rarely used as
-   responder HIs, they are likely be common for initiators.  Support for
+   responder HIs, they are likely common for initiators.  Support for
    multiple HIs is recommended.

@@ -852,7 +849,7 @@
 
 12.  Benefits of HIP
 
-   In the beginning, the network layer protocol (i.e.  IP) had the
+   In the beginning, the network layer protocol (i.e.,  IP) had the
    following four "classic" invariants:
 
    o  Non-mutable: The address sent is the address received.
@@ -869,26 +866,26 @@
    Actually, the fourth can be inferred from 1 and 3, but it is worth
    mentioning for reasons that will be obvious soon if not already.
 
-   In the current "post-classic" world, we are trying intentionally to
+   In the current "post-classic" world, we are intentionally trying to
    get rid of the second invariant (both for mobility and for
    multi-homing), and we have been forced to give up the first and the
-   fourth.  Realm Specific IP [3] is an attempt to reinstate the fourth
+   fourth.  Realm-Specific IP [3] is an attempt to reinstate the fourth
    invariant without the first invariant.  IPv6 is an attempt to
    reinstate the first invariant.
 
-   Few systems on the Internet have DNS names that are meaningful to
-   them.  That is, if they have a Fully Qualified Domain Name (FQDN),
-   that typically belongs to a NAT device or a dial-up server, and does
+   Few systems on the Internet have DNS names that are meaningful.
+   That is, if they have a Fully Qualified Domain Name (FQDN),
+   that name typically belongs to a NAT device or a dial-up server, and does
    not really identify the system itself but its current connectivity.
-   FQDN names (and their extensions as email names) are Application
-   Layer names; more frequently naming services than a particular
-   system.  This is why many systems on the internet are not registered
-   in DNS; they do not have services of interest to other Internet
+   FQDNs (and their extensions as email names) are application-
+   layer names; more frequently naming services than a particular
+   system.  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.
 
    DNS names are references to IP addresses.  This only demonstrates the
    interrelationship of the networking and application layers.  DNS, as
-   the Internet's only deployed, distributed, database is also the
+   the Internet's only deployed, distributed database is also the

@@ -905,14 +902,14 @@
 
    The Host Identity (HI) namespace fills an important gap between the
    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
+   actually allows one to give up all but the 3rd network-layer
    invariant.  That is to say, as long as the source and destination
-   addresses in the network layer protocol are reversible, then things
+   addresses in the network-layer protocol are reversible, then things
    work ok because HIP takes care of host identification, and
    reversibility allows one to get a packet back to one's partner host.
-   You don't care if the network layer address changes in transit
-   (mutable) and you don't care what network layer address the partner
-   is using (non-omniscient).
+   You do not care if the network-layer address changes in transit
+   (mutable) and you do not care what network-layer address the partner
+   is using (non-omniscient.)
 
 12.1  HIP's Answers to NSRG questions
 
@@ -943,7 +940,7 @@
           HIP provides both stable and temporary Host Identifiers.
           Stable HIs are typically long lived, with a lifetime of years
           or more.  The lifetime of temporary HIs depends on how long
-          the upper layer connections and applications need them, and
+          the upper-layer connections and applications need them, and
           can range from a few seconds to years.

@@ -962,7 +959,7 @@
           The Host Identifiers may be used directly or indirectly (in
           the form of HITs or LSIs) by applications when they access
           network services.  Additionally, the Host Identifiers, as
-          public keys, are used in the built in key agreement protocol,
+          public keys, are used in the built in key-agreement protocol,
           called the HIP base exchange, to authenticate the hosts to
           each other.
 
@@ -986,8 +983,8 @@
           HIP reduces dependency on IP addresses, making the so called
           address ownership [11] problems easier to solve.  In practice,
           HIP provides security for end-host mobility and multi-homing.
-          Furthermore, since HIP Host Identifiers are public keys,
-          standard public key certificate infrastructures can be applied
+          Furthermore, because Host Identifiers are public keys,
+          standard public-key certificate infrastructures can be applied
           on the top of HIP.
 
    9.  What would the resolution mechanisms be, or what characteristics
@@ -998,7 +995,7 @@
           However, if it becomes necessary to resolve HIs into IP
           addresses or back to DNS names, a flat resolution
           infrastructure is needed.  Such an infrastructure could be
-          based on the ideas of Distributed Hash Tables, but would
+          based on the ideas of distributed hash tables, but would
           require significant new development and deployment.

@@ -1019,7 +1016,7 @@
    that potentially could be more damaging to a host's ability to
    conduct business as usual.
 
-   Resource exhausting Denial-of-service attacks take advantage of the
+   Resource exhausting denial-of-service attacks take advantage of the
    cost of setting up a state for a protocol on the responder compared
    to the 'cheapness' on the initiator.  HIP allows a responder to
    increase the cost of the start of state on the initiator and makes an
@@ -1036,7 +1033,7 @@
    method to force the start of HIP is expensive on either host, the
    attacker need only spoof a TCP SYN.  This would put both systems into
    the expensive operations.  HIP avoids this attack by having the
-   responder send a simple HIP packet that it can pre-build.  Since this
+   responder send a simple HIP packet that it can pre-build.  Because this
    packet is fixed and easily replayed, the initiator only reacts to it
    if it has just started a connection to the responder.
 
@@ -1048,14 +1045,14 @@
    initiator can use this to authenticate the signed HIP packets.
    Likewise, if the initiator's HI is in a secure DNS zone, the
    responder can retrieve it and validate the signed HIP packets.
-   However, since an initiator may choose to use an unpublished HI, it
+   However, because an initiator may choose to use an unpublished HI, it
    knowingly risks a MitM attack.  The responder may choose not to
    accept a HIP exchange with an initiator using an unknown HI.
 
    In HIP, the Security Association for IPsec is indexed by the SPI; the
    source address is always ignored, and the destination address may be
-   ignored as well.  Therefore, HIP enabled IPsec Encapsulated Security
-   Payload (ESP) is IP address independent.  This might seem to make it
+   ignored as well.  Therefore, HIP enabled IPsec encapsulated security
+   payload (ESP) is IP address independent.  This might seem to make it
    easier for an attacker, but ESP with replay protection is already as

@@ -1068,7 +1065,7 @@
    well protected as possible, and the removal of the IP address as a
    check should not increase the exposure of IPsec ESP to DoS attacks.
 
-   Since not all hosts will ever support HIP, ICMPv4 'Destination
+   Because not all hosts will ever support HIP, ICMPv4 'Destination
    Unreachable, Protocol Unreachable' and ICMPv6 'Parameter Problem,
    Unrecognized Next Header' messages are to be expected and present a
    DoS attack.  Against an initiator, the attack would look like the
@@ -1088,7 +1085,7 @@
    the defense against this attack is for the initiator to wait a
    reasonable time period to get a valid HIP packet.  If one does not
    come, then the initiator has to assume that the ICMP message is
-   valid.  Since this is the only point in the HIP base exchange where
+   valid.  Because this is the only point in the HIP base exchange where
    this ICMP message is appropriate, it can be ignored at any other
    point in the exchange.
 
@@ -1098,20 +1095,20 @@
    use HITs to control egress and ingress to networks, with an assurance
    level difficult to achieve today.  As discussed above in Section 8,
    once a HIP session has been established, the SPI value in an IPsec
-   packet may be used as an index, indicating the HITs.  In practise,
-   the firewalls can inspect the HIP packets to learn of the bindings
+   packet may be used as an index, indicating the HITs.  In practice,
+   firewalls can inspect HIP packets to learn of bindings
    between HITs, SPI values, and IP addresses.  They can even explicitly
    control IPsec usage, dynamically opening IPsec ESP only for specific
-   SPI values and IP addresses.  The signatures in the HIP packets allow
-   a capable firewall to make sure that the HIP exchange is indeed
+   SPI values and IP addresses.  The signatures in HIP packets allow
+   a capable firewall to ensure that the HIP exchange is indeed
    happening between two known hosts.  This may increase firewall
    security.
 
    There has been considerable bad experience with distributed ACLs that
-   contain public key related material, for example, with SSH.  If the
-   owner of the key needs to revoke it for any reason, the task of
+   contain public-key-related material, for example, with SSH.  If the
+   owner of a key needs to revoke it for any reason, the task of
    finding all locations where the key is held in an ACL may be
-   impossible.  If the reason for the revocation is due to private key
+   impossible.  If the reason for the revocation is due to private-key
    theft, this could be a serious issue.

@@ -1129,10 +1126,10 @@
 
    HIP-aware NATs, however, are transparent to the HIP aware systems by
    design.  Thus, the host may find it difficult to notify any NAT that
-   is using a HIT in an ACL.  Since most systems will know of the NATs
+   is using a HIT in an ACL.  Because most systems will know of the NATs
    for their network, there should be a process by which they can notify
    these NATs of the change of the HIT.  This is mandatory for systems
-   that function as responders behind a NAT.  In a similar vein, if a
+   that function as responders behind a NAT.  Similarly, if a
    host is notified of a change in a HIT of an initiator, it should
    notify its NAT of the change.  In this manner, NATs will get updated
    with the HIT change.
@@ -1141,21 +1138,21 @@
 
    The definition of the Host Identifier states that the HI need not be
    a public key.  It implies that the HI could be any value; for example
-   an FQDN.  This document does not describe how to support such a
+   a FQDN.  This document does not describe how to support such a
    non-cryptographic HI.  A non-cryptographic HI would still offer the
-   services of the HIT or LSI for NAT traversal.  It would be possible
-   carry the HITs in HIP packets that had neither privacy nor
-   authentication.  Since such a mode would offer so little additional
-   functionality for so much addition to the IP kernel, it has not been
-   defined.  Given how little public key cryptography HIP requires, HIP
-   should only be implemented using public key Host Identities.
+   services of the HIT or LSI for NAT traversal.  It would be possible to
+   carry HITs in HIP packets that have neither privacy nor
+   authentication.  Because such a mode would offer so little additional
+   functionality for the complexities it adds to an IP kernel, it has not been
+   defined.  Given how little public-key cryptography HIP requires, HIP
+   should only be implemented using public-key Host Identities.
 
    If it is desirable to use HIP in a low security situation where
-   public key computations are considered expensive, HIP can be used
+   public-key computations are considered expensive, HIP can be used
    with very short Diffie-Hellman and Host Identity keys.  Such use
-   makes the participating hosts vulnerable to MitM and connection
+   makes the participating hosts vulnerable to MitM and connection-
    hijacking attacks.  However, it does not cause flooding dangers,
-   since the address check mechanism relies on the routing system and
+   because the address check mechanism relies on the routing system and
    not on cryptographic strength.
 
 14.  Acknowledgments
@@ -1327,7 +1324,7 @@
 
 Copyright Statement
 
-   Copyright (C) The Internet Society (2004).  This document is subject
+   Copyright (C) The Internet Society (2004.)  This document is subject
    to the rights, licenses and restrictions contained in BCP 78, and
    except as set forth therein, the authors retain all their rights.

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 20 Oct 2004 18:12:27 +0300

> below, the attached diff has both them and the nits.

Thanks.  I'll return to the nits later.

> single one, or at least one? I think the latter, and would just remove

As far as I can understand what Bob has meant, the first sentence
says that the HI->host direction of the relationship is unary and
non-zero, and the second says that the HI<-host direction is not unary
but there may be multiple IDs per host.  IMHO, both are needed.  OTOH,
the sentences could be certainly reformulated, if people find
them confusing.  Any suggestions for rewording?

> kind "private" instead of "unpublished?"

The term that we user before was "anonymous", but some people felt
that it was inappropriate.  "private" was also thought to be bad,
since an unpublished HI may not be secret, and "private" in that sense.
As a compromise, I chose "unpublished", which I agree to be bad,
but maybe less bad than the others.

Anyway, I don't that much care about what term we use, as long as
we are consistent.  Any suggestions or opinions?

> Section 2, 4th paragraph: A sentence on why we didn't go with IKE may 

Would a reference to Section 8 do?

> Formatting is weird. Is this a new bullet or belongs to the previous

It belongs to a previous one.  Any suggestions on how to change the
formatting?

> RFC 2119. We should probably change all RFC 2119 terms to lower case 

Ok, that is an oversight by me.  I will fix it.  I didn't find anything
else but one MUST.  Did I miss something?

> SPIs to an IP address." Not sure what this sentence is supposed to 

I'll take this up separately as this may need some discussion.
(Later, now I must go.)

> All section headings: Use consistent capitalization througout the

Ok, I will fix that.

--Pekka

---

From: Lars Eggert <[email-masked]>
Date: Wed, 20 Oct 2004 18:26:21 +0200

> them confusing.  Any suggestions for rewording?

How about: "Each host will have at least one host identity, but may have 
multiple ones. Each host identity uniquely identifies a single host, 
i.e., no two hosts have the same host identity."

> we are consistent.  Any suggestions or opinions?

Didn't know these had been discussed. The comment was based on the 
observation that "unpublished" isn't the natural opposite of "public." 
Anyhow, I don't think this is really too important.

> Would a reference to Section 8 do?

Yup, saw that there is more on that later.

> It belongs to a previous one.  Any suggestions on how to change the

Move it under the previous bullet then? Currently it looks like this, 
which is probably an xml2rfc issue:

    o  It must be possible to create names locally.  This can provide
       anonymity at the cost of making resolvability very difficult.

          Sometimes the names may contain a delegation component.  This
          is the cost of resolvability.

> else but one MUST.  Did I miss something?

Didn't find anything else either.

> I'll take this up separately as this may need some discussion.

On second reading, it makes sense. When I first read it, I wasn't able 
to parse the sentence. Lack of coffee, probably.

Lars