Subject: [SAVA] Re: [Int-area] Call For Participation and Interest: SourceAddress ...

From: HeinerHummel at aol.com ([email-masked])
Date: Wed Sep 20 11:51:07 2006

A quite alternate solution of this problem is to come up with what I would  
like to call "cascade forwarding": The DSLAMs of may be 11 % of  the requesting 
users add their (new) capability whether they can  be branching node for 
cascading down by e.g. 10. The overloaded server  selects the request it receives 
within some timeframe and sends out a list  of the requesting users and 
DSLAMs. Based on its individual position  within the list each capable DSLAM is able 
to forward this and the following  packets such that all will get to 100 % of 
the users.
The workload of any branching node is well confined - and the  malicious 
service attacks will stop: Because they cannot do any harm to any  specific server 
anymore.
 
Heiner Hummel
 
In einer eMail vom 19.09.2006 19:11:50 Westeurop?ische Normalzeit schreibt  
[email-masked]:

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

_______________________________________________
routing-discussion  mailing  list
[email-masked]
https://www1.ietf.org/mailman/listinfo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20060919/ddab582d/attachment-0001.htm