Subject: RE: [SAVA] Re: [Int-area] Call For Participation and Interest: SourceAddress Validation Architecture (SAVA)

From: "Barry Greene \(bgreene\)" <[email-masked]>
Date: Tue, 19 Sep 2006 07:20:01 -0700

> A more general approach would be to create a mechanism that 
> allows recognizing packets that belong to approved sessions. 
> This can be because the session is towards an approved 
> correspondent, which is easy to determine with a return 
> routability check, or it can be after higher-layer 
> authentication/authorization.

Isn't that done with AAA and vendor specific 'session control'
implementation of BCP38 today?

I still do not see anything new. All I see in this public and private
discussion is a gross misunderstanding of BCP38 as a policy and the
breath of work in the industry done to enforce that policy. The only
thing I see a WG doing is to list the BCP38 enforcement mechanisms -
which then goes down the path of vendor advertisement.

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: "Barry Greene \(bgreene\)" <[email-masked]>
Date: Tue, 19 Sep 2006 11:01:00 -0700

That approach is wishful nirvana of how a massive network of networks
will work. I never thought that IETF was in the job of actively
influencing the business behavior of a company (which is the essence of
"[creating] stronger incentives to operators to apply source filters."
The data today is showing that spoofed source address attacks are not
the primary threat vector. But they could be in the future - which is
why doing more source address validation is important. But I don't see
it the IETF's job to tell Sprint, SingTel, VSNL, or Batelco how they
need to run their business. Vendors have already been down the path of a
wide range of innovation around BCP38 enforcement - in many areas
deploying technology which does more than IP source. Other standards
groups have also done their part - DOCSIS and TR-69 are two examples. 

Bottom-line, I'm not seeing enough to take the enthusiasm from a BOF to
a chartered WG. The BOF then WG crafting needs to point down to work
which will make IETF contributions. So you do the follow as suggested
areas of work:

-> Is universal BCP38 required? Informational RFC. This would catch up
people on the theories behind "you don't need it everywhere to influence
criminal behavior." 

-> Survey of BCP38 Mechanisms. Information RFC. Obviously people are not
caught up with what techniques have been developed to enforce BCP38

-> BCP38 ++. Update the work. Add L2, DSCP, and over all update of the
work.

Once these are done, you see if the WG wants to get into something
totally new (after knowingly reviewing all the existing Mechanisms).

> -----Original Message-----
> From: Mark Williams [mailto:[email-masked]] 
> Sent: Tuesday, September 19, 2006 10:06 AM
> To: Barry Greene (bgreene)
> Cc: Ronald Bonica; Pekka Savola; Jun Bi; 
> [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [SAVA] Re: [Int-area] Call For Participation and 
> Interest: SourceAddress Validation Architecture (SAVA)
> 
> The issue is not whether BCP38 works or not if applied. It 
> does, and that is not in dispute.
> 
> The issue is whether it will ever be applied in its current 
> form in enough places to make enough difference. As things 
> are, it doesn't look as if it will be. Recommended source 
> filters have been around for more than a decade now - I 
> remember applying them to my network back in the first half 
> of the 1990s. Despite this we still have a situation where 
> approaching a quarter of the endpoints in the Internet can 
> get a spoofed source address into the network. There are 
> several attacks out there that require a spoofed source 
> address, and many more that are much harder to shut down if 
> they do use spoofed source addresses. What's more there are 
> zombies out there that can detect the ability to use spoofed 
> source addresses and operate accordingly.
> 
> A medicine that the patient is not taking cannot effect a cure.
> 
> One area of focus for SAVA is to actually create stronger 
> incentives to operators to apply source filters. A second 
> focus is to come up with a system which works if coverage 
> does not approach 100%. BCP38 does not work because if 25% of 
> the network is not covered, then the blackhats can just 
> choose where to launch the attack from.
> 
> SAVA does not claim to be aiming to solve every security 
> problem in today's Internet. It is looking to significantly 
> reduce one kind of threat.
> 
> I think there are three questions that need to be asked here:
> 
> 1. Does the ability to insert packets with spoofed source 
> addresses into the Internet represent a threat? (I think it does).
> 
> 2. Are there measures currently in use that look likely to 
> solve the problem? (I think not, but agree there are measures 
> that would work if incentive to deploy could be made 
> sufficiently great.)
> 
> 3. Would it be a good thing if there was a coordinated effort 
> to improve the situation for IPv6 while it is still at a low 
> level of deployment? 
> (I think it would.)
> 
> cheers,
> 
> Mark
> 
> Barry Greene (bgreene) wrote:
> >
> > What you described is BCP38. OK. Done.
> >
> > Everything else are techniques/features/functions to 
> implement BCP38. 
> > We know that BCP38 works. We've got a lot of experience with it and 
> > there has been a lot of innovation to enhance BCP38 (BCP38 
> ++) so that 
> > you "know" the source address came from an authorized 
> source (i.e. in 
> > the world of Cable and ETTX/Metro/Carrier Ethernet).
> >
> > So back what is the point of Sava? I'm not seeing anything new? 
> > Pekka's worked on an BCP 38 experiences docs. RIPE is working on a 
> > BCP38 config guide.
> >
> >
> >
> > > -----Original Message-----
> > > From: Ron Bonica [mailto:[email-masked]]
> > > Sent: Thursday, September 14, 2006 1:07 PM
> > > To: Pekka Savola
> > > Cc: Jun Bi; [email-masked]; [email-masked]; 
> > > [email-masked]
> > > Subject: Re: [SAVA] Re: [Int-area] Call For Participation and
> > > Interest: Source Address Validation Architecture (SAVA)
> > >
> > > Pekka,
> > >
> > > You raise some very fundamental questions about SAVA. I 
> will try to 
> > > enumerate and answer them. If I get any of the answers wrong, I 
> > > invite the SAVA contributors to step up and correct me.
> > >
> > > First, you ask what it means for a packet to have a "valid source 
> > > address". It means that there is some degree of certainty 
> that the 
> > > packet originated at a site to which the address was 
> assigned by a 
> > > legitimate numbering authority.
> > > This is a much stronger statement than an alternative definition, 
> > > which claims only that the packet is not spoofing some well known 
> > > address (for example, one of your own backbone addresses).
> > >
> > > The degree of certainty that source address filtering and 
> uRPF can 
> > > provide is inversely proportional to the number of hops 
> between the 
> > > validating and originating devices. So, (although this might be 
> > > anticipating solutions), the SAVA architecture will 
> probably include 
> > > a source address filtering/uRPF component that will be 
> implemented 
> > > by upstream routers, and a signature component, by which the 
> > > upstream router notifies downstream routers that 
> validation has (or 
> > > has not) occurred.
> > >
> > > Next, you ask what network resource are protected by 
> SAVA. I think 
> > > that the answer is the entire Internet, but especially 
> the routers 
> > > that are close to the validating nodes. This is because SAVA can 
> > > identify all of the following classes of spoofed packets:
> > >
> > > a) spoofed packets that are bound for routers (in the local or 
> > > remote AS)
> > > b) spoofed packets that are bound for hosts, but cause router 
> > > interfaces to congest.
> > >
> > >                                      Ron
> > >
> > >
> > >
> > >
> > > routing-discussion mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/routing-discussion
> > >
> >
> > SAVA mailing list
> > [email-masked]
> > http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava
> >
> 
> --
> "Product roadmap and/or product discussion in this email set 
> forth Juniper Networks' current intention and is subject to 
> change at any time without notice.  No purchases are 
> contingent upon Juniper Networks delivering any feature or 
> functionality expressed or implied in this roadmap or product 
> discussion."
> -----------------------------------------------------------------
> Mark Williams                        Juniper Networks
> Liaison                              Beijing Office
> Academic Networking Sector           Tel: +86 10 6528 8800 x16032
> Asia Pacific                         FAX: +61 7 3251 0155
> [email-masked]                      Cell: +86 1370-111-4749
>