Subject: Re: [savi] A few comments on draft-vogt-savi-framework

From: Eric Levy-Abegnoli <[email-masked]>
Date: Mon, 02 Nov 2009 11:28:13 +0100

Christian,

Christian Vogt a écrit :
> On Oct 28, 2009, marcelo bagnulo braun wrote:
>
>   
>>> For this case, we need a prioritization of which address assignment
>>> methods take precedence over which other address assignment methods.
>>> And you are right that the definition of this prioritization will
>>> require care.
>>>
>>>       
>> yes, moreover, we need to figure if it is enough with a prioritazation
>> or we need to change the mechanisms in order to interact properly.  
>> As i
>> stated earlier (and eric noted before me), we certainly need to update
>> send savi to properly interact with the slaac savi (at least, haven't
>> doen the analysis for dhcp savi yet)
>>     
>
> Correct; the prioritization may affect the protocol specifications
> (SLAAC, DHCP, SEND) just as well as it affects the framework document.
>
> My suggestion -- as a working group member, not as a chair -- is that
> the framework document should talk about the prioritization
> conceptually, whereas the protocol specifications need to include the
> details that implement the prioritization.  Thoughts?
>
>   
I don't see much value in a document that describes things at the 
"conceptual" level without looking at the details of address assignament 
methods.
Its going to be very confusing if each "protocol" document describes the 
prioritisation of binding entries from it's own point of view.
So far, I see s 1)SLACC 2)DHCP 3)CGA 4)MANUAL (static binding) 5) LOCAL 
(L3 addresses configured on the L2 device). And then there are 
combinations. For instance CGA is relatively orthogonal to the protocol 
(SLACC, MANUAL, DHCP, etc...).
I thought the very purpose of the framenwork document was exactly to 
describe those interactions, which include prioritzation, but also 
protocol interactions. This draft addresses none of this. Does that mean 
we need a document that describe the interactions?  That could be 
draft-levy-abegnoli-savi-plbt-01 
<https://datatracker.ietf.org/drafts/draft-levy-abegnoli-savi-plbt/>. I 
had given up on it, hoping the framework document would cover the same 
topic. So far, it does not.
Eric

> - Christian
>
>
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>
>

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Mon, 02 Nov 2009 11:41:57 +0100

Christian,

Christian Vogt a écrit :
> Alberto -
>
> As a member of the working group, not as its chair:  You are right  
> that co-existence scenarios need to be handled.  But I'm not sure that  
> coexistence requires /special/ behavior.  As long as the behavior  
> desired for coexistence scenarios does not preclude the behavior  
> desired for non-coexistence scenarios, I think coexistence should be  
> covered by the /regular/ behavior of the various SAVI protocol  
> specifications.  That is, in the particular case of SLAAC/SEND co- 
> existence, I think we should strive for a SAVI SEND protocol that can  
> handle non-SEND-capable SAVI devices.
>   
As we are centralizing the co-existence decisions in a 
"man-in-the-middle" savi-device, we can't just consider that the 
capability of the savi-device (SeND, not SeND) are it's sole problem. 
Which "looks" the case if the co-existence scenarios are described in 
the savi-SeND protocol specification.
A savi device not SEND-capable breaks RFC3971. Like a bridge that would 
mess with L3 messages. And it has no way to know. Can we **really** 
specify that? There might be thousands of non-SeND capable nodes on the 
link, and just one signle pair of SeND nodes, and this SAVI-switch in 
the middle is completely messing with their "standard" behavior.  Note 
that there **are** such deployments out there. And the deployments 
scenarios are exactly that (few SeND critical nodes, many non-SeND).
So I think the description of this scenario, and associated warnings 
should show up either in all documents, or in a higher level doc( 
framework, or other).
Eric
> Does this make sense?
>
> - Christian
>
>
>
> On Oct 29, 2009, at 3:04, Alberto García wrote:
>
>   
>> My opinion is that priorization is not enough.
>> I think we need to define "operation modes" (SEND-only, SLAAC-only,
>> SEND-SLAAC-compatible...) and describe the state machine for each one.
>>
>> To support the idea of why we need a new state machine for SEND-SLAAC
>> compatibility, i.e. for a domain in which both SEND hosts and non- 
>> SEND hosts
>> coexist, just consider what a node should do (extending naturally the
>> current FCFS and SEND proposals) if a SAVI device is in NO_BIND  
>> state, and a
>> data packet (not DAD NSOL) is received, from a Validating port VP.  
>> In this
>> case, the SEND SAVI device should send
>> 	- 2 (unsecured) NSOL messages through Trusted ports (according to
>> FCFS SAVI)
>> 	- and a secured NUD NSOL message through the Validating Port
>> (according to SEND SAVI
>> 	And The state is moved to TENTATIVE.
>>
>> In the TENTATIVE state, the SAVI device should maybe wait long  
>> enough (a
>> RetransTimer, which is the waiting time for NUD operation) for a  
>> secured NUD
>> NADV even if an unsecured DAD NSOL is received from a trusted port  
>> in the
>> meanwhile, to assure that SEND validated addresses have priority over
>> non-SEND addresses. [Note that this may occur if a SEND host has one
>> collision when performing DAD for an address, and it is not  
>> withdrawing the
>> second address if an unsecured DAD NSOL is received for it, as RFC  
>> 3971
>> says].
>> Different states should be defined (VALID_SEND, VALID_NON_SEND), with
>> different behavior when the valid_timeout expires.
>>
>>
>> So I don't think this is just "ships in the night", but different  
>> modes
>> should be defined to integrate all the possible combinations of  
>> address
>> configuration mechanisms. Maybe one of these modes should be the  
>> default
>> one, but the administrator could set the SAVI devices to the  
>> appropriate
>> mode (well, they also have to define which ports are trusted or  
>> not...).
>>
>> Does this make sense?
>> Regards,
>> Alberto
>>     
>
>
>

---

From: Alberto García <[email-masked]>
Date: Mon, 2 Nov 2009 15:34:10 +0100

Hi

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de
Eric
|  Levy-Abegnoli
|  Enviado el: lunes, 02 de noviembre de 2009 11:42
|  Para: Christian Vogt
|  CC: SAVI Mailing List; Alberto García
|  Asunto: Re: [savi] A few comments on draft-vogt-savi-framework
|  
|  Christian,
|  Christian Vogt a écrit :
|  
|  	Alberto -
|  
|  	As a member of the working group, not as its chair:  You are right
|  	that co-existence scenarios need to be handled.  But I'm not sure
that
|  	coexistence requires /special/ behavior.  As long as the behavior
|  	desired for coexistence scenarios does not preclude the behavior
|  	desired for non-coexistence scenarios, I think coexistence should be
|  	covered by the /regular/ behavior of the various SAVI protocol
|  	specifications.  That is, in the particular case of SLAAC/SEND co-
|  	existence, I think we should strive for a SAVI SEND protocol that
can
|  	handle non-SEND-capable SAVI devices.
|  
|  
|  As we are centralizing the co-existence decisions in a
"man-in-the-middle" savi-
|  device, we can't just consider that the capability of the savi-device
(SeND, not
|  SeND) are it's sole problem. Which "looks" the case if the co-existence
scenarios
|  are described in the savi-SeND protocol specification.

I don't understand this. What's the problem with a situation in which the
manager of the network configures SAVI devices...
- in SLAAC-only mode if it knows no SEND hosts are there
- in SEND-only mode if it knows all hosts are SEND
- in SLAAC-SEND-compatible mode if it knows the network has SEND and no SEND
hosts.
I assume that deploying SAVI is going to require some management (we have
assumed that when stating that there are roles such as Trusted and
Validating). For SEND even more configuration is required in the SAVI
devices (i.e. trust anchors). 
SEND hosts also need to be configured with trust anchors for processing
correctly secured RADV. (well, the manager may not know if two hosts
configure CGAs just for communication among themselves, but, is this the
general case? )
So, the manager will provide the appropriate SAVI operation mode. 

In addition, the compatible mode should work fine for both types of hosts. A
manager with SAVI devices capable of this, and with any suspicion that a
SEND host may appear, may set up the SAVI devices to be in this mode. 

Do you think this deployment model for SAVI is reasonable?

|  A savi device not SEND-capable breaks RFC3971. 
Yes, so when a SEND host exists, SAVI must be SEND enabled.

|  Like a bridge that would mess
|  with L3 messages. And it has no way to know. 

This is where I kindly disagree.
Regards,
Alberto

|  Can we **really** specify that?
|  There might be thousands of non-SeND capable nodes on the link, and just
one
|  signle pair of SeND nodes, and this SAVI-switch in the middle is
completely
|  messing with their "standard" behavior.  Note that there **are** such
|  deployments out there. And the deployments scenarios are exactly that
(few
|  SeND critical nodes, many non-SeND).
|  So I think the description of this scenario, and associated warnings
should show
|  up either in all documents, or in a higher level doc( framework, or
other).
|  Eric
|  
|  
|  	Does this make sense?
|  
|  	- Christian
|  
|  
|  
|  	On Oct 29, 2009, at 3:04, Alberto García wrote:
|  
|  
|  
|  		My opinion is that priorization is not enough.
|  		I think we need to define "operation modes" (SEND-only,
SLAAC-
|  only,
|  		SEND-SLAAC-compatible...) and describe the state machine for
|  each one.
|  
|  		To support the idea of why we need a new state machine for
|  SEND-SLAAC
|  		compatibility, i.e. for a domain in which both SEND hosts
and
|  non-
|  		SEND hosts
|  		coexist, just consider what a node should do (extending
naturally
|  the
|  		current FCFS and SEND proposals) if a SAVI device is in
|  NO_BIND
|  		state, and a
|  		data packet (not DAD NSOL) is received, from a Validating
port
|  VP.
|  		In this
|  		case, the SEND SAVI device should send
|  			- 2 (unsecured) NSOL messages through Trusted ports
|  (according to
|  		FCFS SAVI)
|  			- and a secured NUD NSOL message through the
|  Validating Port
|  		(according to SEND SAVI
|  			And The state is moved to TENTATIVE.
|  
|  		In the TENTATIVE state, the SAVI device should maybe wait
long
|  		enough (a
|  		RetransTimer, which is the waiting time for NUD operation)
for a
|  		secured NUD
|  		NADV even if an unsecured DAD NSOL is received from a
trusted
|  port
|  		in the
|  		meanwhile, to assure that SEND validated addresses have
priority
|  over
|  		non-SEND addresses. [Note that this may occur if a SEND host
|  has one
|  		collision when performing DAD for an address, and it is not
|  		withdrawing the
|  		second address if an unsecured DAD NSOL is received for it,
as
|  RFC
|  		3971
|  		says].
|  		Different states should be defined (VALID_SEND,
|  VALID_NON_SEND), with
|  		different behavior when the valid_timeout expires.
|  
|  
|  		So I don't think this is just "ships in the night", but
different
|  		modes
|  		should be defined to integrate all the possible combinations
of
|  		address
|  		configuration mechanisms. Maybe one of these modes should be
|  the
|  		default
|  		one, but the administrator could set the SAVI devices to the
|  		appropriate
|  		mode (well, they also have to define which ports are trusted
or
|  		not...).
|  
|  		Does this make sense?
|  		Regards,
|  		Alberto
|  
|  
|  
|  
|  
|  	_______________________________________________
|  	savi mailing list
|  	[email-masked]
|  	https://www.ietf.org/mailman/listinfo/savi
|  
|  
|

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Mon, 02 Nov 2009 16:01:59 +0100

Alberto,
> devices (i.e. trust anchors). 
It is not realistic to expect that the operator will know **all** 
end-nodes capabilities. There might be thousands of them,
(I know an enterprise which as 100,000) and they could show up or 
disappear at n a very dynamic pace.
Also, there is an organisation issue; quite commonly, the network in 
controlled by one entity, the end-nodes by a different one.
Security so far is mostly dealt with by end-nodes, not network 
elements.  If we move some security feature out of the end-nodes
into a network box, we must insure it does at least an equivalent job.

For CGA, no provisionning (trust anchor) is required what-so-ever. So 
the SAVI has no other way to know than to look at
the CGA option.
> So, the manager will provide the appropriate SAVI operation mode. 
We are talking about address assignment, right? Then CGA does not 
require any centralized provisionning of any kind.
In particular no trust anchor.
> Do you think this deployment model for SAVI is reasonable?
There are many situations where he will not know. We (SeND) have 
designed a distributed protocol where end-nodes can
take care of their own security. And now by centralizing some of the 
security, we (SAVI) are breaking this model.
I think this is going to be a SeND (or at least CGA) killer. Once 
someone have deployed a bunch of SAVI switches, it won't be possible
anymore to deploy SeND on any subset of end-devices.
Eric

---

From: Christian Vogt <[email-masked]>
Date: Mon, 2 Nov 2009 12:38:43 -0500

On Nov 2, 2009, Eric Levy-Abegnoli wrote:

> A savi device not SEND-capable breaks RFC3971.

Let's be a bit more specific here.  In what way would a non-SEND-capable
SAVI device break RFC 3971?  Alberto has mentioned one case -- when a
SEND host's DAD fails for the second time due to an unsecured Neighbor
Advertisement, then the SEND host will configure the IP address, yet a
non-SEND-capable SAVI device would block the IP address.  Is this the
issue you are referring to?  Then we should discuss whether or not this
is acceptable.  Or are there more issues you are thinking of?

- Christian

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Tue, 03 Nov 2009 09:53:24 +0100

> is acceptable.  Or are there more issues you are thinking of?
The sole purpose of CGA is to enable a CGA-capable node to prefer 
CGA-prooved NDP message over a none prooved one.
If the savi device does first-come-first-serve, and is not able to 
verify (and prefer) CGA credentials, then there are plenty of scenarios
where it will keep the non CGA owner entry and discard traffic from the 
legitimate: basically all scenarios where the non-CGA came first.

But I consider keeping the bogus entry is not the worse. It also 
prevents CGA-capable nodes to make a RFC3971 proper decision, by not
showing them messages from the legitimate owner, provided that it came 
second.

This is **not** a theoritical issue. I'll give you one scenario (you 
asked for it :)):

1) A CGA-capable node N (typically a critical host, such as a server or 
a router) gets its address X in the savi binding table
2) an attacker M spots X -easy, it's multicast in NA -. He sends DAD NS 
every minute for target X. As long as N is there,
   he gets the NS, responds with NA and that's legal.
- In parallel, M computes X' (easy), the sibling CGA address of X (with 
colision = 1) and DAD it. The savi device installs it in the table
- At some point N go silent (pretty common, for maintenance, move, etc). 
Attacker M sends its periodic DAD NS for X. The savi device thinks
it's a move and replace the legitimate owner by the attacker.
- Here is the funny part. N comes back. Do DAD for X. M responds. N 
tries a second address X'. It's in the binding table! M responds.
- N ignores the response (that's 3971) and start sourcing with X'. All 
its traffic is dropped. Including the unsolicited NA to all-nodes
- Every node on the link, including the CGA-capable now have M as X and 
X' owner.  And the savi device is dropping all N traffic.

That's what I call highjacking.
While this is not worse than before for non-CGA capable nodes, any 
CGA-capable nodes on the link should have prefered  N to M.
But they don't have chance to see N. So CGA (RFC3971) become pointless, 
useless.
Eric

---

From: Alberto García <[email-masked]>
Date: Tue, 3 Nov 2009 18:59:42 +0100

Hi Eric

|  -----Mensaje original-----
|  De: Eric Levy-Abegnoli [mailto:[email-masked]]
|  Enviado el: lunes, 02 de noviembre de 2009 16:02
|  Para: Alberto García
|  CC: 'Christian Vogt'; 'SAVI Mailing List'
|  Asunto: Re: [savi] A few comments on draft-vogt-savi-framework
|  
|  Alberto,
|  Alberto García a écrit :
|  > Hi
|  >
|  > |  -----Mensaje original-----
|  > |  De: [email-masked] [mailto:[email-masked]] En nombre
de
|  > Eric
|  > |  Levy-Abegnoli
|  > |  Enviado el: lunes, 02 de noviembre de 2009 11:42
|  > |  Para: Christian Vogt
|  > |  CC: SAVI Mailing List; Alberto García
|  > |  Asunto: Re: [savi] A few comments on draft-vogt-savi-framework
|  > |
|  > |  Christian,
|  > |  Christian Vogt a écrit :
|  > |
|  > |  	Alberto -
|  > |
|  > |  	As a member of the working group, not as its chair:  You are
right
|  > |  	that co-existence scenarios need to be handled.  But I'm not
sure
|  > that
|  > |  	coexistence requires /special/ behavior.  As long as the
behavior
|  > |  	desired for coexistence scenarios does not preclude the
behavior
|  > |  	desired for non-coexistence scenarios, I think coexistence
should be
|  > |  	covered by the /regular/ behavior of the various SAVI
protocol
|  > |  	specifications.  That is, in the particular case of
SLAAC/SEND co-
|  > |  	existence, I think we should strive for a SAVI SEND protocol
that
|  > can
|  > |  	handle non-SEND-capable SAVI devices.
|  > |
|  > |
|  > |  As we are centralizing the co-existence decisions in a
|  > "man-in-the-middle" savi-
|  > |  device, we can't just consider that the capability of the
savi-device
|  > (SeND, not
|  > |  SeND) are it's sole problem. Which "looks" the case if the
co-existence
|  > scenarios
|  > |  are described in the savi-SeND protocol specification.
|  >
|  > I don't understand this. What's the problem with a situation in which
the
|  > manager of the network configures SAVI devices...
|  > - in SLAAC-only mode if it knows no SEND hosts are there
|  > - in SEND-only mode if it knows all hosts are SEND
|  > - in SLAAC-SEND-compatible mode if it knows the network has SEND and no
|  SEND
|  > hosts.
|  > I assume that deploying SAVI is going to require some management (we
have
|  > assumed that when stating that there are roles such as Trusted and
|  > Validating). For SEND even more configuration is required in the SAVI
|  > devices (i.e. trust anchors).
|  >
|  It is not realistic to expect that the operator will know **all**
|  end-nodes capabilities. There might be thousands of them,
|  (I know an enterprise which as 100,000) and they could show up or
|  disappear at n a very dynamic pace.
|  Also, there is an organisation issue; quite commonly, the network in
|  controlled by one entity, the end-nodes by a different one.
|  Security so far is mostly dealt with by end-nodes, not network
|  elements.  If we move some security feature out of the end-nodes
|  into a network box, we must insure it does at least an equivalent job.

In this case I assume that the SAVI devices should be SLAAC-SEND compatible
(it is a case in which the operator assumes could be any of them). Is this a
problem?

|  
|  For CGA, no provisionning (trust anchor) is required what-so-ever. So
|  the SAVI has no other way to know than to look at
|  the CGA option.

I agree about that.
However, I don't like very much talking about CGA, but about SEND. SEND
specifies the behavior for validating host addresses (that must be CGAs),
but also for validating router-related information (router identity and
prefixes). For the last issue, trust anchors is the way defined in the
RFC3971 to do this.
Note that for SEND SAVI operation, it is relevant to be able to identify
local traffic from transit traffic, and to do this, the devices must know
which prefixes are on-link. A good dynamic way to do this is to use the
signing facility for RADV info of SEND, whose validation depends on trust
anchors. 
Otherwise, the operator must configure manually the prefixes... i.e. a lot
of configuration in SAVI devices, which was the point here (configuration of
the operation mode of SAVI devices is not an issue compared to the rest of
the configuration required).

|  > SEND hosts also need to be configured with trust anchors for processing
|  > correctly secured RADV. (well, the manager may not know if two hosts
|  > configure CGAs just for communication among themselves, but, is this
the
|  > general case? )
|  > So, the manager will provide the appropriate SAVI operation mode.
|  >
|  We are talking about address assignment, right? Then CGA does not
|  require any centralized provisionning of any kind.
|  In particular no trust anchor.
Yes, agreed

|  > In addition, the compatible mode should work fine for both types of
hosts. A
|  > manager with SAVI devices capable of this, and with any suspicion that
a
|  > SEND host may appear, may set up the SAVI devices to be in this mode.
|  >
|  > Do you think this deployment model for SAVI is reasonable?
|  >
|  There are many situations where he will not know. We (SeND) have
|  designed a distributed protocol where end-nodes can
|  take care of their own security. And now by centralizing some of the
|  security, we (SAVI) are breaking this model.
|  I think this is going to be a SeND (or at least CGA) killer. Once
|  someone have deployed a bunch of SAVI switches, it won't be possible
|  anymore to deploy SeND on any subset of end-devices.

... or just deploy from the beginning SLAAC-SEND savi compatible devices. 
Well, I'm not seriously proposing this (due to cost considerations). 
But I'm not so pessimistic as you are: SLAAC SAVI provides to SLAAC more
security than SEND. Even SLAAC SAVI for SEND provides a different type of
security, that is applied to data packets (SEND only protects the binding
between IP address and layer-2 address), which is an additional security
that does not exist now for SEND operation. For SLAAC SAVI, when a host
receives SEND ND messages, it knows that the additional protection for the
IP / layer 2 address binding is there.
Agreed that does not provide priority to SEND hosts (which occurs in
RFC3971), and does not protect DAD for unsecured NADV in 2nd and 3rd times.
Which I assume that would make users ask their operators to change SAVI
devices to SEND-compatible ones. 
By the way, I think some kind of notification (such as the ICMP message
currently suggested to generate when discarding packets) would enable, at
least, some kind of feedback specially relevant for SEND hosts (or users of
the host). 
Alberto

|  Eric
|  > |  A savi device not SEND-capable breaks RFC3971.
|  > Yes, so when a SEND host exists, SAVI must be SEND enabled.
|  >
|  > |  Like a bridge that would mess
|  > |  with L3 messages. And it has no way to know.
|  >
|  > This is where I kindly disagree.
|  > Regards,
|  > Alberto
|  >
|  > |  Can we **really** specify that?
|  > |  There might be thousands of non-SeND capable nodes on the link, and
just
|  > one
|  > |  signle pair of SeND nodes, and this SAVI-switch in the middle is
|  > completely
|  > |  messing with their "standard" behavior.  Note that there **are**
such
|  > |  deployments out there. And the deployments scenarios are exactly
that
|  > (few
|  > |  SeND critical nodes, many non-SeND).
|  > |  So I think the description of this scenario, and associated warnings
|  > should show
|  > |  up either in all documents, or in a higher level doc( framework, or
|  > other).
|  > |  Eric
|  > |
|  > |
|  > |  	Does this make sense?
|  > |
|  > |  	- Christian
|  > |
|  > |
|  > |
|  > |  	On Oct 29, 2009, at 3:04, Alberto García wrote:
|  > |
|  > |
|  > |
|  > |  		My opinion is that priorization is not enough.
|  > |  		I think we need to define "operation modes"
(SEND-only,
|  > SLAAC-
|  > |  only,
|  > |  		SEND-SLAAC-compatible...) and describe the state
machine for
|  > |  each one.
|  > |
|  > |  		To support the idea of why we need a new state
machine for
|  > |  SEND-SLAAC
|  > |  		compatibility, i.e. for a domain in which both SEND
hosts
|  > and
|  > |  non-
|  > |  		SEND hosts
|  > |  		coexist, just consider what a node should do
(extending
|  > naturally
|  > |  the
|  > |  		current FCFS and SEND proposals) if a SAVI device is
in
|  > |  NO_BIND
|  > |  		state, and a
|  > |  		data packet (not DAD NSOL) is received, from a
Validating
|  > port
|  > |  VP.
|  > |  		In this
|  > |  		case, the SEND SAVI device should send
|  > |  			- 2 (unsecured) NSOL messages through
Trusted ports
|  > |  (according to
|  > |  		FCFS SAVI)
|  > |  			- and a secured NUD NSOL message through the
|  > |  Validating Port
|  > |  		(according to SEND SAVI
|  > |  			And The state is moved to TENTATIVE.
|  > |
|  > |  		In the TENTATIVE state, the SAVI device should maybe
wait
|  > long
|  > |  		enough (a
|  > |  		RetransTimer, which is the waiting time for NUD
operation)
|  > for a
|  > |  		secured NUD
|  > |  		NADV even if an unsecured DAD NSOL is received from
a
|  > trusted
|  > |  port
|  > |  		in the
|  > |  		meanwhile, to assure that SEND validated addresses
have
|  > priority
|  > |  over
|  > |  		non-SEND addresses. [Note that this may occur if a
SEND host
|  > |  has one
|  > |  		collision when performing DAD for an address, and it
is not
|  > |  		withdrawing the
|  > |  		second address if an unsecured DAD NSOL is received
for it,
|  > as
|  > |  RFC
|  > |  		3971
|  > |  		says].
|  > |  		Different states should be defined (VALID_SEND,
|  > |  VALID_NON_SEND), with
|  > |  		different behavior when the valid_timeout expires.
|  > |
|  > |
|  > |  		So I don't think this is just "ships in the night",
but
|  > different
|  > |  		modes
|  > |  		should be defined to integrate all the possible
combinations
|  > of
|  > |  		address
|  > |  		configuration mechanisms. Maybe one of these modes
should be
|  > |  the
|  > |  		default
|  > |  		one, but the administrator could set the SAVI
devices to the
|  > |  		appropriate
|  > |  		mode (well, they also have to define which ports are
trusted
|  > or
|  > |  		not...).
|  > |
|  > |  		Does this make sense?
|  > |  		Regards,
|  > |  		Alberto
|  > |
|  > |
|  > |
|  > |
|  > |
|  > |  	_______________________________________________
|  > |  	savi mailing list
|  > |  	[email-masked]
|  > |  	https://www.ietf.org/mailman/listinfo/savi
|  > |
|  > |
|  > |
|  >
|  >
|  >
|  >

---

From: Christian Vogt <[email-masked]>
Date: Thu, 5 Nov 2009 03:33:57 -0500

On Nov 3, 2009, Eric Levy-Abegnoli wrote:

> CGA-prooved NDP message over a none prooved one. If the savi device  
> does
> first-come-first-serve, and is not able to verify (and prefer) CGA
> credentials, then there are plenty of scenarios where it will keep the
> non CGA owner entry and discard traffic from the legitimate: basically
> all scenarios where the non-CGA came first.

But all of these scenarios are about the same issue:  When a SEND host's
DAD fails for the second time due to an unsecured Neighbor
Advertisement, then the SEND host will configure the IP address, yet a
non-SEND-capable SAVI device would block the IP address.  The same holds
for the attack scenario that you described in your email.

The question is hence:  What do we do about this issue?  Is it
negligible?  Is it significant enough to warrant building SEND support
in all SLAAC SAVI devices?  Should we find some tradeoff?

I think your attack scenario shows that the situation is not negligible.
On the other hand, many of us feel that full-fledged SEND support would
make SLAAC SAVI devices too expensive.  So how would a reasonable
tradeoff (Alberto calls it a "SEND-compatible mode") look like?

- Christian

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Thu, 05 Nov 2009 10:07:00 +0100

> tradeoff (Alberto calls it a "SEND-compatible mode") look like?
I don't think we need "full-fledged SEND support". All what is needed is 
the capability to verify a sha1 hash and a rsa-signature. **That** is 
negligeable compared to full-fledge SeND or to everything else required 
to implement savi slacc or dhcp. And there is plenty of open source to 
achieve these minor features.
So the tradeoff would be to require CGA and RSA verification (this is 
pure algorithmic and entirely stateless), and prefer entries what carry 
these credentials. I really don't see that as a big deal.

We (SeND work) have defined a realistic incremental deployment scenario 
for SeND ("transitionning mode"). And we start seeing it happening. The 
security is left to end-nodes, and network admin have little ways to 
know which end-nodes are using CGA addresses. As soon as a 
savi-not-CGA-capable device is going to be deployed, these (few) 
end-nodes doing SeND will be as vulnerable as regular ND nodes. And 
these nodes will have  no way to know that a savi-device is messing with ND.
**We are moving the security decision from host to the switch, with less 
security, and no way to communicate this between each other**
I am worrying that if we don't make CGA verification a MUST, we are 
giving a clear message that SeND  is useless. What is the value of a 
security mechanism that prevent another stronger one to operate?
Eric