[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

- 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 provide your comments.
thanks,
Jun Bi
 
 
               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


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.