Re: [savi] SAVI Solution for DHCPv4/v6

[Lin Tao <lint at h3c.com>]

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


----- Original Message ----- 
From: "Bi Jun" <junbi at cernet.edu.cn>
To: "Eric Levy-Abegnoli" <elevyabe at cisco.com>
Cc: "SAVI Mailing List" <savi at ietf.org>
Sent: Tuesday, November 03, 2009 6:45 PM
Subject: Re: [savi] SAVI Solution for DHCPv4/v6


> 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
> 
>    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
> savi at ietf.org
> https://www.ietf.org/mailman/listinfo/savi
>  
>


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


> _______________________________________________
> savi mailing list
> savi at ietf.org
> https://www.ietf.org/mailman/listinfo/savi
>