Subject: Thoughts about transition mode

From: Pekka Nikander <[email-masked]>
Date: Mon, 14 Apr 2003 12:02:16 +0300

On last weeks telephone meeting I promised to
write up my thoughts about the transition mode.
Here are now some notes.

For some time already I have had the feeling that
the current transition mode idea, i.e. having two
logically separate links on one physical link, will
not fly.  I still cannot point out the exact reasons,
but my strong intuitive feeling is that there will
be a number of problems.  OTOH, only implementation
work will tell for sure.

As an alternativity, I would promise the following
approach.  I am only considering ND here, Router
Discovery will require more work.

Have two different modes for each link:

1.  Mixed mode.  Allow both SEND and legacy nodes.
     SEND nodes are somewhat vulnerable to downgrading
     (aka bidding down) attacks by attackers claiming
     to be legacy nodes.

2.  Secure mode.  All SEND nodes ignore the legacy
     nodes.  At the ND level, SEND nodes defend their
     IP addresses against legacy nodes/attackers, but
     do not participate in legacy traffic otherwise.

The mode selection is a configuration switch.
All SEND nodes MUST implement both modes, and
the default configuration SHOULD be mixed mode,
for the time being.

Defending addresses
-------------------

In both modes all SEND nodes MUST reply to unproteced
NS queries with both an AH protected and AH unprotected
NA.  That is, if a SEND node receives an unprotected
NS that refers to any of its addresses, it will send two
replies:  One contains a normal, legacy NA, and the other
one sem same NA, protected with AH.

Mixed mode
----------

In this mode SEND nodes keep track of the other nodes on
the link, and whether they are SEND nodes or not.  Basically,
if another node is a SEND node, its public key is recorded
in the Neighbor Cache.  The mere presense of the public
key is enough to signal that the node is a SEND node.

If the node needs to garbage collect Neighbor Cache
entries, it should avoid garbage collecting SEND ND
entries.  Otherwise an attacker would be able to fill
the ND with new entries, forcing the SEND node entries
to be flushed, etc.

When a SEND node wants to get the link-layer address of
another node, it first sends an AH protected NS.  If it
does not receive any reply within RetransTimer/10
milliseconds, it sends an unprotected ND.  Since the default
RetransTimer is 1000 milliseconds, this causes an 100 ms
additional delay in contacting non-SEND hosts.  I think
this is acceptable.  If retransmissions are required,
the node behaves as if it were doing both the AH protected
and unprotected address resolutions at the same time,
RetransTimer/10 milliseconds apart.  That is, it always
sends first an AH protected NS, and then RetransTimer/10
milliseconds later an unprotected one.

If a SEND node receives an AH protected NS, is simply
replies with an AH protected NA.

If a SEND node receives an unprotected NS, is replies
first with an AH protected NA, and a few milliseconds
after that with an unprotected NA.  10 ms delay is
probably ideal for most environments, but we may need to
do some simulation or experiments.

DAD is an interesting question here.  I will not touch
it since we cannot use AH for DAD right now.

Secure mode
-----------

In this mode SEND nodes keep track only about other
SEND nodes.  They ignore all unprotected messages
other than unprotected NS messages, which they MUST
reply to in order to protect their addresses.

As a result, legacy nodes may try to send traffic
to SEND nodes, but SEND nodes will not reply since
they do not "see" the legacy nodes on the link.
This is perfectly acceptable, since the purpose of
this mode is to ignore the legacy nodes and pretend
that they do not exist.

-----------------------------------------------------

I know that implementing this is not as easy as the
currently proposed implementation is.  In effect,
the implementation requires a fairly rich API between
the ND layer and the IPsec layer, allowing the ND
layer to receive and send both protected and unprotected
packets.  In other words, the IPsec layer must include
meta data in the packets so that the ND layer can
learn the public key of the other SEND nodes.  Respectively,
the ND layer must be able to inform the IPsec layer
whether to protect a given packet or not.

I do not think this is too hard.  We have to remember
that to implement SEND one has to change the IPsec
implementation anyway.  In the case where it is undesirable
to change the IPsec policy implementation, the actual
policy can be implemented in the SEND SA code.  That is,
one can configure IPsec to use AH always for ND/RD packets,
but the actual AH SA code would pass up also unprotected
packets and would allow sending unprotected packets.

Thoughts?

--Pekka

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Claude Castelluccia <[email-masked]>
Date: Mon, 14 Apr 2003 11:39:42 +0200

>      (aka bidding down) attacks by attackers claiming

Hello Pekka,
The bidding down attack can be prevented by embedding the
address type in the address itself?

For example if it is decided that legacy addresses have the
lowest bit set to 0 and the SEND addresses have the lowest
bit set to 1, the bidding down attack can not be performed...

Is that right?

cheers,
Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 14 Apr 2003 14:02:36 +0300

> address type in the address itself?

Depends on the design details.  Currently we (the DT) do not
want to make the SEND and non-SEND nodes to live in totally
separate name spaces.  If we wanted that, the easiest way would
be to use a separate link local prefix, and we could use
the transition mode as currently defined in -00.  However,
I don't like that solution, and therefore I wrote the note.

Note also that I write "somewhat vulnerable".  That is, it
looks like the vulnerabilities would probably be quite minor.
However, the details need to be worked out before we can
really evaluate the situation.

> bit set to 1, the bidding down attack can not be performed...

As far as I can see, that would fix the problem.  In practice,
though, we would either need a separate link local prefix or
take in to use the u and g bits in the IID.  For a number of
reasons (some of which I don't even remember), we don't want
to do that, if possible.

If we need to take the road of having different address spaces
for SEND and non-SEND nodes, the easiest way is probably to
allocate a second link local prefix for SEND nodes, and to
use different routing prefixes for SEND and non-SEND nodes.
Then we would have two logically completely different links,
just like what is currently defined in the draft.

The biggest problem with the separate link local prefix is
that SEND nodes would not be able to talk to non-SEND nodes
without the help of a router.  That would make the transition
harder, requiring the routers to be updated first, since one
could not be able to use SEND before there is a router that
supports SEND.  With the mixed mode, one can use SEND independent
on whether there is a SEND capable router or not.

I don't remember the problems with u and g, but I think they
were more related to the difficulty of assigning the bits
than anything technical.

--Pekka Nikander