Subject: [SAVA] FWD: Notes from SAVA BoF

From: fergdawg at netzero.net (Fergie)
Date: Tue Mar 20 23:06:30 2007

Much thanks to Dave for taking notes.

- ferg

---------- Forwarded Message ----------

> From: Dave McDysan [mailto:[email-masked]]
> Sent: Monday, March 19, 2007 7:06 AM
> To: 'Ronald Bonica'; Paul Ferguson (RD-US)
> Cc: [email-masked]
> Subject: Notes from SAVA BoF
> 
> Ron, Paul,
> 
> Here are my notes. It was very hard to get some speakers names, their
> questions and the very interactive discussion.
> 
> Dave
>
========================================================================
=
> Source Address Validation Architecture - SAVA (Internet Area)
> 
> Monday, March 19, 2007
> ======================
> 
> Chairs:
> Paul Ferguson <[email-masked]> Ron Bonica
> <[email-masked]>
> 
> 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.
> 
> Pecka - 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
> 
> 
> 
> 

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/