Source Address Validation Improvements -------------------------------------- Chairs: Christian Vogt and Danny McPherson Note Takers: Ralph Droms, Behcet Sarikaya, Mark Williams 1. Christian Vogt - Introduction Christian Vogt gave presentation on ... Reviewed some existing solutions; gave evidence that existing solutions are insufficient. Three scopes: - local link - admin domain - cross domain SAVI will focus on the local link scope and where absolutely necessary will touch on the admin domain. ** See Powerpoint! 2. IPv4 Source Guard - An existing technique - Fred Baker 10 min ----------------------------------------------------------------- for source address validation on the 1st hop Fred Baker, draft-baker-sava-cisco-ip-source-guard-00 Main thrust of this presentation is to show that, for IPv4, the problem does have a solution, and that it is standardisable. Description of Cisco savi package that is a candidate for standardization. IPv4-only; set of features that associates an IP address with a port and discards any datagrams with other (assumed spoofed) source addresses. There are cases this feature set doesn't address; in fact, it may be problematic in some scenarios. Value is accepting only datagrams with valid source addresses; assumption is, then, that all traffic is valid. Already implemented byCisco, Foundry and probably thers. *** See Powerpoint! Erik Nordmark: Hosts that implement failover (link bonding, etc) will move an IP from one "trust anchor" (i.e. a switch port, VLAN, wireless access point link association, etc.) to another on failover. A decision must be made as to whether this will be addressed. Hannes Tshcofening: You say that there are many attcks not covered. Why is it useful? Fred: To guard against attacks, you have to do A, B, C.... What is described here is "A". It does not do everything. It just guards against spoofing in the access network. Hannes Tschofening: Value of spoofing as an attack method is not that great any more. 3. Source Guard for IP version 6 Fred Baker 15 min ------------------------------------------------------------------ Fred Baker, draft-baker-sava-implementation-00 Similar to source guard for IPv6 only. Three cases in draft. Assumptions: - addresses assigned using DHCP or SAA - multiple addresses per interface - potentially multiple VLANs - potentially multiple prefixes on a link Defines several alternative trust anchors; trust mapping is IP address-> trust anchor to allow multiple addresses per interface. Switched LAN: snoop ND. Non-switched LAN: Hosts/routers snoop ND to determine negotiated addresses. Upstream router can use RPF for "defense in depth". Can fix "snaky case" by only sending datagrams with a source address assigned to the interface on which the datagram is sent. Sam Hartman: What discussion is in order at this stage? Chair: at this stage, queries directly to Fred's solution: Sam Hartman: - Breaks Virtualization, and where there are lots of macs behind the one port - My problem here is that the corner cases are exactly the cases that happen on office laptops and pcs. mobility and virtualization are both common on my networks - doesn't like solution - Please don't use the term "Trust Anchor" in that way! Eric Rescorla breaking down the classes of things this fixes for tracking DoSes, the hard part is finding which subnetwork the attack is coming from, not picking the subnet. What are the important cases? I don't buy internet scale dos as a reason. Fred: it works as stated where it is. Tracking source of DoSes is is separate problem. Comment (unknown): There are some metropolitan networks where a subnet spans many subscribers so this has value behond subnet granularity Ilitsch van Beijnum Must it cover all "corner cases"? Fred: No it doesn't have to cover all corner cases. Primarily useful in access networks for SPs or in Enterprise networks. Dave Thaler: one other limitation (IPv6 case) is when you use things like a switch port for trust anchor - if things roam from one "trust anchor" to another "trust anchor" then a roamer is indistinguishable from an attacker. How do we support roaming? Dan Colin: If a switch snoops IP addresses in route announcements coming from a router, then routers could be handled. Jari Arkko: On topic of corner cases, we could (a) try to solve them all and make the solution complex (b) turn off as required to avoid corner cases Barry Greene: Is it worthwhile to have a WG for this? Is it time to re-look at the principle of BCP38? Maybe when we have a breathing space it is worthwhile to have a WG to bring in all the various work, standardise, etc. Maybe we should look a wider spoofng issues as well, including e.g. MAC spoofing. Erik Nordmark: Moving between switch ports might be recognized through loss of connection to "moved from" port. We could proceed in 2 ways: (a) as strict as possible, in which case it needs to be turned off by default (b) "safe" so it can be turned on by default Eric Rescorla Suppose I have a /28. Narrowing down the number of addessed a host could use from 16 to 1 Seems to be Lots of complication for limited results; attack vector analysis would be useful Richard Pruss: sometimes it is not 16, but many thousands, in which case it is highly applicable. 4. Discussion (Cristian Vogt Chair) 25 mins --------------------------------------------- 4a. Review of Charter --------------------- Christian Vogt: - talk about charter. * generalise to include other link layers * generalise to have routers as well as switches David Oran: DO WE really mean hosts (not host interfaces)or do we mean host interfaces? The differentiation is crucial. Eric Nordmark: Interface moving between ports will fail? (Yes) 4b Review of Milestones ----------------------- Fred: IP sourceguard draft should not be taken to RFC because of IPR considerations. In the end we want a WG draft, not a Cisco draft. Sam Hartman - not convinced it is worthwhile the IETF doing. - But if it is, the proposed solutions would be actively harmful to the Internet. The corner cases are cases that come up on regular networks and it would break regular networks need to support multiple addresses and multiple MACs for IPv4, and supoprting movement is a strong SHOULD+ - Should be narrowly scoped and any broadening should be the subject of further discussion with the community. Eric Rescorla: how/why is it standardisable? Ans: So we can get an RFC/BCP number for equipment specifications. Hannes Tshcofening: not convinced that this is an important problem given the types of attacks we see today and on an open network, knowing the IP address doesn't help Chair: Not a solution with an end-to-end benefit; doesn't address inter-domain case; Ans: these limitations are recognized. Mark Williams: Addresses significant problems. The fact that there are lots of problems left to solve does not make this not worth solving. In my previous life managing a large enterprise network, would have been very happy to have this kind of facility. Should be standardised by the IETF because it makes it more procureable. Jari Arkko: It's no silver bullet, but since several vendors do it, it shows there's demand in the market for this. 5. Questions to BoF: -------------------- Question 1: (Is this an area in which the IETF should work?) Yes: About 70% of room (>100) No: <5 Question 2: Who will work? About 15-20 Question 3: (is this charter a reasonable starting point? Yes: 25-30 people yes (~20% of room?) No: about 10 people Jari Arkko: The conclusion that I am getting from this is that there is interest, but charter needs work, and need to worry about corner cases