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

From: lintao 00450 <[email-masked]>
Date: Sat, 07 Nov 2009 01:17:41 +0800

I'll clarify that I think it is worth to become a SAVI WG as SAVI solution for DHCP. The follow discussion is tiny and help it clearer. In fact, we have deploy it in our product.

> 
> 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
E�n�zZ��&�w�'�~��E����~�&�w&�M��WZ��nk���&r���m�םv����ɜ�h���z-ܢg(�#�jw�1�,j��'�����z-,uۖ�[Lj���N0��DH�ω�
H�41u�䵽�w&sM�����r���g�X���r���-:6���Ov�n9��<�@�M�z+�u��ܚ]6�yhq�a��u۽4ռ��ɥ�h���z-ܢg(�#�jw�1�,j��'�����z-,uۖ�[Lj���N0��DH�ω�
H�4�?S)���w&�M�����r���g�X���r��D#Ӗ)�w�ak�N�����ݴߍu�O4�$�E����~�&�w&��6v�wq�&׽��]�Ѽ��ɥ�h���z-ܢg(�#�jw�1�,j��'�����z-,uۖ�[Lj���N0��DH�ω�
H�4��S)��w&�M�����r���g�X���r��D#Ӗ)�w�ak�N�����ݴߍt�O4�$�E����~�&�ki��r���m�׍�ټ��ɭkM���r���۬����^��{�E?\"�13�wm4�]t�m6Ӟ=�;�~��-:6���Ov�m9��<�D^q�y��i��X���+��5�O|�f�ki��r����DH������/�M=�M��ߴ�MyǢ��_���۽4�ZjXh��v�M5o'(��ښ�\�c������D�L��]Ap:�>�-:6���Ot�n6�O4���E����~�&���,�ZjXh��v�M5o'(��ښ�\�c������D�L��_@�p:����'(��ښ�\�ak�N������8ۍ���4=$�yǢ��_���j)bz���׽=�}��ZjXh��(��ښ�\�mv�M5jf���g{
h��t�n0��DH�ω��
��z{mʗ�{�V���Z�ǭ���]��{^��kj{z��r�b�ڱ�\�⢸��sh�f�\Čj)i�*+�܍����s0D�i������H��I��z�'�w&��6v����^��{�E?Rn��y�M=jݴ��uӭ��N4I��jX�y����^����ɭkM���wq�y��Oԛ�{^v�OZ�m4�]t�m6ӍRz���,�r����^jݴ��uӭ��N5"צ�7��#='����ܚִ��?�wzW���9�I�w��m4��v�Ou�N��m9�'���b���F��z�'�w&��6v����^��{�E?Rn��y�M=jݴ��uӭ��NyI��jX�y�&�W�y�v�Ou�N��m9���q�^�ǥ��W�N�zƯ�'�~��
�b���v�,j�����jk%r��:���v�N��'(��ښ�\�eՊ��IƧ��Z�������Z��\�eҥ����
9t�jd�������J��-�ޕt�jd�j۬6���ۏ;�� y֛����kz�����׬��X�����M��E�N�׎uB�0��0��Ӟw0���K

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" <[email-masked]>
To: "Eric Levy-Abegnoli" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>  
>

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

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