Subject: Allocating a bit in the RFC2437 Interface Identifier

From: Pekka Nikander <[email-masked]>
Date: Wed, 20 Mar 2002 13:18:49 -0600

As discussed at the mobile-ip WG meeting on Tuesday morning, in length
at the mobile-ip mailing list, and in some length at the this mailing
list, there has emerged a need to encode functional, security related
semantics into IP addresses.  The purpose of this short note is to try
to describe the situation in general terms, thereby giving *background*
to the discussion on Thursday at the ipv6 WG meeting.

Note that the discussion on Thursday morning is about *reserving*
space in the interface ID for possible future extensions.  This note
is about a possible *use* of part of that space.  It makes sense
keeping the discussion of whether or not to reserve space separate
from the discussion about use.

The situation
=============

Consider two hosts, Alice and Bob, that do not know each other.  For
some reason, Alice wants to contact Bob.  Thus, she goes to DNS (or
whatever), learns Bob's address, and sends a packet (e.g. TCP SYN) to
Bob.  Bob receives the packet and starts processing it.

Now, when Bob receives the packet sent by Alice, he has no other
knowledge about Alice but the packet itself.  In particular, the only
information he has about Alice is the source IP address in the packet.
However, there seem to be situations (I'll return to them in a moment)
where he needs to learn a little bit more about Alice before he can
answer in a proper way.  Clearly, Bob has a few options how he can
proceed and learn more about Alice:

  a) He can go to DNS, do a reverse lookup, and hope to learn something
     useful.  However, this may be expensive in terms of time and
     number of packets, causing packets sent to the DNS server that
     serves the reverse map for Alice's address, and thereby somewhat
     dangerous from the Denial-of-Service point of view.  Additionally,
     secure DNS is not widely deployed, and therefore he usually can't
     fully trust the results.  Anyhow, this is the method that most
     hosts use today.

  b) He can try to use some other infrastructure, such as AAA, and try
     to get some information about Alice from there.  However, this
     method requires that Alice participates in the same
     infrastructure, which, in general, is unlikely for a number of
     years to come.  Secondly, this method has the same drawbacks as
     DNS lookups, generating delay and extra traffic.

  c) He can send a probe to Alice, checking that there indeed is
     somebody who answers in the said address.  TCP SYN ACK is
     basically such a probe, and so are the new Mobile IPv6 RR packets
     (HoTI, CoTI, HoT, CoT).  The drawback of this method is that
     doesn't *prove* anything else but that Alice (or somebody
     impersonating her) is really there (which is an important
     property, but orthogonal to the other the other pieces of
     information about Alice).

  d) He can have a look at the address, and try to deduce something
     from the address itself.  Currently, he can learn whether Alice is
     using a link local, site local or global address, whether Alice's
     address is supposed to contain a globally unique interface ID,
     etc.

Now, the whole need and idea is to extend d) so that Bob can learn
more about Alice by just looking at the address.  This would be very
benefial for busy servers, and especially in situations where the
server may be facing a resource exhausting denial-of-service attack.
Note, however, that extending d) does not mean, in any way, that the
other options could not or should not be used in the future.

Security point of view
======================

Security is a very important issue here.  Firstly, as will be
discussed below, there are situations where the method must be
resistant to resource consumption amplifying denial-of-service
attacks, basically ruling out DNS and AAA/other infra in those
situations.  Secondly, there are situations where the information
about Alice must be reliable, i.e. authentic and integral.  Secure DNS
and AAA could fulfil this latter need, but only at the expense of
added delay & traffic, and possible DoS/reflection, as noted above.

The need for reliable information is especially important for security
protocols.  Here we come to the so called "bindding down" argument.
That is, let us assume that there exist some default security protocol
that all IPv6 hosts are assumed to support.  Furthermore, let us
assume that there *does* exist some more secure protocols for the same
purpose, but some hosts do not support these more secure protocols,
for example, since the more secure protocols impose more computational
requirements or are otherwise more costly.  In this situation the
hosts must be able to do a selection between the default, less secure
protocol and the more secure protocols.  That is, if Bob supports both
the default protocol and (at least one) more secure protocol, he must
be able to determine if Alice supports the more secure protocol so
that he can take the more secure protocol into use.  Furthermore, he
cannot ask Alice, since an attacker impersonating as Alice would lie,
and say that Alice supports only the default, less secure protocol.

In other words, there must be a method, independent on Alice's
actions, that securely gives Bob reliable information about the
protocols Alice supports.  If such a method does not exist, and there
is an attacker that can break one of the protocols, the attacker can
claim that Alice supports only the protocol that it is able to break,
thereby making it impossible for Bob to use the other more secure
protocols.

This is the essense of the bidding down attack:  an attacker that is
able to break one of a number of security protocols can impersonate
Alice to Bob unless Bob can learn, independent of Alice, what
protocols Alice supports.

See http://playground.sun.com/mobile-ip/WG-archive/frm05357.html
and http://www.piuha.net/~jarkko/publications/mipv6/Bidding_down.txt
for more details.

Note that with respect to the bidding down attack the discussing about
allowing Bob to determine, by looking at the address, whether Alice is
satisfied with the default protocol or not.  That allows Bob to
continue quickly in the default case.  What to do, in exact terms, in
the non-default case (other than not using the default protocol) is
beyond the scope of this note.  Especially, we are *not* suggesting
that there should be additional bit(s) reserved for specific needs.

Specific needs
==============

Currently there seems to be only one situation where we want to
introduce a default, not-so-good-but-good-enough security protocol
that anybody can use, with the anticipation that in the future there
will be a number of better-and-more-secure variants.  This is the
Mobile IPv6 situation, where Return Routability (RR) will be the
baseline security protocol.  However, the situation is in no way
specific to Mobile IP.  There will clearly be other needs too, e.g.,
secure multicast or anycast might have the same need.

In the case of Mobile IP, we definitely want to have a method where it
is possible to tell whether a given Mobile Node wants to use RR or
not.  In this case, the most secure security protocol is to disallow
the function completely, i.e., say that Mobile IP Route Optimization
MUST NOT be used for this host.  For example, stationary hosts most
probably want to forbid Mobile IP Route Optimization.  However, if we
want universal deployment for Mobile IPv6, the default clearly cannot
be to disallow Mobile IP.  Instead, the default case clearly needs to
be the lowest common denominator, Return Routability (RR), and it is
up to each host to separately indicate when it wants to use some more
secure protocol, including the no-RO at all choice.

The suggestion
==============

Now, Mobile IPv6 Security Design Team has discussed whether it would
be possible to allocate a bit (or a bit pattern) on the IPv6 64 bit
Interface Identifier field, with the intention of later defining a
method that allows peer hosts to securely find out what security
protocols, and perhaps other functional features, the host using the
address supports.  That is, if the bit is cleared, the host is happy
to rely on the default security protocols and semantics, as defined in
the base IPv6 RFCs.  Thus, its peers are allowed to use the default
semantics and protocols when dealing with this host.  If the bit is
set, on the other hand, the host instructs its peers that the host is
not happy with the default semantics and protocols, and instructs the
peers to look for more information.  The exact way of how to look for
this information is to be defined later.

Note that an active attacker at the path between Alice and Bob is able
to clear a set bit.  However, that changes the address, and Alice is
not going to answer to any possible replies sent by Bob.  Thus, the
bit prevents the attacker from impersonating as Alice and fooling Bob
to use the less secure protocol.

The immediate intention at the mobile-ip WG is to the define the
Return Routabilility (RR) security method as the default Mobile IP
Route Optimization methods, to be used by all hosts that have the said
bit cleared.  If the bit is set, the corresponding hosts must go to
find out what Mobile IP security method the mobile node supports.  If
the corresponding node cannot find out this information securely, it
MUST NOT use Return Routability.  This effectively blocks the bidding
down attack, as discussed above.

--Pekka Nikander
   on the behalf of the MIPv6 Security Design Team

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Mar 2002 21:02:47 +0100

Can you change the subject: RFC 2437 is PKCS #1 ???

[email-masked]

PS: IMHO we should serialize reservation and use, so I'll read
your message just after Erik presentation+discussion tomorrow!
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Mar 2002 15:11:39 -0500

> there has emerged a need to encode functional, security related
> semantics into IP addresses

I strongly disagree.

there has been a longstanding need to encode functional security
related semantics into IP packets.

but the address is entirely the wrong place for these.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Mar 2002 22:56:45 +0100

> but the address is entirely the wrong place for these.
I must say I don't understand the reference to RFC2437...
presumably you mean 2374, which will be obsoleted anyway.

In which case, I violently agree with Keith. We've already
overloaded IP addresses with two functions - locator and
identifier. We've been rebuffing various suggestions for
yet more overloading for years (the porno bit for example) and
this is in the same category - not the right place to put a security
hint. It's quite inappropriate to damage the opaqueness of a pure ID
field in such a way. If a security hint is needed, it should be somewhere
else.

On a practical point, I don't see how this fits with the addressing
architecture (draft-ietf-ipngwg-addr-arch-v3-07.txt) which requires
that "For all unicast addresses, except those that start with binary 
value 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format." It also doesn't fit with
the RFC 3041 privacy extensions.

  Brian

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 20 Mar 2002 16:23:20 -0600

> presumably you mean 2374, which will be obsoleted anyway.

2437 was a mistake, pardon my poor sleep deprived brain.
The subject line should now have the right reference.

> field in such a way. If a security hint is needed, it should be somewhere

A security hint is needed.  Please read the "bidding down" notes
to see why.  For reference, here are the URLs again:

http://playground.sun.com/mobile-ip/WG-archive/frm05357.html
http://www.piuha.net/~jarkko/publications/mipv6/Bidding_down.txt

If you don't agree with the argumentation, please let us know,
in detail, where you disagree.

What comes to the method of passing the hint, I (and the whole
design team) really wish the hint could be placed somewhere
else.  However, we just haven't been able to find such a way.
We would be more than happy to use some other method, but we
just haven't been able to find one, given the constraints.

> the RFC 3041 privacy extensions.

I'll let Erik to address this one, my knowledge fails here.

--Pekka

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Mar 2002 00:29:47 +0200 (EET)

On Wed, 20 Mar 2002, Brian E Carpenter wrote:
[snip]
> yet more overloading for years (the porno bit for example) and
[snip]

Hmm.. interesting piece of history.  Any references? :-)

P.S. wouldn't at least 2 bits been necessary, for unrated, X, XX, and 
XXX-rated porn? :-)

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Mar 2002 00:17:39 +0100 (CET)

Brian,

> field in such a way. If a security hint is needed, it should be somewhere

Three - not two.
In addition to locator and identifier we also effectively encode 
how the interface ID part is allocated (by having the universal/local
bit in there.)
Pekka's proposal (that has been discussed in the mobile-ipv6 context)
essentially extends the ability to encode how the interface ID has
been allocated to carry additional information.
Basically when the bit is set to say "don't use non-default semantics"
it would involve some checks against the interface ID.

It would be most useful if folks could read the URLs that Pekka pointed
so that we can gain a better shared understanding of the security issues
involved.

> the RFC 3041 privacy extensions.

I sent an email to the ipng list on titled
	Reserving bits in RFC 2473 Interface IDs?
on March 4th.
Since the above comment seems to be about that email I'd appreciate if you 
could recast it as a comment against that email.

  Erik

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Mar 2002 18:50:58 -0500

> http://www.piuha.net/~jarkko/publications/mipv6/Bidding_down.txt

I'd have to have more background to be sure I understand what's being
discussed.  But the bidding down argument is familiar from other 
contexts - for instance, security negotiation in SMTP, security 
negotation by failing over from an SSL port to another port that
doesn't use authentication, indicating security by using an "s"
suffix on a URL type.  From the results of those discussions, I'm 
highly doubtful that allocating an address bit fixes the problem.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Mar 2002 15:15:58 +0100

Erik,

As I recall we didn't define the U/L bit ; the IEEE did, and we decided
to invert it. And I thought the U/L bit was only part of the ID allocation
mechanism more than anything else. It has an unfortunate side effect of
appearing to add semantics to the identifier field, but I don't think it
really does so.

In your March 4 mail you wrote 

> RFC 2373 does not have any way
> to introduce or identify new types of interface IDs that can be
> identified syntactically by just looking at the interface ID.

Correct, and this is exactly how an identifier field should be
-opaque, no syntax, no semantics. That is my whole point.

    Brian

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Mar 2002 15:25:58 +0100 (CET)

> appearing to add semantics to the identifier field, but I don't think it

Without going into history, the current state 
is that the U/L bit has semantics in the sense that we point out [somewhere]
that e.g. future transport protocols might use the knowledge that
the interface ID is globally unique when the U bit is set.

> -opaque, no syntax, no semantics. That is my whole point.

FWIW we seem to, for whatever reasons, already have embarked on the path
of having semantics associated with the interface ID.

While I'm not advocating removing the U/L bit, it sure would be interesting
to know whether we think assigning the globally unique semantics is 
a bad idea. If so perhaps we should make it clear that U=1 means
"assigned by the IEEE according to EUI-64" and nothing more.
My interpretation is that this is not the current state of things.

  Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Mar 2002 16:07:35 +0100

Erik Nordmark wrote:
...
> we point out [somewhere]
> the interface ID is globally unique when the U bit is set

I seem to recall some discussion that this was broken since the U
bit is not totally trustworthy - this relates of course to the
8+8 debate. 

  Brian

---

From: Robert Elz <[email-masked]>
Date: Sat, 23 Mar 2002 01:53:28 +0700

Date:        Thu, 21 Mar 2002 15:25:58 +0100 (CET)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <[email-masked]>

  | Without going into history, the current state 
  | is that the U/L bit has semantics in the sense that we point out [somewhere]
  | that e.g. future transport protocols might use the knowledge that
  | the interface ID is globally unique when the U bit is set.

Yes, that is written down, but nonsense written down is still nonsense.
A IID does not become globally unique just because it has the U bit set,
and any future protocol that attempted to assume that it did would be
quite rightly laughed out of the I-D directories (if it even made it
that far).

There can never be such a protocol, the very idea is ludicrous - those
words should be deleted from 2373bis.

  | FWIW we seem to, for whatever reasons, already have embarked on the path
  | of having semantics associated with the interface ID.

There's nothing wrong with that, when people are agreeing to make use
of them (it isn't a very good choice, but people can do what they want with
their addresses).   What you can't do is take some random address, and assume
anything at all about it (other than the way to route to it) merely from its
bit pattern (nb: issues of link local, site local, IPv4 mapped, ... are all
related to "how to route to it").

  | While I'm not advocating removing the U/L bit,

No, it serves a useful purpose, when we define when it should be set,
and when it shouldn't - and allows better interoperation between 
implementations that all follow those standards.   The problems only come
when we pretend we can interpret what it means when we see it, as distint
from set it (or not) to achieve a particular outcome.

  | it sure would be interesting
  | to know whether we think assigning the globally unique semantics is 
  | a bad idea.

It isn't that it is a bad idea, it is that it is an impossible idea.
It might actually be nice to know if the IID is globally unique, but
there's no way you can discover that.

I have been pondering collecting the IIDs of all nodes I communicate with
and using those exact same IIDs in addresses I assign...   Guaranteed
non-unique IIDs (with the U bit in either state).   There's nothing anyone
can do to prevent me from doing that.   Except if yours happens by some
fluke to be one of the IIDs I make use of, there's not any way for you
to tell that an address has been formed that way.

  | If so perhaps we should make it clear that U=1 means
  | "assigned by the IEEE according to EUI-64" and nothing more.

No, that's not right either.   U=1 *means* nothing at all.   Or no more
than if the bit to the left of it (in the normal printed representation,
that is, not the G bit) is set.   It is just a bit.

But it is a bit that we set when we make use of an EUI-64 for creating
an address, and don't set otherwise - and which thus, when we create the
address, is extremely unlikely to be a duplicate on the link.  That is,
we set (or clear) it to achieve a purpose - once that has been achieved,
we cannot read any more into the address (bit) than that.

  | My interpretation is that this is not the current state of things.

Probably not - but that's because people seem to be dreaming of some
state where they could tell that this IID was unique, and use it without
its prefix in some (currently unstated) way.   If it were possible, that
would be nice.   It just isn't possible.

kre