Subject: New multiaddressing review and new MAST draft

From: Dave Crocker <[email-masked]>
Date: Tue, 16 Sep 2003 17:35:42 -0700

Howdy.

I've just submitted some new mobility/multihoming I-Ds for
distribution. Meanwhile, they are available from my website, in text and MS
Word formats.

The first breaks out the "discussion" section of the original MAST paper and
expands on it:

     Choices for Support of Multiaddressing

     Text:
       <http://brandenburg.com/specifications/draft-crocker-mast-analysis-00.txt>
     MSWord :
       <http://brandenburg.com/specifications/draft-crocker-mast-analysis-00.doc>

The second is the revised draft proposal:

     Multiple Address Service For Transport (MAST):
     An Extended Proposal

     Text:
        <http://brandenburg.com/specifications/draft-crocker-mast-proposal-01.txt>
     MSWord:
        <http://brandenburg.com/specifications/draft-crocker-mast-proposal-01.doc>

d/
----- 
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA USA <tel: +1.408.246.8253>; <fax: +1.408.850.1850>

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 17 Sep 2003 12:52:37 +0200

Hi Dave,

I think it is valuable to have a document covering the issues related to
multi-addressing, so thanks for doing it.

My main comment about the document is that the security section seems
incomplete to me.

The only considered threat is connection hijacking. I guess there much other
issues to consider.

IMHO the security section is focused on the threats reffered to the parties
involved in the communication. However, it is also important to consider the
new threats that the adoption of multi-addressing mechanisms means for other
hosts in the internet (for instance non-mobile, non multi-homed hosts)
For instance, flooding attacks, dos attacks.

Other type of attacks should also be considered such as time shifting
attacks.

I would recomend considering the analysis contained in
draft-nikander-mobileip-v6-ro-sec as an input. It contain a detailed
analysis of different attacks related to mobility.

Regards, marcelo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Dave Crocker
> Enviado el: miercoles, 17 de septiembre de 2003 2:36
> Para: [email-masked]
> Asunto: New multiaddressing review and new MAST draft
>
>
> Howdy.
>

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 17 Sep 2003 15:02:09 +0300

Dave,

Firstly, I very much agree with Marcelo wrt. his comment
about security.

Secondly, some specific comments about the HIP section:

>      3.5.2.    Host Identity Protocol (HIP)
>      
>      HIP works with IPv4 and IPv6.  Also, it:
>      
>           *    Creates a new, globally unique name space

You may consider adding "probabilistically", since the only
currently defined type of HIs are public keys.  HIP does not
assume any key registry, and therefore the uniqueness of host
identifiers is only probabilistic.

(I also suspect that none of the current implementations supports
  resolving HIT conflicts, even if the spec requires that.  However,
  even with that the probability of conflicts is very low.)

>           *    Uses strong, cryptographically based protocol details,
>                overloading some HIP functionality with security 
>                functionality

I am not quite sure about the word "overload".  That is, I don't
quite understand what you imply with it.

HIP was initially designed to solve other identity related
problems but mobility and multi-homing, with strong focus
on security.  Rudimentary mobility support was there from
fairly early on, but real mobility support (with rendezvous)
and multi-homing came only afterwards, around the time I
joined the HIP gang a couple of years ago.  And the exact
details for those are still being worked on.

>           *    Is tied significantly to [IPSEC]

Well, while that is technically correct, the word "significantly"
may give a wrong impression (see below).  Furthermore, there are
some thoughts of loosening those ties.  The problem is that we
haven't found any way to do so without compromising the some
security aspects.  It may be possible in the future, though.

>           *    Creates a new DNS RR entry

Correct.  However, for the time being we will use IPSECKEY,
which is in IESG review, I think.

>           *    Requires a Rendezvous server for mobility support

Well, it requires rendezvous for con-current mobility.  Client
mobility or slow server mobility (with dyndns updates) works
pretty well without any rendezvous servers.  In fact, the
rendezvous function has not been fully specified.

Hence, I would suggest changing "mobility" to "con-current" mobility
(or something equivalent that matches with your overall terminology).

>           *    Requires that NATs be aware of HIP

This was an explicit design choice.  It would be possible to
make HIP work using UDP tunneling, but we chose not to do so.
At least not yet.  If there is real need for that, such support
could be added, but the result would not be pretty any more.

>      Many of the HIP features are appealing, such as the cleanliness
>      of the architectural model depicted in Section 4 of the HIP
>      architecture document.  Were the Internet stack being created
>      now, HIP well might be an excellent approach. 

Thank you.

>      However
>      retrofitting this approach into the existing, deployed Internet
>      entails serious barriers to adoption, such as its dependence on
>      IPSec.

I am not quite sure how serious the alledged barriers are.
HIP does require changes to the stack, yes.  It introduces
a kind of shim or wedge, just like MAST or LIN6.  It does
not work with current NAT boxes, but that has been an explicit
design choice for the time being.

A word about dependence with IPsec.  HIP uses only a small
portion of IPsec, and supports only a small subset of the
current functionality that full IPsec implementations support.
On the other hand, HIP requires virtually no configuration,
while the current IPsec implementations require a considerable
amount of configuration and expertese.

To be more specific, HIP uses ESP as its packet transport
mechanism.  It integrates well with the current IPsec
processing model, and is able to co-exist with other
IPsec based secure connections.  On the other hand, it is
also possible to implement the ESP functions that HIP
requires completely independent on any IPsec code in the
stack.  One of the existing implementations uses this
approach, and contains a user level ESP implementation.

Hence, I don't immeditely see any serious barries for HIP.
But maybe I am blind in this issue.  Well, if you consider
the NAT issue as such, then be it so.  Otherwise I would
fairly strongly disagree with your statement.

>      In general, addition of a DNS SRV record can be useful for
>      achieving efficient rendezvous, with or without mobility.  It
>      permits participants to know whether a service is supported by
>      its partner, without requiring a probe packet.  While beneficial,
>      this enhancement to DNS data structures is not required for
>      multihoming or client (initiator) mobility.

I am not quite sure what the paragraph above has to do with HIP.

--Pekka Nikander

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Sep 2003 06:14:10 -0700

marcelo,

mb> The only considered threat is connection hijacking. I guess there much other
mb> issues to consider.

Thank you for raising this point.  I'll start by commenting that I expected
folks to take exception with the paper, on this matter, and that I think it is
extremely important to have consensus about the security issues that need to
be covered for multiaddressing.

I took an extreme position, in the paper, because I think we need to make sure
that the number and type of security issues are kept to the bare minimum
necessary.

The key question is:  What are security issues are created by
multiaddressing and alter the existing IP security?

mb> However, it is also important to consider the
mb> new threats that the adoption of multi-addressing mechanisms means for other
mb> hosts in the internet (for instance non-mobile, non multi-homed hosts)
mb> For instance, flooding attacks, dos attacks.

However, existing IP is subject to these attacks, is it not?

mb> Other type of attacks should also be considered such as time shifting
mb> attacks.

What is a "time shifting attack"?

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 17 Sep 2003 17:21:32 +0200

> De: Dave Crocker [mailto:[email-masked]]
> Enviado el: miercoles, 17 de septiembre de 2003 15:14
> Para: marcelo bagnulo
> CC: [email-masked]; [email-masked]
> Asunto: Re: multi-addressing review (was:RE: New multiaddressing review
> and new MAST draft)
>
>
> marcelo,
>

Right.
I think that there are other people in the list who can provide a so much
better answer to this question than me...
Anyway, Tony Li's design team has promised a security analysis from a great
expert, so we are waiting.

> However, existing IP is subject to these attacks, is it not?

I think so, but we have to make sure that deploying a multi-addressing
solution just don't enable more of them.

For instance, suppose that you have no security at all and you enable to
send BU to move a connection from an ip address to another.

You can create a flooding attack by just initiating a communication with a
streaming server and then just move to the target host (you can find a
better explanation in section 3.2.1 basic flooding of the ro sec draft)

> What is a "time shifting attack"?

In current ipv4, if an attacker wnats to pretend to be at a given ip address
(steal the address, impersonate, whatever), the attacker must be on place,
intercepting the packets in order to receive them.
However, if you enable something such as BU that allows you to say to the
other node that from now on he must send packets to an alternative address
(i.e. and alternative location), the attacker can divert the traffic to a
more confortable location for him. So the attacker is not required to be on
place during the complete period of the attack. Or in other words, the
attacker can leave the location where it intercepts the packets and still
perform the attack. (Again a much better explanation of this can be found in
the ro sec document section 4.3 Quick expiration of the BCE and section 5.1
Time Shifting attacks)

Regards, marcelo

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Sep 2003 13:07:07 -0700

Pekka,

PN> Firstly, I very much agree with Marcelo wrt. his comment about security.

The key here, is to be clear about the requirements for security. In
particular, I think we need to be diligent in separating the requirements that
are strictly due to adding multiaddressing, versus the changes that are more
generally interesting and useful.

Let me again stress that I'm not trying to make light of those additional
goals, but want to make sure that we are clear that they are additional. If
satisfying those goals imposes significant challenges to the basic design of
multiaddressing support, then the effort for them should be separated out.

>>           *    Creates a new, globally unique name space

PN> You may consider adding "probabilistically", since the only currently
PN> defined type of HIs are public keys. HIP does not assume any key registry,
PN> and therefore the uniqueness of host identifiers is only probabilistic.

Oh.  Thank you. I completely misunderstood this.

>>                overloading some HIP functionality with security 
PN> I am not quite sure about the word "overload".  That is, I don't
PN> quite understand what you imply with it.
PN> HIP was initially designed to solve other identity related problems but
PN> mobility and multi-homing, with strong focus on security. Rudimentary
PN> mobility support was there from fairly early on, but real mobility support
PN> (with rendezvous) and multi-homing came only afterwards, around the time I
PN> joined the HIP gang a couple of years ago. And the exact details for those
PN> are still being worked on.

Your reference to solving "other identity related problems" is what I meant. I
think the scope of HIP has been broader than just enabling multiaddressing.
And I fear that that makes the design more complicated.

>>           *    Is tied significantly to [IPSEC]

PN> Well, while that is technically correct, the word "significantly"
PN> may give a wrong impression (see below).

My point was not about concepts, but about implementation and operation.  So I
think the concern I was raising was that a system cannot use HIP without being
required to also support IPSec.  Is my understanding of this incorrect?

Taking ideas and algorithms from other specs, and even "cohabiting" bits of
functionality can be excellent.  I like to do that as much as possible.

However having implementation and operation dependencies -- especially when
neither service is yet universal -- is problematic.

PN> Furthermore, there are some thoughts of loosening those ties. The problem
PN> is that we haven't found any way to do so without compromising the some
PN> security aspects. It may be possible in the future, though.

I understand.  And that is a strong reason I'm looking to make the
security requirements be as few as is reasonable to support multiaddressing.

>>           *    Creates a new DNS RR entry

PN> Correct. However, for the time being we will use IPSECKEY, which is in
PN> IESG review, I think.

If this is an adjunct feature, then it's probably fine.  If it is required for
the basic service, then it is a barrier to adoption.

>>           *    Requires a Rendezvous server for mobility support

PN> Well, it requires rendezvous for con-current mobility. Client mobility or
PN> slow server mobility (with dyndns updates) works pretty well without any
PN> rendezvous servers.

Cool! Again, I had misunderstood this, and thought that the rendezvous server
was required for basic HIT use.

PN> In fact, the rendezvous function has not been fully specified.

(Feel free to take a look at MAST's latest attempt to suggest one...)

>>           *    Requires that NATs be aware of HIP

PN> This was an explicit design choice. It would be possible to make HIP work
PN> using UDP tunneling, but we chose not to do so. At least not yet. If there
PN> is real need for that, such support could be added, but the result would
PN> not be pretty any more.

My point is that requiring NAT support is a huge barrier to adoption.

>>      now, HIP well might be an excellent approach. 

PN> Thank you.

No. Thank _you_. I've been stymied on this topic for some years, and it was
only the HIP and SCTP/PBK analysis work that made it possible for me to think
about this more.

>>      entails serious barriers to adoption, such as its dependence on

PN> To be more specific, HIP uses ESP as its packet transport mechanism.

Does this not mean that you cannot use HIP unless you also support IPSec?  I
think that is frankly an significant barrier.  (I think that your next
paragraph means that I am misunderstanding this.)

PN> It integrates well with the current IPsec processing model, and is able to
PN> co-exist with other IPsec based secure connections. On the other hand, it
PN> is also possible to implement the ESP functions that HIP requires
PN> completely independent on any IPsec code in the stack. One of the existing
PN> implementations uses this approach, and contains a user level ESP
PN> implementation.

Interesting.

>> In general, addition of a DNS SRV record can be useful for achieving
>> efficient rendezvous, with or without mobility. It permits participants to
>> know whether a service is supported by its partner, without requiring a
>> probe packet. While beneficial, this enhancement to DNS data structures is
>> not required for multihoming or client (initiator) mobility.

PN> I am not quite sure what the paragraph above has to do with HIP.

it probably needs to be moved elsewhere.

Many thanks for the clarifications.

d/

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 23 Sep 2003 19:41:44 +0200

Hi Dave,

> The key here, is to be clear about the requirements for security.

I guess that the goal should be that the resulting Internet (with the
multi-addressing mechanism) should be "as secure as the IPv4 Internet"

This was the design goal for mobileip and many folks have mentioned this
goal on the list, but is there consensus about this?

Thanks, marcelo

---

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Sep 2003 11:08:17 -0700

marcelo,

>> The key here, is to be clear about the requirements for security.

mb> I guess that the goal should be that the resulting Internet (with the
mb> multi-addressing mechanism) should be "as secure as the IPv4 Internet"

Thank you, yes.  This is the right place to start from, in order to make sure
that we are all trying to achieve the right (or same) goal.

mb> This was the design goal for mobileip and many folks have mentioned this
mb> goal on the list, but is there consensus about this?

I suspect that we do have consensus with the statement.  I suspect the
differences in opinion are about what the security of the current IPv4
Internet is.

Most of the features that I have questioned look like they are a good idea.
However they appear to be a) redundant with existing solutions elsewhere in
the stack, and/or b) beyond "the security of the current IPv4 Internet".

d/

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 23 Sep 2003 18:52:02 +0200

>>>               overloading some HIP functionality with security
...
 > Your reference to solving "other identity related problems" is
 > what I meant. I think the scope of HIP has been broader than
 > just enabling multiaddressing.

I understand.  But maybe you should consider rephrasing.
IMHO, the statement is hard to understand.

 > My point was not about concepts, but about implementation
 > and operation.  So I think the concern I was raising was
 > that a system cannot use HIP without being required to
 > also support IPSec.  Is my understanding of this incorrect?

As I tried to point out, you can implement ESP for HIP yourself,
and then you don't need any IPsec support from the underlying
platform.

 > However having implementation and operation dependencies
 > -- especially when neither service is yet universal -- is
 > problematic.

As I tried to clarify, HIP *can* co-exist with other IPsec usage,
and utilize the ESP implementation from IPsec if it is available.
(Some more details on that can be found in the ongoing charter
discussion on the HIP mailing list.)

 > If this is an adjunct feature, then it's probably fine.  If it
 > is required for the basic service, then it is a barrier to adoption.

HIP can be used without any DNS entries, in the so called opportunistic
mode.  However, the details still need some thinking to make the
opportunistic mode more efficient.  On the other hand, storing any
long term HIP public keys into the DNS looks like a good practise,
and shouldn't be too hard.  Most people that can modify their kernel
can also change some (forward) DNS entries, too.

 > My point is that requiring NAT support is a huge barrier to adoption.

With HIP, the NAT issue is really beaty vs. supporting current NAT.
My current, personal preference is to prioritize beaty.  Running the
HIP protocol on the top of UDP instead of IP is not such a big deal,
but running ESP on the top of UDP is pain.  You really should be able
to mux packets based on SPI as well as you can mux them based on
UDP ports.  The trick is to learn the association between the SPIs
in the two directions, and HIP allows the NAT boxes to learn that.

On the other hand, if we do find a way of using HIP without
requiring ESP, then it might make more sense to specify how
to run the HIP protocol over UDP.

 > PN> To be more specific, HIP uses ESP as its packet transport
 > PN> mechanism.
 >
 > Does this not mean that you cannot use HIP unless you also
 > support IPSec?

Second time:  The answer depends on what exactly you mean
with "support IPsec".  The system must implement ESP
(but not AH or IKE or IKEv2 or claim IPsec compliance).
It doesn't much matter whether ESP is implemented as a
part of HIP, or separately by the system.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 23 Sep 2003 18:44:29 +0200

Dave,

> generally interesting and useful.

I completely agree.  On the other hand, I also think that most people
underestimate the security consequences of introducing genuine
multi-addressing, with the capability of changing the addresses on the
fly.  I certainly underestimated it myself before starting to seriously
work on the area.

> multiaddressing support, then the effort for them should be separated out.

Well, the basic differences in terms of cost seems to come from two
sources:
- public key crypto or just hash functions etc
- number of messages and round trips

 From this point of view, HIP can be certainly critisized for relying
on public key crypto, and therefore being heavier than absolutely
necessary.  On the other hand, it is *possible* to use HIP with
very short key lengths, with the obvious (or perhaps not so :-)
consequences.

Complexity wise I don't see any big difference.  There are other
factors that basically necessitate you to use either a three-way
or four-way handshake anyway.  For DoS reasons four-way "stateless"
handshakes seem to be better.  What comes to the complexity of
changes to the stack, there is no big difference.  The real differences,
if any, are in the complexity of the control protocol.  It looks like
that you can't make authenticated Diffie-Hellman with DoS protection
much more simpler than what HIP does.  Hence, the question really is
whether you want to use PK authentication or not, since if you do not,
then you don't need Diffie-Hellman either.

Clarifications about HIP in a separate message.

--Pekka Nikander