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
--- Begin Message ---Eën®zZ¶¾&èºw ²'~?àEç ?÷?~º&?w&?M¢?WZ¥¸nk¢ÝÊ&r?µïm¹×?võ¼¡ÝÉ?Óh§?æ°z-Ü¢g(?#åjw1ë,j§?'«½êùØz-,uÛ?î?[Lj½öÓN0?ØDHÄÏ?Ý Hí41u?äµ½?w&sM¢??Áè·r??¢gè®X§¶ Ür??®-:6?öÓOvÓn9ïí<Ó at ?M?z+Þuúè? Ü?]6?yhq©a¢ËuÛ½4Õ¼¡ÝÉ¥Óh§?æ°z-Ü¢g(?#åjw1ë,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(?#åjw1ë,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ÖZ jXh²ÝvïM5o'(íÚ?É\¢cè²×âÇ?D?Lø? ]A p:ð>®-:6?öÓOtãn6ßO4Ðô?Eç ?÷?~º&???,¶Z jXh²ÝvïM5o'(íÚ?É\¢cè²×âÇ?D?Lø? _ at ëp:ð ¢»¾'(íÚ?É\¢ak?N?¢ý´ÓÝ8Û?¶ÓÍ4=$ÑyÇ¢½ç_®?¦j)bz×许׽=ó}?ÊZ jXh²×(íÚ?É\¢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Ê&¦Wy«vÓOu×N¶Óm9äúÞqç^?Ç¥?ËWç§N«zƯ?'~?à éb½êÞvÚ,jø?¢··jk%r??:¸ ?v¥N?¾'(íÚ?É\¢eÕ?»¬IƧ?çZ?«â±ÙÞÁ«Z?É\¢eÒ¥©??¨ 9t©jd?¢·¶ãÎ×J?¦-ëÞ?t©jdjÛ¬6? ¢·Û?;µ¨ yÖ?¢÷÷ßkz«¢çæ׬¶ÀX½×Ï?ÓMçßE ?N Ô×?u BÎ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" <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 > _______________________________________________ savi mailing list savi at ietf.org https://www.ietf.org/mailman/listinfo/savi
--- End Message ---
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.