Subject: [Hipsec] HIP shortcomings (was something else)

From: Pekka Nikander <[email-masked]>
Date: Sun, 18 Sep 2005 09:16:29 +0200

[Discussion coming from IETF Discuss list]

Iljitsch,

> I think HIP is on the right track in some areas, but I don't like  
> the protocol as such because the overhead is too large, and I think  
> even though it's fairly radical in some ways, it doesn't go far  
> enough.

With regard to overhead, as we have repeatedly discussed briefly, it  
would be technically possible to

   a) design a variant (extension) of HIP that uses light weight mitm- 
vulnerable authentication, and

   b) define how to use plain TCP and UDP while when HIP state is there

However, there hasn't been enough of interest in the HIP community to  
specify exactly how.  W.r.t. b), I guess some people are waiting for  
shim6 to converge, and then will define a simple extension for  
carrying plain TCP and UDP.

What comes to a), there was the LHIP (Lightweight HIP) idea that,  
IMHO, was OK but it never flew since there wasn't enough of interest.

> For instance, the first sentence of any new internet architecture  
> would have to be: one size does NOT fit all.

HIP has been carefully designed to be a) extensible and b) optional  
in the sense that you can decide whether to use it or not in any  
particular situation.

> The assumption that it does has allowed a lot of great work in the  
> past. For instance, for some time, TCP was able to accommodate the  
> slowest possible links and the fastest. But that's no longer true,  
> so now we have to choose between enabling RFC 1323 high performance  
> options to allow high speed downloads across the globe, or disable  
> them and allow for header compression to optimize for low speed  
> links. Unfortunately most operating systems enable the options,  
> killing header compression, while applications fail to use buffers  
> that are big enough so long distance high speed downloads aren't  
> possible either.
>
> That kind of stuff is very common in today's internet.

I agree, and your warning is a fair one.  Personally, I can't see  
where there we would have gone wrong so far, but I am *very*  
interested in hearing your detailed analysis.

> We also need to address the need of intermediate systems to  
> influence the communication between two endpoints in various ways,  
> without killing the end-to-end principle wholesale.

Exactly!  That principle has affected many aspects of HIP design, for  
example, the ability to add fields *after* the end-to-end signature,  
to basic principle of carrying SPIs and other traffic selectors in  
clear in the control packets, etc.  We have been trying *very* hard  
to fulfil that principle, but of course, I am sure we have also made  
some mistakes in the way.

It would be great if you could review the latest protocol spec, now  
past WG LC and going to cross-area review.  We should have -04 of  
draft-ietf-hip-base out any day now.

> Routing, naming, addressing and layering is a big mess in the  
> current "architecture". (I'm using quotes because all of this  
> evolved over time without noticeable architectural oversight.) CIDR  
> was a step in the right direction,

OK so far, but ...

> but now it's time for the next step: make addresses variable  
> length. (One size doesn't fit all.)

Why this?

> Port numbers should be part of the address to allow for easier  
> filtering.

I agree that port numbers are becoming obsolete, but perhaps for  
other reasons that what you imagine.

> Having DNS names is great, but applications shouldn't have to deal  
> with name to address mappings: we need a new API that hides  
> addresses from applications that don't have any need to look at them.

There I agree again, whole heartedly!  But, OTOH, I also think  
*strongly* that we should work hard to diminish our dependency on DNS  
names and work actively to create new alternative naming  
infrastructures, such as CoDNSs (http://www.cs.cornell.edu/people/egs/ 
beehive/codons.php) or the Handle System (http://www.handle.net/).

> HIP does get the locator/identifier idea right.

Thanks!

> In addition to that, we need to abandon the notion of one single  
> network with a fixed root.

Again, I concur.  [From a security point of view, you may be  
interested in the following paper of ours:

Ilari Lehti and Pekka Nikander, "Certifying trust," in Proceedings of  
the Practice and Theory in Public Key Cryptography (PKC) '98,  
Yokohama, Japan, Springer-Verlag, February 1998. http:// 
www.tml.tkk.fi/~pnr/publications/PKC-98.pdf ]

> By allowing each point in the network to be the root, and map all  
> other parts of the network to arbitrary parts of the hierarchy as  
> seen from a given root, we can impose the constraints required by  
> many organizations. Interdomain routing needs more link state like  
> mechanisms in order to get rid of BGP's version of the count to  
> infinity problem. It also needs to work when the view of the  
> network is incomplete, while at the same time taking advantage of  
> additional topological information when available. (This includes  
> taking advantage of geography in routing.) And interdomain routing  
> shouldn't be subvertable like it is today.

While I think I agree with you, I have to admit that I understand too  
little about real life routing, and e.g. how to use MPLS for TE and  
policy routing, to really understand what you are saying.

Are there anything more substantial written?  Something I could read?

> Coming back to IPsec: we need more of this. TLS is broken because  
> it doesn't protect the underlying TCP session. We need an API that  
> allows applications to do an IPsec version of "STARTTLS". (It would  
> be nice if we could do authentication first and then encryption,  
> unlike it's done today, to get rid of at least SOME of the huge  
> IPsec overhead: the auth data can then be the encryption IV.)

I'd appreciate if you could provide this opinion to the BTNS WG,  
which is working on some related API issues, and perhaps participate  
actively there?

> In other words: we now need to do everything that we didn't do  
> until now because it was too hard.

I think we need to create a vision of that "everything" and then work  
out some kind of road map towards that vision, realising that the  
vision will necessarily change while we are inching towards it.

--Pekka

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