Subject: SEND+ND mixed mode (instead of ND to SEND transition)

From: "Tuomas Aura" <[email-masked]>
Date: Tue, 24 Jun 2003 08:18:52 -0700

This is a proposal for a new, simpler transition mechanism. 
(Thanks to Jari Arkko and Dave Thaler for input.)

It is unnecessary to have a separate transition mode. SEND 
hosts are likely to always encounter networks with nodes 
and routers that do not support SEND. They may also be 
connected at the same time to multiple networks and routers, 
some of which are secure and some insecure. Thus, a mixed 
mode with both secure and insecure hosts and routers on the 
same network should be the default mode for SEND hosts. 
SEND nodes should be able to fall back to insecure ND when 
communicating with insecure on-link nodes. Also, routers 
should be able to serve both SEND hosts and insecure hosts.

The key to implementing the mixed default mode is that 
SEND nodes receive both secure and insecure ND and RD 
messages but give priority to secure ones. "Secure" messages 
are ones that contain a valid signature option, and 
"insecure" messages are ones that contain no signature 
option. 

SEND nodes need to send only secure messages. ND nodes 
obviously will send only insecure messages. ND nodes 
will (per RFC 2461) ignore the unknown options and will 
treat secure messages in the same way as they treat insecure 
ones. Addresses, subnet prefixes, interfaces. networks 
are not divided to "secure" and "insecure". 

SEND routers and hosts follow the protocols defined in 
RFC 2461 and RFC 2462 with the following exceptions:

- All solicitations sent by as SEND node SHOULD be secure. 

- Unsolicited Neighbor and Router Advertisements sent by a 
SEND router SHOULD be secure. Solicited advertisements MUST 
be secure if the solicitation was secure, and SHOULD be
secure if the solicitation was insecure. 

- Secure solicitations MUST contain the Nonce option. 
Secure advertisements sent in response to a secure 
solicitation MUST contain a copy of the Nonce option from
the solicitation. Unsolicited advertisements and ones sent 
in response to an insecure solicitation MUST NOT contain 
the Nonce option.

- A SEND node that uses the CGA the authorization 
mechanism for protecting Neighbor Solicitations SHOULD 
perform Duplicate Address Detection (DAD) as follows. 
If DAD indicates the tentative address is already in use, 
generate a new tentative CGA address. If after 3 
consecutive attempts no non-unique address was generated, 
log a system error and give up attempting to generate an 
address for that interface. When performing DAD for the 
first tentative address, accept both secure and insecure 
Neighbor Advertisements received as response to the 
Neighbor Solicitations. When performing DAD for the second 
or third tentative address, ignore insecure Neighbor 
Advertisements. 

- The node SHOULD have a configuration option that causes 
it to ignore insecure advertisements even when performing 
DAD for the first tentative address. This configuration 
option SHOULD be disabled by default. (This is recovery
mechanism for the unlikely case that attacks against the
first address become common.)

- Neighbor Cache, Prefix List and Default Router list 
entries have a secure/insecure flag that indicates whether 
the message that caused the creation or last update of the 
entry was secure or insecure. Received insecure messages 
MUST NOT cause changes to existing secure entries in the 
Neighbor Cache, Prefix List or Default Router List. Received 
secure messages cause an update of the matching entries and 
flagging of them as secure. 

- The conceptual sending algorithm is modified so that an 
insecure router is selected only if there is no reachable 
secure router for the prefix. That is, the algorithm for 
selecting a default router favors reachable secure routers 
over reachable insecure ones.

- A SEND node MAY have a configuration option that causes
it to ignore all insecure ND, RD and Redirect messages. 
(This can be used to enforce SEND-only networks.)

The mixed default mode should make transition much easier 
as it allows gradual transition and it is not necessary to 
phase out insecure equipment, such as printers. There does 
not seem to be any particular disadvantages to the default 
mixed mode. 

As far as I know, the decision to not allow mixed operation 
in the current SEND main draft was made solely because of 
the desire to live with the limitations of IPSec. It is 
straightforward to implement the mixed mode in Jari's 
ND-option-based protocol. 

It might be possible to implement the mixed mode with the 
CGA+AH headers and IPSec API changes proposed by Pekka 
Nikander. The key point here is we must not end up with an 
inferior transition mechanism (as in the current main draft) 
just because IPSec does not support anything better.

Tuomas

--------------------------------------------------------------------
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: Julien Laganier <[email-masked]>
Date: Wed, 25 Jun 2003 11:24:43 +0200

> "insecure" messages are ones that contain no signature

I like the idea of a default mixed mode for SEND. Sounds straightforward to 
deploy.

> just because IPSec does not support anything better.

Some IPsec implementations have a SPD allowing to specify that some traffic 
MAY use IPsec (KAME does that, you can specify 'require' or 'use' for an SPD 
entry). In this case, an incoming packet can be processed by the IPsec layer 
if it is secured via AH and/or ESP, or just bypass the IPsec layer if it is 
not secured. 

On implementation of this type it should not be a problem to implement mixed 
mode SEND. At the opposite It looks difficult to implement this on a 
_standard_ IPsec layer.

Thanks,

--julien

---

From: [email-masked]
Date: Wed, 25 Jun 2003 18:30:41 +0900

>if it is secured via AH and/or ESP, or just bypass the IPsec layer if it is

	while the description about KAME "use/require" is accurate, it does not
	help in the SEND/ND mixture scenario.  if SEND node transmits a packet
	with AH to ND node, ND node will silently discard it (with "unknown
	SPI" logs) as ND node has no key for it.  if SEND mechanism is defined
	as a ND option, such problem does not happen (just as Tuomas described).

itojun

---

From: Julien Laganier <[email-masked]>
Date: Wed, 25 Jun 2003 18:36:41 +0200

[email-masked] wrote :
>
> >Some IPsec implementations have a SPD allowing to specify that some
> > traffic MAY use IPsec (KAME does that, you can specify 'require' or 'use'
> > for an SPD entry). In this case, an incoming packet can be processed by
> > the IPsec layer if it is secured via AH and/or ESP, or just bypass the
> > IPsec layer if it is not secured.
>
> 	SPI" logs) as ND node has no key for it. 

I agree with that, but I need to explain more deeply what I have in mind for 
SEND mixed mod. (more below)

>      if SEND mechanism is defined

I agree.

Let's explain more precisely my thoughts:

On SEND enabled nodes, the SPD specify that link-local communications MAY use 
AH. The SEND layer has an API to make the CGA layer add a CGA header on some 
of the packets sent, and add meta-data to the packet causing it to be 
authenticated by AH. 

On the sending side :

o When a SEND nodes want to send a packet to a non-SEND node, it doesn't 
attach to it the CGA header containing the public key. Thus, the IPsec layer 
will not find any public key for this (SPI, src_addr) tuple, causing the 
packet to bypass IPsec processing and being sent without AH.

o At the opposite, when a SEND nodes want to send a packet to a SEND node, it 
attach to it a CGA header containing the public key used to generate the 
source address of the packet. Thus, the IPsec layer will find the 
corresponding public key (for this SPI, src_addr), and authenticate it with 
AH.

A node wanting to send ND signalling to both secure and insecure nodes could 
send two times the same message, an insecure and a secure one.

On the receiving side :

o a SEND node will receive packets with a CGA header allowing AH to process 
the packet. The SEND layer will find the associated metadata in the CGA 
header. 

o a SEND node will receive packets without a CGA header, nor AH. The SEND 
layer will find not find the associated metadatas, thus being aware of the 
insecure nature of this packet.

o A non-SEND node will receive packets without CGA and AH header, and rejects 
the others.

Thoughts?

Thanks,

--julien

---

From: "James Kempf" <[email-masked]>
Date: Wed, 25 Jun 2003 11:01:47 -0700

> packet to bypass IPsec processing and being sent without AH.

Problem is, some of the packets are multicast (for DAD). These are the ones
that cause the most trouble, since the SEND node needs to monitor whether a
nonSEND node is claiming its address.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Wed, 25 Jun 2003 21:32:28 +0300

> send two times the same message, an insecure and a secure one.

Yes, this looks like it can work. Interesting! But it implies twice
the amount of overhead from ND traffic. How significant is this?
I don't know, but at least it is a factor that should be considered.
In addition, the coupling to IPsec processing is pretty tight.

--Jari

---

From: [email-masked]
Date: Thu, 26 Jun 2003 11:07:27 +0900

>In addition, the coupling to IPsec processing is pretty tight.

	for a receiving SEND-capable node, it would be confusing.
	- if SEND packet comes in then ND, do you want to update ND cache state,
	  or ignore ND?
	- if ND packet comes in then SEND, do you want to create ND cache on
	  receipt of the first ND packet?  what do you do against second packet?

	note that we shouldn't be peeking L2 header so it is not distinguishable
	from (sort of) replay attack.

itojun

---

From: Jari Arkko <[email-masked]>
Date: Thu, 26 Jun 2003 08:07:12 +0300

> 	  receipt of the first ND packet?  what do you do against second packet?

I suppose you'd have to use the same kind of rules as Tuomas
outlined for the ND option case, i.e., an insecure advertisement
should not override a secure one etc. But this requires a tight
coupling between the IPsec and ND code, essentially you have to
be able to tell whether the packet was protected or not, and possibly
even how it was protected.

In addition, sending the same messages twice does not look
very pretty.

All this would be much simpler with the ND option approach.

--Jari