--------------------------------------------------------------------- Draft Minutes of the SAVI working group meeting at IETF 78 Monday, July 26, 9:00 - 11:30, Berlin room Chairs: Christian Vogt, Jean-Michel Combes Jabber scribe: Fred Baker Minutes takers: Joel Halpern, Eric Vyncke --------------------------------------------------------------------- Introduction and Administrativa Jean-Michel Combes, Christian Vogt - Threats draft A new version of this draft will be submitted in September - Framework draft Co-authors are needed. Please contact Christian. - Reviews of the current WG draft Don't hesitate to review the drafts and comment them on the ML +++++ SAVI solution for SLAAC draft-ietf-savi-fcfs-04 Marcelo Bagnulo Updated to reflect SHOULD trigger binding creation up the reception of binding from data packet, with qualification in an appendix. Updated to reflect that SAVI devices MUST learn prefixes from the router advertisement. Open Questions: - Do we need router ports? Currently there are only trusted and validating ports. Routers will probably on trusted ports. Adding a third type of ports for routers where the local address is validated but remote address (for transit/forwarded traffic) is blindly trusted. Discussion of benefits/costs of allowing this. Including related issues of where we accept RAs (all trusted ports, or some specific kind of trusted ports). General agreement in room that we don't need the complication. Suggested alternative from Jean-Michel Combes that Router Port would be a trusted port with logging. Concern that logging is a DoS vector. It is noted that SAVI has to defend the router link address as it defends other bindings. Consensus seems to stay with 2 kinds of ports and update security considerations. - When to delete bindings? It is necessary that usage extends the lifetime of the binding. So what is the default lifetime? Obvious choice is to keep the lifetime as long as there is traffic. Using the RA prefix lifetime. OTOH could also send a NUD before deleting. Also removing a binding does not mean blocking traffic but rather stopping the protection. Fred Baker and others observed that the Prefix Lifetime from the router is not a good basis for the SLAAC lifetime. Suggested that timeouts on the same order as classic bridge MAC lifetimes seems attractive. Other factors were presented. Including the question of what the right response is to attack via traffic that produces many bindings (under attack such as DAD flooding very similar to the CAM overflow), proposal delete newest bindings or limit the number of bindings per port (configurable, which default?, could be used to prevent privacy extension), should we rate limit the NUD probe before deleting? (or is it left to the implementers?) but of course the attacker will reply to NUD probe. Discussion of responses and implications. There is agreement that old bindings are more valuable than new ones. It is noted that with privacy addresses this is more complicated. Question to room: Should we send a NUD probe before deleting a binding? Suggestion is to probe for timeout but not for memory exhaustion. Discussion moved to the question of how to handle moves safely, and how this interacts with lifetimes. Conclusion at meeting we will have lifetimes on entries. Which one? Using the 802.1d default time (5 minutes)? Consensus is to keep the lifetime mean for garbage collect (main benefit is to be able to differentiate normal situation and an attack). Fred’s default would be MAC address in CAM (5 minutes perhaps too short but the NUD probe will keep it alive), Eric’s default would be TCP timer (1 hour). On the related issue of how many entries to have per port, the discussion noted that the minimum requirements are tricky, since link local and privacy leads to needing at least 4 entries, and virtual machines require the ability to have more entries. Discussion of whether there should be default values for the minimum and maximum number of addresses and for the lifetime of entries. Agreement that these values need to have defaults and need to be configurable. Consensus for default values is 5 minutes for lifetime and a minimum of 4 bindings per port. - Rate limiting SAVI generated packets Christophe Alter: use the DAD rate limiting Chairs: We are late. Please, continue the discussion on the ML. +++++ SAVI solution for DHCP savi-ietf-dhcp-04 Jun Bi Started with a review of the document structure and content. The port could have multiple attributes: drop/forward DHCP server type message, snooping DHCP, ... Port attributes include compatibility, may need amplification. Already implemented by ZTE, Huawei, Ruije, H3C, Digital China, Bitway, Centec, ... Example given Tsinghua University Campus with different vendors. Changes: the prefix configuration is removed. Open question: - Support of mixed address assignment (DHCP and SLAAC), should it be supported? Jun: yes because a lot of OS lack DHCP client. In order to support mixed environment, the finite state machine has to change. Joel Halpern suggested that we separate issues, write documents for the single cases, and deal with mixed-mode cases completely separately. Proposal is to remove mixed-mode from SLAAC & DHCP documents to move them ASAP to the IESG while adopting a new work item for this WG for mixed-mode. +++++ CNGI-CERNET2 deployment update Jun Bi CNGI-CERNET 100 campuses, 1 million users. Vendors are the one previously mentioned by Jun in his previous talk. A lot of CLI examples. Testing was done for conformance, performance, test bed and in production network using SLAAC-only, DHCP-only and mixed mode (performance and binding size numbers reported). Performance graphs were mostly in Chinese but the conclusion is that SAVI does not add any delay. Interoperability was tested also. Management was done by using a SAVI-MIB (including whether SLAAC-only or DHCP-only FSM). One operational issue was packet lost but 802.1x and SAVI were working fine together. +++++ Liaison with BBF draft-costa-6man-dad-proxy-00 Christophe Alter, Jean-Michel Combes The issues is DAD in N:1 VLAN configurations. This was presented at IETF 76. In an access node, in some case there are multiple subscribers in a shared VLAN but CPE do not have direct layer-2 connectivity to each other: they talk at the IP level through the BNG (Broadband Network Gateway). As seen at the BNG, all users are on one VLAN, but Ethernet Frames are not forwarded from one user to another. This is because the access network is designed to drop all frames sent from CPE to another CPE. This is called split-horizon or E-tree service (in Metro-Ethernet) or N:1 VLAN (broadband forum). It was mainly done for scalability (10,000 subscribers per VLAN) and for privacy among subscribers. As some CPE have duplicate MAC addresses, some access networks do MAC address translation. Issues to be resolved: - LLA cannot be derived from MAC as there is duplicate MAC… - BBF would love to have SAVI to define how a helper function could allow DAD without any CPE-to-CPE layer-2 connectivity. Indeed, SAVI should have all LLA bindings. Discussion: is it a SAVI item? Or 6MAN or 6OPS ? Other topic: DAD will not make SAVI stronger of course. Is the layer-2 MAC NAT (used in some access network) part of the issue? (not really dixit Christophe but uniqueness of MAC address is not guaranteed). Draft-costa-6man-dad-proxy is a solution for this problem and is presented by Jean-Michel. The best WG is probably 6MAN but authors are open to any host WG. The I-D presents the N:1 VLAN split-horizon + why existing protocols do not work (even RFC4389 ND proxy because of lack of multicast support) + solution of DAD proxy. SAVI device uses the binding to signal to the 2nd CPE doing DAD for one already-bound LLA that this LLA is already used (minimal amount of traffic). There was discussion of whether the use of MAC address translation in some of these access networks has to be part of the discussion at the IETF. Several people want to analyze the issues linked to the MAC NAT, probably into another document. +++++ Analysis of SAVI in PANA with SLACC draft-ding-savi-pana-with-slacc-00 Yilan Ding No time for this presentation. --- End of working group meeting ---