Source Address Validation Architecture - SAVA (Internet Area) Monday, March 19, 2007 ====================== Chairs: Paul Ferguson Ron Bonica Agenda: 13:00-13:30 Problem Statement - R. Bonica (RB in notes below). http://www.arkko.com/publications/ietf-68/sava/agenda.txt draft-sava-problem-statement-00 Bob Hinden - State what is the problem with source address spoofing? RB - Protection from DoS attacks (e.g., some bot attacks). RB - In some countries, packets are required to be sent from only legitimate owner and the network provider must be able to vouch for the source. RB - Could give different policy based upon source address. Tim Shepard - Is result anything more than drop or forward? RB - Probably only these two actions. Will clarify. Lars Eggert - Why is false positive unacceptable? False negative is a drop. Need to clearly define positive and negative. RB - False "positive" is bad because it means source is not validated, but the packet was passed anyway. DM Note (I don't recall reading the positive/negtive definition in any of the drafts). Eric Rescorla - Suggest clarification that consistent false positives is unacceptable. RB - False positive result assumed to be consistent for all packets Eric - Need to define false positives better. RB - Will define ia s "squishier" manner. Christian Fork - Downstream router do some MAC authentication? RB - Different solutions depending upon whether routers are in same or different networks. Dave McDysan - Was the RPF definition intended to include egress/transmit ACLs versus traditional definition of the source address being in the routing table. RB - Definition could be that the interface is the shortest path for the source address. The intent was not to include egress/transmit ACLs in the definition. ============================================================================ == 14:00-14:30 CERNET Testbed - J. Bi, J. Wu draft-wu-sava-testbed-experience Vishan Solomon - Application Requirements slide, want more than source address validation, but also have application level requirements. Wu - Scope extends to include protection of users (e.g., E-mail, Tim Taylor - If primary requirement is regulatory (e.g., vouching for source), then why is scope only IPv4? Wu - Believe it is difficult to support v4, and easier to support v6. Tim Taylor - Is regulatory requirement mandatory, or desirable when technology can support it? Wu - Believes that many countires require it. ?? - Does vouching for source of each requirement apply only to packets transmitted from country or packets received from Internet? Wu - Applies to packets received from within a country, and also to packets received from Internet. Latter requirement to do this from the Internet is a dream. RB - Distinguish between packets vouched for and those that cannot. ?? - Question on lessons learned. How does this relate to SAVA? Wu - Read bullets from slide. BCP 38 (ingress filtering) only applies to intra-AS. Eric Rescorla - Why don't regulators enforce/incent operators (e.g., a fine) to implement BCP 38 (ingress filtering)? RB - How do we get this to implemented by multiple providers. Dan McPherson - Implement a list of those ISPs that do BCP 38? RB - Packets could be from those who don't. Dan McPherson - Could the cure be worse than the disease? Establoshment, signaling could create another vector for a DoS attack. RB - Premature to say that solution is worse than cure since solution not yet defined. Isa Gao - SAVA differs from BCP 38 is where enforcement is applied. BCP-38 is deployed at source. Beneficiary of BCP38 is destination end. Design goal is to develop destination-based validation. Pera ?? - BCP 38 requires universal deployment to get benefit. Won't SAVA also require near universal deployment to achieve the benefit? 30,000 AS providers; establishing trust relationship! Paul Ferguson - Sender ID versus DCAM, referenced vouch by reference and a trust factor needs to be worked. Is there interest in BoF to take this forward into developing a particular solution. Eric Rescorla - To be useful, verify function needs to be enabled and sending function to mark packets. RB - More work for both parties to do SAVA and incremental benefit occurs as compared with BCP 38. Eric Rescorla - Benefit occurs with BCP38, what is benefit of tagging? Same game theoretic issue as DCAM. Sam - Benefit accrues is packet on send is marked. Moesha - BCP38 problem is management of multiple prefixes with IPv4. Does the same problem occur with IPv6 since there are fewer prefixes and they are better aggregated. Paul F - BCP38 is only first hop. If globally deployed, then higher the value. Performing closest to edge of hierarchy for performance reasons. SAVA hierachircally (could use TBD mechanisms) that does vouching between AS's. RB - Do ISPs see BCP38 being universally deployed? - No responses. Dan McPherson - BCP38 not universally deployed for IPv4. If cost for receiver based validation is much greater than source validation (BCP 38), then would it be less attractive? RB - That the cost not be greater than BCP 38 is a constraint on the solution. Dan McPherson - 50% of 55 clueful operators said they implement BCP38 or uRPF. Peka - Not sure if there is incentive not to deploy ingress filtering. Need to protect own networks management infrastructure. Need to either block all infrastructure destination address (prefixes) or else enfore the source. Have found that validating the source is easier. ========================================================================= Zhang - China Telcom Requirements presentation Eric Rescorla - Assess in bulk where IP address came from (e.g., AS), or assess in detail where the IP address came from (e.g., machine). Is the requirement for bulk or data endpoint authentication. Zhang - Not intended to support data endpoint authentication. ========================================================================= Duan Xiao Dong - China Mobile Use of NAT/NAPT on IPv4 makes identifying users and hackers. Appeared to be asking for AS level validation AND end user identity. Jari - Why should SAVA work with IPv6? Why is this needed with Mobile IPv6? Should this be talked about on the list. ?? - Will present later. ========================================================================= Miaofy Appears to be asking for AS level validation ========================================================================= 13:30-14:00 Framework - M. Williams draft-wu-sava-framework-00.txt Paul Ferguson - Could piggyback on sidr work for vouching. Need to add forwarding signature component to complement sidr routing component. Dave McDysan - Does the hierarchical domains of validation mean that both AS and individual validation are required? Mark - Yes. It provides a means to trace back. Eric R. - Receiver of validation can rely on what level? MW - Vouching is at the same level of hierarchy. PF - Made analogy of whois/ Netblock. RB - Believe that prefix is the best that can be done. ========================================================================= Steve Crocker? - Address marked as being validated, is it treated better and can damp out attacks. If packet arrives and is marked as validated, then it can be traced back to the vouching party. May not be sufficient to be able to take action. PF - Analogy You must be this high to validate an address. Tim Shepard - Source addressing with multi-homing must be supported RB - Attaching to multiple providers, both must also support BCP38. Tim Shepard - There may also be now provider independent IPv6 address blocks, which will make things more complex. This BoF could explain where IETF is in terms of architecture and source address assignment/ multi-homing. Erif Fronheim - This BoF should not address source address assignment/ multi-homing at the host level. BCP38 is inter-AS (e.g., multihoming of sites). Mark Andrews - BCP38 can be done at individual host level (not just BGP, OSPF or RIP). Dave Ferrit - RFC 3484 source address validation model has already been addressed. If host address document is to be updated, then it should be done there as well. Dan McPherson - Should also look at anycast, multicast (v4, v6). Also in use of address block allocations and assignments and punching holes in the aggregate advertised. ========================================================================= RB - 1. Do you believe that SAVA problem is significant enough to work on? Is it well defined enough to solve. Peka - Not well defined enough yet. Way too broad to solve problem that spoofed packets are sent. Steve Crocker - Extremely vital problem. Solveable. Multiple approaches possible. Premature to pick one before solution space is defined. Unclear how much is an IETF problem versus operator decision and would require cooperation across multiple fronts. Eric R. - Three problems 1) Person connecting who they claim to be. 2) Being able to reject traffic in real-time that have belive have been spoofed (e.g., DoS), 3) Tracing back to the source that is generating an attack (DoS source). RB - First is out of scope. Jari - Useful. More work needed on what needs to be done. RB - 2. Seen a framework. What part of framework is applicable to the IETF? Don Chen? - Why people aren't doing BCP38? Multihoming, laziness. Will they implement a more complex solution? Peka - New problem is non-adjacent ISPs. Eric R. - Any ISPs outside of China see a need to deploy this? Steve - Published a paper on several proposals on how to do this. Any scheme deployed must work incrementally and provide incremental benefit. Suggesting individual experiments and reports on these. Bob Hinden - Would like to first understand problem and some understanding of the solution space. Don't know what deployment choices would be. Would at least like to see some pointers to solution spaces as means to assess potential costs. RB - Fair comment. If presenters came with solutions, then IETF would have nothing to do. Owen Davis - Two forwarding mechanisms: BCP38 and validation point at other end of the path. Concern regarding processing power to implement the second mechanism. PF - Problem not unique to SAVA. Mark Andrews - Reflection attacks in general. Solution space must get down to the end host level. Should also be applicable to the receiving host. Solmon - 1) Problem definition and scope not clear, seemed to be basically regulatory. IPsec host-host usage questioned. 2) Also need to state incentives more clearly. Tim Shepard - Still don't know precise problem. No means to verify SA is not in itself a problem. List of problems where this would be a useful function is still fuzzy. Solution space could be different based upon the application space. For some DoS attacks, SA verification may not be the best approach. Non-deniability given in another talk is a very different problem. RB - Gave example of DNS-oriented attack that SA verification was needed. RB - At the point of the BoF, problem space is all over the place. Trying to look for problem to focus on. Dave Ferrit - Large architectural branching point. Lots of interest inside China, none heard so far outside of China. List of applications (DoS, accounting, etc.) from 2nd presentation. How big is the regulatory requirement, which goes down to the host level? May be fundamentally different problems. Peka, Jari 1) Create a working group that would ID problem and requirements and not work on solution (recharter would be necessary), 2) go straight to problems/requirements/solution non-adjacent inter-domain ISP problem, 3) work on better defining problem/requirements and bring back to another BoF, 4) work in IETF Opsec on getting BCP38 more widely deployed Show of Hands 1) Somewhat fewer than 3 or 4 2)Least 3 or 4) Most Jari - Conclusion is to continue work with problem statement and possible solutions, and go to operations area with further work. Bill Fenner - Come back with strong sense of the cost of the solutions. Touched on, but not a focus of the work so far. ========================================================================= 14:30-15:00 Charter Discussion - all