Subject: [savi] New Version Notification for draft-levy-abegnoli-savi-plbt-01

From: Eric Levy-Abegnoli <[email-masked]>
Date: Tue, 04 Aug 2009 16:36:33 +0200

Hi,
I have uploaded a new version of the pblt draft 
(draft-levy-abegnoli-savi-plbt-01) to keep only the central issues with 
regard to [fcfs] and the proposed resolution. It should make the 
document easier to review.
Feedbacks are more than welcome.
Document can be found at:
http://www.ietf.org/id/draft-levy-abegnoli-savi-plbt-01.txt
Thanks
Eric

Subject: New Version Notification for draft-levy-abegnoli-savi-plbt-01
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Date: Tue, 4 Aug 2009 07:28:59 -0700 (PDT)

A new version of I-D, draft-levy-abegnoli-savi-plbt-01.txt has been successfuly submitted by Eric Levy-Abegnoli and posted to the IETF repository.

Filename:	 draft-levy-abegnoli-savi-plbt
Revision:	 01
Title:		 Preference Level based Binding Table
Creation_date:	 2009-08-04
WG ID:		 Independent Submission
Number_of_pages: 8

Abstract:
[fcfs] proposes a simple preference scheme to resolve binding entry
collisions (same l3 address, different anchors): it keeps the first
entry and rejects any others.  However, there are cases where keeping
the first entry is not the best choice, and others cases where it is
bogus.  This draft analyses what are these cases, and proposes a
different algorithm (preference based) to fix the problem.

The IETF Secretariat.

---

From: Dong Zhang <[email-masked]>
Date: Wed, 05 Aug 2009 10:21:36 +0800

Hi Eric,

I have a litte confusion here.
>Consider the case of a link with a mix of ND (RFC4861] and SeND
>(RFC3971] nodes.  Consider node A running ND, node B and node C
>running SeND. 
Can the mix of ND and SeND in a same link be a common case? I mean 
if this happens, how to handle the NA/NS between SeND node and non-
SeND node?  

>The following preflevel values have been identified (from lowest to
>highest):
>o  LLA_MAC_MATCH: LLA (found in NDP option) and MAC (found at layer2)
>   are identical;
>o  TRUNK_PORT: the entry was learnt from a trunk port (connected to
>   another switch)
>o  ACCESS_PORT: the entry was leant from an access port (connected to
>   a host)
>o  TRUSTED_ACCESS: The entry was learnt from a trusted port
>o  TRUSTED_TRUNK: The entry was learnt from a trusted trunk
>o  DHCP_ASSIGNED: the entry is assigned by DHCP
>o  CGA_AUTHENTICATED: The entry is CGA authenticated, per [RFC3972]
>o  CERT_AUTHENTICATED: the entry is authenticated with a certificate
>o  STATIC: this is a statically configured entry per [RFC3971].
Then what about ACCESS_PORT+DHCP_ASSIGNED and TRUNK_PORT+CGA_AUTHENTICATED, 
which is bigger?
I think there will be some different cases and combinations of the preflevel 
values. Is it necessary and possible to list every case, giving particular 
illustration? Then it will be much more clear. Perhaps I might miss something.

Thank you.
------------------				 
Dong Zhang                        
2009-08-05

---

From: "Greg Daley" <[email-masked]>
Date: Wed, 5 Aug 2009 15:03:14 +1000

Hi Dong, 

> if this happens, how to handle the NA/NS between SeND node and non-

SEND/non-SEND interoperation is dealt with extensively in RFC3971.

It does make sense to have a mix of nodes on the LAN, and this allows
incremental security deployment.

> Then what about ACCESS_PORT+DHCP_ASSIGNED and
TRUNK_PORT+CGA_AUTHENTICATED,  which is bigger?
> illustration? Then it will be much more clear. Perhaps I  might miss
something.

Since the bindings identify the level of authority attained about the 
address mapping, only the highest of these should be considered.

The presence of CGA_AUTHENTICATED means the higher level of
certification
which has been attained by the binding.   This would supercede a
previous
(or contemporary) binding of TRUNK_PORT.  Therefore the binding state
would
be CGA_AUTHENTICATED.

Similarly, with ACCESS_PORT+DHCP_ASSIGNED, the DHCP assignment is a
control process which can be authenticated and is specified by a server.
This has more authority than the ACCESS_PORT binding.  Therefore this
binding's state is DHCP_ASSIGNED.

Comparison of these bindings therefore becomes simpler: DHCP_ASSIGNED vs
CGA_AUTHENTICATED

Perhaps some clarifying words could be put into the draft?

Please note that an address binding can be both CGA Authenticated and
DHCPv6 assigned, since
a node can propose its address in DHCPv6 based on known address
prefixes.  In this case,
the fact that the device can perform SEND CGA Auth on the address lends
more authority to the
binding (giving CGA_AUTHENTICATED) state.

Sincerely,

Greg Daley
Security Consultant
NetStar Australia Pty Ltd

E-mail: [email-masked]
Mobile: +61 401 772 770
Direct: +61 3 8532 4042
Fax:    +61 3 8532 4032

---

From: Dong Zhang <[email-masked]>
Date: Wed, 05 Aug 2009 15:26:43 +0800

Hi Greg,

>incremental security deployment.
Hmmm, if so, I might re-read RFC3971 carefully. :)
>Perhaps some clarifying words could be put into the draft?
According to your explanation, my understanding is an entry may have 
serveral preflevel values. And we pick up a highest one, to compare with 
another entry's.
If my understanding is right, yse, I do suggest adding a few words to make 
this point much clearer.

This draft provides a approach to reduce the possibility of misbinding in 
fcfs. That is to say the approach is used for the data packet first reveiced 
the savi switch. Other process is still the same with fcfs. Right?
This approach adds complexity to fcfs. Need we worry about the cost? 

Thx.

------------------				 
Dong Zhang
2009-08-05

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Wed, 05 Aug 2009 15:11:20 +0200

Hi Dong,

to add up to Greg's response ...

> if this happens, how to handle the NA/NS between SeND node and non-
I tend to think that this is going to be the prevalent case. It is hard to imagine that one will deploy SeND on all nodes from day 1.
Current status of SeND is that some vendors have implemented it, and others have not. So to start taking some advantage of it, in any
heterogeneous setup, it would sound reasonnable to expect a mix of ND and SeND, and have the SeND nodes more secure that the others.
By a matter of fact RFC3971 does describe this situation. I must also add that we are starting to see it in the field.
What I was pointing out is that, given how RFC3971 suggest to handle such situation, a "fcfs" switch will break it, and render SeND nodes as
insecure as ND nodes. Not a great achievement ...
Basically, SeND defines a preference algorithm which in a sense is similar to mine: nodes should prefer the most secure binding,
not the first one they see. hence the breakage ... 

> illustration? Then it will be much more clear. Perhaps I might miss something.
Given the encoding that I proposed, the sum of *everything* smaller than for instance CGA_AUTHENTICATED
cannot be equal or bigger than CGA_AUTHENTICATED. Let me put values to illustrate:
LLA_MAC_MATCH = 2**1 = 2
TRUNK_PORT = 2**2 = 4
ACCESS_PORT = 8
TRUSTED_ACCESS = 16
DHCP_ASSIGNED = 32
CGA_AUTHENTICATED = 64
CERT_AUTHENTICATED = 128
STATIC = 256

So ACCESS_PORT+DHCP_ASSIGNED would be 40 'decimal).
TRUNK_PORT+CGA_AUTHENTICATED would be 68.

The idea is that there is a strict order in this list (I am opened to discuss that order of course). But you can still
add up values. So a CGA assigned with DHCP would be prefered over a CGA assigned by SLACC. But a non CGA assigned by DHCP would
never be preferred over a CGA.
Hope that clarifies the mechanism. Which I think is actually implementaton-firndly, because the comparaison is very straigh forward.
Eric

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Wed, 05 Aug 2009 15:14:42 +0200

Hi Greg,

Greg Daley a écrit :
>> I think there will be some different cases and combinations  of the
>>     
> preflevel 
>   
>> values. Is it necessary and possible to list every case,  giving
>>     
> particular 
>   
>> illustration? Then it will be much more clear. Perhaps I  might miss
>>     
> something.
>
>
I guess so. If this was not crystal clear in the current writing, it 
means I need to clarify.  You got it allright though,
so it must not have been too bad :)
Maybe I'll add an example with some values ...
Thanks
eric

---

From: Dong Zhang <[email-masked]>
Date: Thu, 06 Aug 2009 10:04:32 +0800

Hi Eric,

Please check inline.

2009-08-06 

Dong Zhang

发件人： Eric Levy-Abegnoli 
发送时间： 2009-08-05  21:14:50 
收件人： Greg Daley 
抄送： Dong Zhang; SAVI Mailing List 
主题： Re: [savi] Question for draft-levy-abegnoli-savi-plbt-01 
 
Hi Greg,

Greg Daley a écrit : 
Hi Dong, 

  

    
preflevel 

particular 

something.

I guess so. If this was not crystal clear in the current writing, it means I need to clarify.  You got it allright though, 
so it must not have been too bad :)
Maybe I'll add an example with some values ...
Thanks
eric
[Dong] But It seems there is something different  between Greg's understanding and your explanation. So agree to add 
some clarification as my last mail said.

[Dong] In addition, I'm worried about a possible security problem.
*************
The draft says:
   Therefore, a data packet should not be used to complete the
   binding entry, but only as a hint that it should seek for completion.
   Upon receiving a data packet carrying a source address not seen
   before, the switch should issue a DAD packet on the link (all ports
   of the vlan), including the one from which the data packet was
   received.  The address owner is expected to respond with an NA,
   carrying CGA credentials if any.  Upon receiving this response, the
   switch can complete the binding entry and start forwarding traffic
   from the source.
   ...
   For instance, upon receiving a data packet, the
   switch will issue a DAD NS and wait for an NA.  Before receiving the
   NA, the entry is IMCOMPLETE.  Then it moves to REACHABLE.  Then to
   STALE unless the binding is confirmed by more NDP traffic.
************
Thinking about an attacker sends data packets with different forged source addresses incessantly. Then these data packets lead 
the savi switch to send DAD and wait for NA response. In this case, a DoS attack arise. The security consideration should be added.
And the entry bindings with IMCOMPLETE state cost the memory while waiting for the response. Maybe a state machine is need for 
the state transition. The behavior of savi switch might be something like this:
Trigger                                                                Action
Receive a data packet                                           Create a IMCOMPLETE entry, send DAD NS
If receive a NA within x(the exact seconds, e.g. 3s )   IMCOMPLETE moves to REACHABLE
If receive no NA within x                                         Eleminate the IMCOMPLETE entry
...                                                                       ...

Thank you.
Dong

Sincerely,

Greg Daley
Security Consultant

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Thu, 06 Aug 2009 10:34:43 +0200

Hi Dong,
thanks for all the good points. See inline ...

> Please check inline.
[snip]
> [Dong] But It seems there is something different between Greg's
> understanding and your explanation. So agree to add
will do in the next version

> Thinking about an attacker sends data packets with different forged
> source addresses incessantly. Then these data packets lead
> the savi switch to send DAD and wait for NA response. In this case, a
> DoS attack arise. The security consideration should be added.
> And the entry bindings with IMCOMPLETE state cost the memory while
> waiting for the response. Maybe a state machine is need for
All this is very true. Actually, in the -00 of this draft, I had
included a state machine description, somewhat very close to what you
are describing. I removed it in this -01 version to focus on
the preference algorithm (problem statement and proposed solution) and
give a chance to people to review that bit.
>From there it really depend on where this is going: if some of this
draft endup in the WG document (fcfs or with a different name as it was
suggested in Stockholm), then I would really like to
see a state machine there (I don't think there is one in fcfs).
If this is going to be a separate document, them I agree that I should
put back the state machine and clarify the security issues.
Eric