Subject: Re: [savi] SAVI Solution for DHCPv4/v6

From: Eric Levy-Abegnoli <[email-masked]>
Date: Mon, 02 Nov 2009 14:20:45 +0100

Jun Bi and all,
I think the document is a reasonnably good shape. I had however a few
substantial comments made offline, that I'd like to repeat
the mailing list (note that they are all listed already in the doc as
open issues, but the RA filtering)

- Section 9.4: Router Advertisements have nothing to do with the SAVI
charter. For that, there is draft-ietf-v6ops-ra-guard. So
I don't think it belongs here or in the framework document.

- Section 7 (and subsequent) I don't like the idea of creating a state
"START" on the request, and I think in most cases, the state creation
could happen on the reply. Otherwise, there is an obvious DoS attack
that would fill the binding table with as
many "START" entries as allowed (max described in section 16 help
protecting the box, but not the anchor) and prevent legitimate entries
to be created.
>From my reading, a state "START" is created upon receiving a REQUEST
message. In most cases, creating the state on the REPLY should
work and be a lot safer. That is whenever the REPLY have enough
information to create the entry and associate it with the requesting
anchor.
For instance, if the anchor is the MAC, then the response has it. If the
anchor is the port, upon receiving the REPLY, it can be found in the
option 82. And if there is no option 82 (I am wondering if the switch
could not insert it all the time?), then there is the switch L2 mapping
table.
So I'd like this state to be removed or a least used as an "optionnal
but dangerous" correlation mechanism.

- My other substantial comment is about the interactions between ND (or
ARP) and DHCP. My understanding of DHCP is
that it is the client responsability to verify the address uniqueness
and to DHCPDECLINE in case of a collision. So it should be
sufficient to refer to DHCP messages, and if not, i'd like to see the
rational for it.
I have also suggested that whatever additional interactions there maybe
should rather be described in the
framework document.

Eric

Bi Jun a écrit:
> Dear WG members,
> Please read the SAVI solution for DHCP.
> This draft is for DHCP case. We removed the text on SLAAC of CPS-01
> and contributed to SAVI SLAAC draft.
> This version have taken the suggestions from Christian, Eric
> Levy-Abegnoli , Alberto García, etc. Thanks to all of them.
> Please provideyour comments.
> thanks,
> Jun Bi
> http://www.ietf.org/id/draft-bi-savi-cps-02.txt
> SAVI Solution for DHCPv4/v6
> draft-bi-savi-cps-02.txt
> Abstract
>
> This document specifies the procedure of setting up bindings between
> DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and
> anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation
> Improvements) device. The bindings can be used to filter packets with
> forged IP addresses.
> ------------------------------------------------------------------------
>
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: "Bi Jun" <[email-masked]>
Date: Tue, 3 Nov 2009 18:45:06 +0800

Dear Eric,

Thank you very much for your comments.
Please see my reply below.

Best Regards,
Jun Bi

From: Eric Levy-Abegnoli 
Sent: Monday, November 02, 2009 9:20 PM
To: Bi Jun 
Cc: SAVI Mailing List 
Subject: Re: [savi] SAVI Solution for DHCPv4/v6

Jun Bi and all,
I think the document is a reasonnably good shape. I had however a few substantial comments made offline, that I'd like to repeat 
the mailing list (note that they are all listed already in the doc as open issues, but the RA filtering)

- Section 9.4: Router Advertisements have nothing to do with the SAVI charter. For that, there is draft-ietf-v6ops-ra-guard. So
I don't think it belongs here or in the framework document.

  bj: A good suggestion. The address prefix configuration security is very important for source address validation, so the SAVI draft must 
     mention it. Since there is a related draft, we plan to move this part into the "security consideration". After the draft-ietf-v6ops-ra-guard is finalized (as a RFC), if at that time, the solution in that rfc works for SAVI requirement, then we remove the text and state that the SAVI device must conform to that rfc.

- Section 7 (and subsequent) I don't like the idea of creating a state "START" on the request, and I think in most cases, the state creation
  could happen on the reply. Otherwise, there is an obvious DoS attack that would fill the binding table with as
  many "START" entries as allowed (max described in section 16 help protecting the box, but not the anchor) and prevent legitimate entries
  to be created.  
  From my reading, a state "START" is created upon receiving a REQUEST message. In most cases, creating the state on the REPLY should
  work and be a lot safer. That is whenever the REPLY have enough information to create the entry and associate it with the requesting anchor. 
  For instance, if the anchor is the MAC, then the response has it. If the anchor is the port, upon receiving the REPLY, it can be found in the
  option 82. And if there is no option 82 (I am wondering if the switch could not insert it all the time?), then there is the switch L2 mapping table. 
  So I'd like this state to be removed or a least used as an "optionnal but dangerous" correlation mechanism.

   bj:  In our opinion, the most scenarios will be SAVI-host connections. In that case, host directly attached to SAVI-host port, so there is be no 
    security threaten in this case. If a non-savi switch is connected to SAVI-poly port, what you mentioned might be a problem. But please note that 
  if we remove this state, then if the MAC-port mapping table is poisoned by an attacked launched between REQUEST and REPLY, the SAVI switch 
 will lost the source port, there will another security threaten (with this "START" state, the REPLY can be forwarded to the correct source port by 
the binding table when the MAP-port mapping table is changed). Therefore by trading off, we intend to keep it (but will consider to mentioned the
  potential problem for SAVI-poly port). 

  Actually, the SAVI-ploy port (A SAVI switch connects to a non-SAVI switch) is really not recommend indeed in our opinion, because it can not achieve the host-granularity anti-spoofing, which is very import for security, management and billing purposes. The only case I believe the SAVI-poly case is useful is that a person in  a office connect a hub to SAVI-switch, then connect his multiple hosts to the hub (as the case we discussed with Marcelo, Erik, Christian on the last day of IETF 75). In this case, I think the user should be reasonable for the attacking between his own hosts).

- My other substantial comment is about the interactions between ND (or ARP) and DHCP. My understanding of DHCP is 
  that it is the client responsability to verify the address uniqueness and to DHCPDECLINE in case of a collision. So it should be
  sufficient to refer to DHCP messages, and if not, i'd like to see the rational for it.
  I have also suggested that whatever additional interactions there maybe should rather be described in the 
  framework document.      

  bj: Even it is a client's resposability to verify the address uniqueness, the SAVI device must make sure the client have done it.
        If the client didn't complete the DAD procedure, the SAVI device has the right to drop the packets as a punishment.

Eric

Bi Jun a écrit : 
  Dear WG members,

  Please read the SAVI solution for DHCP.  
  This draft is for DHCP case. We removed the text on SLAAC of CPS-01 and contributed to SAVI SLAAC draft.
  This version have taken the suggestions from Christian, Eric Levy-Abegnoli , Alberto García, etc. Thanks to all of them.

  Please provide your comments.
  thanks,
  Jun Bi

  Abstract

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

---

From: "Bi Jun" <[email-masked]>
Date: Fri, 6 Nov 2009 20:04:25 +0800

Dear Eric,

In response your comment on using option 82 to store the port info to reduce the "START" state, 
we consulted some vendors, not all DHCP servers support option 82, so that might be a problem when the SAVI　
device is widely deployed.  Another response from the switch vendor is that inserting the option in DHCP packet 
is estimated to consume the similar or more CPU resource than creating a "START" state. 
There is one situation that if the anchor is MAC (need the MAC is unspoofable, by deploying some IEEE tech such 802.1ae/af, 
which is not the common case), then the "START" state is not needed.
Anyway, thank you very much for your valuable comments, and we are considering to adopt your suggestion as 
an option (or open issue) in the draft.

thanks,
Jun Bi

From: Bi Jun 
Sent: Tuesday, November 03, 2009 6:45 PM
To: Eric Levy-Abegnoli 
Cc: SAVI Mailing List 
Subject: Re: [savi] SAVI Solution for DHCPv4/v6

Dear Eric,

Best Regards,
Jun Bi

From: Eric Levy-Abegnoli 

Jun Bi and all,

Eric

Bi Jun a écrit : 
  Dear WG members,

  Abstract

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

---

From: Lin Tao <[email-masked]>
Date: Fri, 06 Nov 2009 20:23:31 +0800

Dear Bi and Eric:

I think this document is reasonably good shape too. Like IPv4, it's obvious to create binding entry according DHCPv6 message. It is worth to become a SAVI group draft.

But I'm afraid of the numerous state. As the access device, SAVI must simpler and simpler, the numerous will complex it. Should we have a simple solution?

Another question, how to defend that a pseudo host forge the confirm message to change the binding entry's port? Maybe sending a NS to origin port can avoid this attack. BTW, some DHCPv6 server's Reply doesn't carry the IA address's lifetime, the same as comfirm, so the binding entry hasn't lifetime.

Lin Tao

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Fri, 06 Nov 2009 18:21:10 +0100

Hi Jun Bi,
Bi Jun a écrit:
> device is widely deployed.
ack.
> Another response fromthe switch vendor is that insertingthe option in
> DHCP packet
For the record, I believe we should be cautious in not driving this
specification from too many implementation considerations, as there seem
to be more and more such arguments brought up.
I'd prefer a solid reliable secure protocol than one that can be
prototyped.

CPU was not my concern: It's rather early/temporary state creation.
There are numerous examples (tcp syn attack is the best known) where
creating states before the clinet is "confirmed" (in our case before the
client is granted with an address) opened the door for nasty attacks.
> There is one situation that if the anchor is MAC (need the MAC is
> unspoofable, by deploying some IEEE tech such 802.1ae/af,
As I said, as long as the state is clearly qualified, issues discussed
and cases where it can be avoided listed, I am all fine.
Thank you.
Eric
> thanks,
> Jun Bi
>
> *From:* Bi Jun <mailto:[email-masked]>
> *Sent:* Tuesday, November 03, 2009 6:45 PM
> *To:* Eric Levy-Abegnoli <mailto:[email-masked]>
> *Cc:* SAVI Mailing List <mailto:[email-masked]>
> *Subject:* Re: [savi] SAVI Solution for DHCPv4/v6
>
> Dear Eric,
> *From:* Eric Levy-Abegnoli <mailto:[email-masked]>
> *Sent:* Monday, November 02, 2009 9:20 PM
> *To:* Bi Jun <mailto:[email-masked]>
> *Cc:* SAVI Mailing List <mailto:[email-masked]>
> *Subject:* Re: [savi] SAVI Solution for DHCPv4/v6
>
> Jun Bi and all,
> * bj: A good suggestion. The address prefix configuration security is
> very important for source address validation, so the SAVI draft must *
> * mention it. Since there is a related draft, we plan to move this
> part into the "security consideration". After the
> draft-ietf-v6ops-ra-guard**is finalized (as a RFC), if at that time,
> the solution in that rfc works for SAVI requirement, then we remove
> the text and state that the SAVI device mustcon**form to that rfc.*
>
>
> For instance, if the anchor is the MAC, then the response has it. If
> the anchor is the port, upon receiving the REPLY, it can be found in the
> could not insert it all the time?), then there is the switch L2
> mapping table.
> bj: In our opinion, the most scenarios will be SAVI-host connections.
> In that case, host directly attached to SAVI-host port, so there is be no
> security threaten in this case. If a non-savi switch is connected to
> SAVI-poly port, what you mentioned might be a problem. But please note
> that
> if we remove this state, then if the MAC-port mapping table is
> poisoned by an attacked launched between REQUEST and REPLY, the SAVI
> switch
> will lost the source port, there will another security threaten (with
> this "START" state,the REPLY can be forwarded to the correct source
> port by
> the binding table when the MAP-port mapping table is changed).
> Therefore by trading off, we intend to keep it (but will consider to
> mentioned the
> potentialproblem for SAVI-polyport).
> Actually, the SAVI-ploy port (A SAVI switchconnects to a non-SAVI
> switch) is really not recommend indeed in our opinion, because it can
> not achieve the host-granularity anti-spoofing, which is very import
> for security, managementand billing purposes. The only case I believe
> the SAVI-poly case is useful isthataperson in a office connect a hub
> to SAVI-switch, then connect his multiple hosts to the hub (as the
> case we discussed with Marcelo, Erik, Christianon the last day of IETF
> 75). In this case, I thinkthe user should be reasonable for the
> attacking between his own hosts).
>
> - My other substantial comment is about the interactions between ND
> (or ARP) and DHCP. My understanding of DHCP is
> * bj: Even it is a client's resposability to verify the address
> uniqueness, the SAVI device must make sure the client have done it.*
> If the client didn't complete the DAD procedure, the SAVI device has
> the right to drop the packets as a punishment.
>
> Eric
>
>
> Bi Jun a écrit:
>> Dear WG members,

---

From: "Bi Jun" <[email-masked]>
Date: Sat, 7 Nov 2009 22:51:36 +0800

Dear Eric,

Thank you for the comment. See my reply inline.

thanks,
Jun Bi

From: Eric Levy-Abegnoli 
Sent: Saturday, November 07, 2009 1:21 AM
To: Bi Jun 
Cc: SAVI Mailing List 
Subject: Re: [savi] SAVI Solution for DHCPv4/v6

Hi Jun Bi,
Bi Jun a écrit : 
  Dear Eric,

ack.

  Another response from the switch vendor is that inserting the option in DHCP packet 
  is estimated to consume the similar or more CPU resource than creating a "START" state.
For the record, I believe we should be cautious in not driving this specification from too many implementation considerations, as there seem to be more and more such arguments brought up.
I'd prefer a solid reliable secure protocol than one that can be prototyped. 

CPU was not my concern: It's rather early/temporary state creation. There are numerous examples (tcp syn attack is the best known) where creating states before the clinet is "confirmed" (in our case before the client is granted with an address) opened the door for nasty attacks.

               bj:  Thank you for the comment. But please note that I proposed many times that it's very important to have a port type SAVI-host (ONE host is directly attached at ONE port). At this port, if there is a binding table limitation, then there will be no attack, because there is only ONE host at the port, it can only attack himself. I strongly propose to have the SAVI-host port at both the DHCP and SLAAC document, because then we will achieve the strictly security, tracing and billing (and make solution at this type of port simplified).  At the DHCP document, we also defined a SAVI-poly port (to connect ONE hub for several hosts usually owned by one person), this port is not recommended. But if some operators like it, it's OK. If those hosts are owned by one person, then it not a big deal if his one host attacking his another host. For SAVI switch port to connect an nonSAVI switch, we suggest the operators configure two VLANs to separate them. We have run this mode and currently it looks OK.

As I said, as long as the state is clearly qualified, issues discussed and cases where it can be avoided listed, I am all fine.
Thank you.
Eric

  thanks,
  Jun Bi

  From: Bi Jun 

  Dear Eric,

  Best Regards,
  Jun Bi

  From: Eric Levy-Abegnoli 

  Jun Bi and all,

  Eric

  Bi Jun a écrit : 
    Dear WG members,

    Abstract

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