Subject: [Hipsec] Arch Issue #4: The document does not explain IPsec usage

From: [email-masked] (Pekka Nikander)
Date: Thu Oct 9 14:16:00 2003

The current architecture document doesn't really
explain how HIP uses IPsec to protect the actual
payload traffic.  This may lead a new reader to
complete confusion.

Proposal:  Add the following text to the end of
the Introduction section.

       <t>When HIP is used, the actual payload traffic between two HIP
       hosts is typically protected with IPsec.  HIP Host Identifiers
       are used to create the needed IPsec Security Associations (SA)
       and to authenticate the hosts.  The actual payload IP packets do
       not differ in any way from standard IPsec protected IP
       packets.</t>

Additionally, a number of occasions where the document
talks about ESP, it is apparently better to talk about
IPsec in general.  That is, architecturally there is
not so much difference between in some of the places.

I've placed a snapshot on my web site.  It is easiest to
see the changes from the diff document:

http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct09-diff.html

Below is also a diff.

--Pekka Nikander

*** draft-moskowitz-hip-arch-05.xml.~1.3.~	Thu Oct  9 09:15:44 2003
--- draft-moskowitz-hip-arch-05.xml	Thu Oct  9 21:32:26 2003
***************
*** 96,101 ****
--- 96,108 ----
         multi-homing and dynamic IP renumbering, aid in protocol
         translation / transition, and greatly reduce denial of service
         (DoS) attacks.</t>
+
+       <t>When HIP is used, the actual payload traffic between two HIP
+       hosts is typically protected with IPsec.  HIP Host Identifiers
+       are used to create the needed IPsec Security Associations (SA)
+       and to authenticate the hosts.  The actual payload IP packets do
+       not differ in any way from standard IPsec protected IP
+       packets.</t>
       </section>

       <section title="Background">
***************
*** 453,467 ****

         <t>When a node moves while communication is already on-going,
         address changes are rather straightforward.  The peer of the
!       mobile node can just accept a HIP or an ESP packet from any
!       address and totally ignore the source address.  As discussed in
!       <xref target="ssec-flooding" /> below, a mobile node must send a
!       HIP readdress packet to inform the peer of the new address(es),
!       and the peer must verify that the new 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).</t>

         <section title="Rendezvous server">

--- 460,474 ----

         <t>When a node moves while communication is already on-going,
         address 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.  As discussed in <xref target="ssec-flooding" /> below,
!       a mobile node must send a HIP readdress packet to inform the
!       peer of the new address(es), and the peer must verify that the
!       new 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).</t>

         <section title="Rendezvous server">

***************
*** 557,569 ****
         may be changed freely during packet traversal.</t>

         <t>For a HIP based flow, a NAT or NAT-PT system needs only track
!       the mapping of the HIT or SPI 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.</t>

!       <t>The NAT systems cannot touch the datagrams within the ESP
         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
--- 564,576 ----
         may be changed freely during packet traversal.</t>

         <t>For a HIP based flow, a NAT or NAT-PT system needs only track
!       the mapping of the HIT or IPsec Security Parameter Index (SPI) 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.</t>

!       <t>The NAT systems cannot touch the 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
***************
*** 817,837 ****

         <t>HIP takes advantage of the new Host Identity paradigm to
         provide secure authentication of hosts and provide a fast key
!       exchange for IPsec ESP.  HIP also attempts to limit the exposure
         of the host to various denial-of-service (DoS) and
         man-in-the-middle (MitM) attacks.  In so doing, HIP itself is
         subject to its own DoS and MitM attacks that potentially could
         be more damaging to a host's ability to conduct business as
         usual.</t>

!       <t>The Security Association for ESP is indexed by the SPI; the
         source address is always ignored, and the destination address
!       may be ignored as well.  Therefore, HIP enabled ESP is IP
!       address independent.  This might seem to make it easier for an
!       attacker, but ESP with replay protection is already as well
!       protected as possible, and the removal of the IP address as a
!       check should not increase the exposure of ESP to DoS
!       attacks.</t>

         <t>Denial-of-service attacks take advantage of the cost of
         setting up a state for a protocol on the responder compared to
--- 824,844 ----

         <t>HIP takes advantage of the new Host Identity paradigm to
         provide secure authentication of hosts and provide a fast key
!       exchange for IPsec.  HIP also attempts to limit the exposure
         of the host to various denial-of-service (DoS) and
         man-in-the-middle (MitM) attacks.  In so doing, HIP itself is
         subject to its own DoS and MitM attacks that potentially could
         be more damaging to a host's ability to conduct business as
         usual.</t>

!       <t>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 easier for an attacker, but ESP with
!       replay protection is already as 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.</t>

         <t>Denial-of-service attacks take advantage of the cost of
         setting up a state for a protocol on the responder compared to
***************
*** 898,912 ****
   	<t>It is expected that HITs will be used in ACLs.  Future
           firewalls can use HITs to control egress and ingress to
           networks, with an assurance difficult to achieve today.  As
!         discussed above in <xref target="spi" />, once a HIP session
!         has been established, the SPI value in an ESP packet may be
           used as an index, indicating the HITs.  In practise, the
!         firewalls can inspect the HIP packets and learn the SPI values
!         from there.  They can even explicitly control ESP usage,
!         opening 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 happening between
!         two known hosts.  This may increase firewall security.</t>

   <!--   <t>[add here wildcarding]</t> -->

--- 905,920 ----
   	<t>It is expected that HITs will be used in ACLs.  Future
           firewalls can use HITs to control egress and ingress to
           networks, with an assurance difficult to achieve today.  As
!         discussed above in <xref target="spi" />, 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
!         between HITs, SPI values, and IP addresses.  They can even
!         explicitly control IPsec usage, 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 happening between two known hosts.  This
!         may increase firewall security.</t>

   <!--   <t>[add here wildcarding]</t> -->

---

From: [email-masked] (Jari Arkko)
Date: Thu Oct 9 14:39:01 2003

>       hosts is typically protected with IPsec.  HIP Host Identifiers

Wouldn't the draft be more specific if it said instead "is protected
with IPsec"?

> IPsec in general.  That is, architecturally there is

Hmm... if you talk about ESP then its again more specific,
less room for interpretation, less options, less interoperability
problems...?

--Jari

---

From: [email-masked] (Pekka Nikander)
Date: Fri Oct 10 03:48:02 2003

Jari,

> Wouldn't the draft be more specific if it said instead "is protected

There is a desire to make HIP to work without IPsec.  In fact,
we know how to do that if we could get one bit allocated in the
IP header.  Such practise would be fairly insecure, though, and
nobody has had time to really analyze the potential consequences.
Hence, nobody has not really proposed anything concrete in that
arena.

On the other hand, I'd like to keep the architecture spec open
in this respect.  That is, while HIP currently relies pretty
heavily on ESP, the situation does not need to be so in the
future.  I'd like the architecture spec to reflect this view somehow.

> less room for interpretation, less options, less interoperability

Remember that this is an *architecture* document.  It is
desirable that architectures are open ended.

It is a different case with the actual protocol spec.
It should be as specific as possible, to ensure interoperability
and simplicity.

--Pekka