Re: [Hipsec] Feedback for 4423bis

[Miika Komu <[e-mail]>]

Hi,

On 10/19/2012 12:38 AM, Miika Komu wrote:
> Hi,
>
> On 10/10/2012 10:05 PM, Sasu Tarkoma wrote:
>> Hi all,
>>
>> I read the latest HIP architecture draft (4423bis-05) and it looks
>> very good. Below you will find some observations that I made
>> when reading the draft.
>
> looks good to me too but I have also some suggestions for improvement.
> Here's the first batch of comments, I'll send the remaining ones later.

the second batch is here, I'll send the third and final later.

> 6.2. Protection against flooding attacks
>
> HIP includes an address check mechanism

(or return routability test)

> 7. HIP and ESP
>
 > The preferred way of implementing HIP is to use ESP to carry the
 > actual data traffic.  As of today, the only completely defined method
 > is to use ESP Encapsulated Security Payload (ESP) to carry the data
 > packets [I-D.ietf-hip-rfc5202-bis].  In the future, other ways of
 > transporting payload data may be developed, including ones that do
 > not use cryptographic protection.

Several comments:
* I would start the discussion by mentioning that the data plane 
encapsulation is not fixed and can be negotiated during the key exchange.
* ESP offers confidentiality protection or integrity protection, or 
both, and this is negotiable
* More precisely, the default ESP mode is BEET (tunnel mode semantics 
but transport mode syntax) to reduce the overhead of tunneling but 
transport and tunnel mode are negotiable by further extensions.
* Other encapsulations have been proposed: 
http://tools.ietf.org/html/draft-tschofenig-hiprg-hip-srtp-01

 > In practice, the HIP base exchange uses the cryptographic Host
 > Identifiers to set up a pair of ESP Security Associations (SAs) to
 > enable ESP in an end-to-end manner.  This is implemented in a way
 > that can span addressing realms.

How? Unless you want to explain, please just reference RFC 5770 or the 
draft:

http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal

Informal reference is fine.

 > First, IKE (and IKEv2) were not designed with middle boxes in mind.

Yes, historically, but also IKE has UDP encapsulation nowadays and 
products can even fake TCP/HTTP encapsulation. This sentence actually a 
bit ambiguous since IKE(v2) is actually *is* a middlebox (gateway) based 
solution (where as the end-to-end mode is the default for HIP). Please 
rephrase and I would also urge to stick to the state of art rather than 
history.

 > Originally, as HIP is designed for host usage, not for gateways or so
 > called Bump-in-the-Wire (BITW) implementations, only ESP transport
 > mode is supported.

Again, let's just focus on the state of the art; you start the 
description with "originally" and never describe "presently". Also, the 
most popular mode is the BEET, not transport.

 > An ESP SA pair is indexed by the SPIs and the two
 > HITs (both HITs since a system can have more than one HIT).

Yes, internally for hosts, but externally on the wire it's just the SPI 
when BEET mode is applied. HITs are not included in the packet.

 > 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 [Bel1998].

Yet another historical reference. Bel1998 points to a slide set which is 
not really the best type of reference you can have. I would suggest 
omitting the reference since it's rather unimportant.

> 8. HIP and MAC Security

Does this count as MAC-based security scheme:

http://tools.ietf.org/html/draft-henderson-hip-vpls

> 9. HIP and NATs
> ..
 > This may happen, ..

This may occur,

 > For a HIP-based flow, a HIP-aware NAT or NAT-PT system tracks the
 > mapping of HITs, and the corresponding ESP SPIs, to an IP address.
 > The NAT system has to learn mappings both from HITs and from SPIs to
 > IP addresses.  Many HITs (and SPIs) 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.

You're missing a reference:

http://dl.acm.org/citation.cfm?id=1128500

Also, you're giving an impression that HIP-aware NATs are typically used 
but this is not really the case. As a concrete way to improve the text, 
please start with the RFC5770 reference and only then describe the above 
mentioned SPINAT draft.

Regarding to RFC5770, I would suggest to mention that also Teredo (RFC 
4380) has been successfully experimented with HIP:

http://dl.acm.org/citation.cfm?id=1719793

In a nutshell, Teredo has more infrastructure but some additional 
overhead naturally results from additional tunneling.

 > HIP provides for 'Distributed NAT', and uses the HIT or the
 > LSI as a placeholder for embedded IP addresses.

Suggestion:

HIP provides for 'Distributed NAT' operating between network and upper 
layers, and uses the HIT or the LSI as a placeholder for embedded IP 
addresses. For this reason, HIP is able to support communications 
between an IPv4 and IPv6-based application.

 > An experimental HIP and NAT traversal is defined in [RFC5770].

Or...

http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal

?

> 9.1. HIP and Upper-layer checksums
>  ..

> 10. Multicast

The discussion is really void without any references:

http://dl.acm.org/citation.cfm?id=277744
http://dl.acm.org/citation.cfm?id=2006035
http://dl.acm.org/citation.cfm?id=2006035

> 11. HIP policies
> ..
 > Opportunistic mode (where the initator starts a HIP exchange without
 > prior knowledge of the responder's HI) presents a policy tradeoff.

the most detailed reference for this is:

http://dl.acm.org/citation.cfm?id=1700740

But feel free to reference also the experiment report:

http://tools.ietf.org/html/rfc6538#section-2.3.2

 > It provides some security benefits but may be subject to MITM.

At the expense of being subject to MITM attacks, the opportunistic mode 
allows the initiator learn the the identity of the responder during 
communications rather than from an external directory.

A good reference for opportunistic mode is:

V. Pham and T. Aura. Security Analysis of Leap-of-Faith Protocols. In
Seventh ICST International Conference on Security and Privacy for Com-
munication Networks, Sept. 2011.

> 12. Benefits of HIP

Please add a section for drawbacks:

* Additional management complexity by additional indirection layer and 
namespace
* Any tunneling mechanism causes some extra latency and bandwidth 
limitations for the data plane
* Referrals (which are already a problem due to NATs)

 > In the beginning, the network layer protocol (i.e., IP) had the
 > following four "classic" invariants:

What's your reference for the classic invariants? I suggest also 
switching to numbered bullets when listing them because you then later 
reference them by number.

 > IPv6 is an attempt to reinstate the first invariant.

What about NAT64?

 > Few systems on the Internet have DNS names that are meaningful.

Few client-side systems...

 > Although each namespace can be stretched (IP
 > with v6, DNS with KEY records), neither can adequately provide for
 > host authentication or act as a separation between internetworking
 > and transport layers.

URIs and URLs also extend the DNS namespace and are more common than KEY 
records.

 > 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
 > invariant.  That is to say, as long as the source and destination
 > 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 do not 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).

Actually, even the third invariant is lost due to NATs that involve the 
transport layer ports, but HIP can be used even in such a case.

The invariants are not "given up", they just shifted to the HIP layer 
for proper handling.

> 12.1. HIP's answers to NSRG questions
>
 > 1.  How would a stack name improve the overall functionality of the
 >     Internet?
 >
 >     HIP decouples the internetworking layer from the transport
 >     layer, allowing each to evolve separately.  The decoupling
 >     makes end-host mobility and multi-homing easier, also across
 >     IPv4 and IPv6 networks.  HIs make network renumbering easier,
 >     and they also make process migration and clustered servers
 >     easier to implement.  Furthermore, being cryptographic in
 >     nature, they provide the basis for solving the security
 >     problems related to end-host mobility and multi-homing.

You're missing IPv6 interoperability at the *application* layer.

 > 3.  What is its lifetime?
 >
 >     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
 >     can range from a few seconds to years.

Advancements in crypto analysis may also reduce the lifetime of the 
Identifiers because they are bound to cryptographic algorithms.

 > 4.  Where does it live in the stack?
 >
 >     The HIs live between the transport and internetworking layers.

...but are referenced by the application and transport layers.

 > 6.  What administrative infrastructure is needed to support it?
 >
 >     In some environments, it is possible to use HIP
 >     opportunistically, without any infrastructure.

again, the most detailed reference for this is:

http://dl.acm.org/citation.cfm?id=1700740

But feel free to reference also the experiment report:

http://tools.ietf.org/html/rfc6538#section-2.3.2

 >     However, to
 >     gain full benefit from HIP, the HIs must be stored in the DNS
 >     or a PKI, and a new rendezvous mechanism is needed
 >     [I-D.ietf-hip-rfc5205-bis].

LDAP (RFC4510) is missing, this has been used successfully.

 > 8.  What additional security benefits would a new naming scheme
 >     offer?
 >
 >     HIP reduces dependency on IP addresses, making the so called
 >     address ownership [Nik2001] 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 on the top of HIP.

You're missing a reference to RFC6253.

 > 9.  What would the resolution mechanisms be, or what characteristics
 >     of a resolution mechanisms would be required?
 >
 >     For most purposes, an approach where DNS names are resolved
 >     simultaneously to HIs and IP addresses is sufficient.

Typically, a locally installed DNS proxy has been deployed at the 
client-side host to support this for legacy applications.

 >     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
 >     require significant new development and deployment.

Missing a DHT reference to RFC 6537.

Actually, the ORCHID prefix for HIP could be delegated to an 
organization, and look ups distributed within the servers of the 
organization. DHT is not the only solution, we can stick to DNS:

http://tools.ietf.org/html/draft-ponomarev-hip-hit2ip-00