----------------------------------------------------------- Minutes of the SAVI working group meeting at IETF 76 Monday, November 9, 9:00am Ð 11:30am, Arcadia West room ----------------------------------------------------------- Minutes taken by Richard Barnes (rbarnes@bbn.com) and Guang Yao (yaog@netarchlab.tsinghua.edu.cn), and compiled by Jun Bi (junbi@cernet.edu.cn). Chair: Christian Vogt (--: Q&A; >>: vote) 1. Christian Vogt: Chairs' introduction Agenda: no change 09:00 Introduction and administrativa Christian Vogt 09:10 SAVI Protocol Framework Christian Vogt (draft-vogt-savi-framework) 09:30 SAVI for Stateless Address Autoconfiguration Marcelo Bagnulo (draft-ietf-savi-fcfs) 09:50 SAVI for DHCP Jun Bi (draft-bi-savi-cps) 10:10 SAVI for Secure Neighbor Discovery Marcelo Bagnulo (draft-ietf-savi-send ) 10:30 Liaison from Broadband Forum David Allan 10:50 CNGI-CERNET2 SAVI deployment update Jun Bi 11:10 SAVI for Delegated IPv6 Prefixes John Kaippallimalil (draft-kaippallimalil-savi-dhcp-pd) 11:30 End of working group meeting 2. Christian Vogt: SAVI protocol framework(draft-vogt-savi-framework) Splitting protocols for DHCP and SLAAC Protocol model: Three-step validation (1). Identify legitimate addresses (2). Bind legitimate addresses to "binding anchor" Anchor = difficult to spoof (e.g. MAC address) (3). Enforce legitimacy through binding validation -- Bagnulo: Are we only supporting filtering? -- We had also discussed logging -- Vogt: That's correct, you don't have to drop the packets -- So maybe what (3) is is "verification", which can inform some action Validate as close to the host as possible Ensure that all packets go through the enforcement point Make it easier to find and validate link-layer binding anchors Optimization to reduce load on individual validators Draw a perimeter (essentially customer edge) at which validation is done -- Bagnulo: Not only memory, but the number of packets you need to handle -- Because of different addressing semantics, need different "flavors" of SAVI -- Bagnulo: Difficult to set hard lines that work across flavors Three cases, exemplified by DHCP, SLAAC, SEND SLAAC case only protects *used* addresses -- Jun Bi: Not enough to only protect *used* addresses -- Need require that the host compeltes the whole ND process -- According to RFC4862, if there's no DAD, then the address is only the tentative address, -- isn't officially assigned and could not be used by the host -- In the goal of savi-slaac, if not requiring host MUST do it, -- then the savi-switch has to do DAD on behalf of host, -- then host might attack the switch by sending many packets without DAD, -- then the swtich will be very busy at doing DAD for attackers. -- Vogt: Don't you agree that you can't protect un-used addresses in SLAAC -- If didn't ask Maybe prioritize DHCP/SEND as more secure -- Bi: Sure, just think it's insufficient, need to make sure that host completes ND/DAD procedure -- as enfored in RFC4862 -- Bagnulo: Don't we all agree that there's no binding without DAD? -- Bi: "Spoofing impossible for used addresses" might imply switch doing DAD -- Bagnulo: Even if you do all that, you can still only protect used addresses -- Vogt: If you leave it to the attacker to pick an address, then he can pick -> It's not really spoofing (!) -- We'll look at the text and see if it's OK -- Bi: If we're stating a goal in the framework doc, let's state it precisely. -- If host picking up a unused address without completing DAD, it is spoofing! -- J-M Combes: Don't see IKEv2 in this list -- Vogt: Yes, one can also use IKEv2 to assign addresses, e.g. in Mobile IP -- Bagnulo: Why don't you write a document? -- Barnes: Don't have to list everything in this document Three classes of binding anchor Network attachment ~= Switch port Attached host ~= MAC address Legitimate user ~= SEND key, security association -- Barnes: Not really accurate to say "bind to user", instead "bind to key" -- Bagnulo: Right, get different security depending on key bindings -- Different security guarantees here -- If the host controls the anchor, then security is less -- Bagnulo: The only reasonable thing you can do here is log (not block) -- Need to consider DOS attacks, e.g., based on MAC spoofing -- If you're binding to a switch port, you can also have collisions -- Baker: My customers filter, don't log; also log can be a DoS on a switch -- Bi: If the MAC is easily spoofed in the most case, -- does it make sense to use MAC as the anchor? -- Vogt: Should we just get rid of the non-secure anchors? -- Baker/Bagnulo: No! Just explain constraints -- Halpern: The classes don't clearly correspond to security classes -- Highly dependent on the specific network environment -- Bi: Might be able to add some more taxonomy -- If the port is directly connected with one host, the security level of anchor is high -- If the port is shared, the security level of port is low -- Manning: How many multi-user hosts are in use today? -- Re: binding to legitimate user -- Barnes: Validation and taking action are separable, discuss trade-offs -- Vogt: Is this framework generally a good baseline? -- Halpern: Would like to move some things from protocol docs to framework -- E.g. port types -- Vogt: Intend to do that, e.g., with perimeter concept, trusted/ untrusted ports -- Bagnulo: Agree with this Show of hands: Is draft-vogt-savi-framework a good starting point for a framework? Not asking for adoption >> ~15 hands in favor, none against 3. Bagnulo: SAVI for locally generated addresses Focused on the local network segment, address ownership based on FCFS -- John Kaippallimalil (Huawei): Does this apply to link-local as well? -- Bagnulo: Don't see why not -- Bi: prospoed not continue to use "FCFS". -- Vogt: will just use "slaac" Uses SAVI enforcement perimeter Watches NSOL and NADV to ensure uniqueness of address Learning ports (learn bindings) and "direct ports" (protect/ filter) Different port types add complexity, more complex manual configuration -- Bi: Need different port types to facilitate good bindings, traceback, billing... -- Need host-level granularity for operators, such as CERNET -- E.g., if port has many hosts and you can spoof MAC, might bill wrong person -- Bagnulo: Would the SAVI device behave differently in that configuration? -- Vogt: Is it important for the operator or the switch to know the difference? -- Bi: Since the security level is very import to operators, -- we need to know how each port is configured and used. -- At different port type, the switch machanism can be different, -- There is a smilary situation in dhcp, I will explain in my savi-dhcp ppt. -- Manning: Confused. Getting wrapped around a current network artifact -- E.g., wouldn't work in a flat Ethernet system -- Try not to get wrapped around specific layer-2 stuff -- Halpern: Flat ether also maps to single port with multiple hosts on it -- Alper Yegin (Samsung): When does a binding get deleted? -- Bagnulo: Several approaches, e.g., lifetime -- Alper Yegin: Infinite lifetime will cause problem -- Marcelo/Vogt: is there any differnet for switch action on differnet port types? -- Bi: It's much differnt. If we have the savi-host port, the solution will be simplified. -- for example, when the host moves to another switch, -- the old switch will know the disconnection immediately, then clear the binding -- In your current state machine, you have to keep those binding entries until timesout, -- it make the state machin complex. -- Moreover, after the host disconnected, the address in old binding entry is no longer an "used address", -- based on the famework, it should not be protected. -- [State machine] -- Bi: This state machine doesn't ensure ND/DAD completion? -- So the attacker could DoS the switch by sending packets with source address from many different sources: making you create lots of tempory states, making the switch CPU send out lots of probes. -- Bagnulo: Couldn't you do that in any case by sending lots of NSOL messages? -- Bi: The switch won't consume CPU to send out lots of probes. The frequency of data packet could be high. -- Eric (Cisco): You assume you always see the DAD, what if the switch reboots? -- Bagnulo: When you get datagrams, you do proxy-DAD -- John: data driving control snooping is complicate and with unpredictable result. -- Bi: Agree 4. Jun Bi: SAVI for DHCP Combination of watching DHCP and deconflicting (DAD/ARP) Generics about types of anchors, ports, prefixes To move to framework document Security questions How much do you trust DHCP server? How do you protect RAs (e.g. draft-ietf-v6ops-ra-guard) Binding state machine driven by observations of DHCP messages Filtering policies for data and control packets Handing lots of "special cases" Switch does "binding keepalive" probes to see if host is still there If there is MAC security, don't need START state Possibility of SAVI switch acting as DHCP relay (insert option 82) >> Show of hands: Should the SAVI WG adopt this document for DHCP? >> Many in favor (most in the room, about 40-50), none against -- Jari Arkko: Does the SAVI device actually send DHCP messages? -- Seemd to be implied by one of the slides? -- Bi: Only in special cases, for the hard part -- Arkko: That needs discussion, might want to not try to solve everything -- e.g., trying to handle all cases where hosts move -- Bi: If there is only host port, we don't need it. -- That's why I said the switch could act different at differnt port type 5. Vogt: Liaison from Broadband Forum Request for help detecting duplicate link-local addresses Also, problems for SLAAC because host-host comms always go through a router -- Baker: Solution for the routing stuff probably needs to come from ND authors, not here -- Bagnulo: There may also be implications for SeND Dave Allan: Discussion of BBF liaison If you make link-local addresses from MAC addresses, no problems, else risk of dupes And some NIC manufacturers are cloning cards, including MAC addresses Split-horizon forwarding (TR-101); connection only exists between host and BB gateway Hosts can't see neighbors' traffic Unicast upstream, broadcast downstream Also happens with other media, e.g., PON Many routers will override bindings if the same address shows up twice -- J-M Combes: There is already a binding between the router I/F and the link-local address -- Allan: BNG fans in 10s of Ks of users, highly aggregated interfaces -- Vogt: Maybe what you need is just proxy-DAD in the BNG -- Allan: Concerns about how it would be implemented -- Vogt: Also concerns about reliability of DAD -- J-M Combes: Proxy-DAD is only defined for ULAs, not link-local -- Baker: This should be in 6man -- Allan: I'm planning to go to 6man 6. Jun Bi: CERNET/CNGI implementation update Goal: Accurately bill traffic to a specific host 1018 switches, 22K hosts installed at Tsinghua Univ. Six vendors implemented SAVI-CPS in ethernet switches "After trail deployment, no complaints from users yet" Handling multiple addresses per host (example: 61 addresses on a 24-port switch) Using native and 6to4 prefixes ~20K savi-switches is being deployed across CERNET2 CERNET Network Center is integrating SAVI into network mgmt systems e.g., working on a MIB to manage SAVI bindings and settings binding limits, whether enforcement is enabled Counting of allowed, blocked packets -- Barnes: How independent were the implementations? -- Bi: They did their implementations and brought them to CERNET for testing -- Automated testbed managed by a professor -- Lots of interactions on telecons, email lists -- Vogt: Valuable experments and feedback more later to the WG. [Last presentation omitted]