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 PROTECTED]:
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 PROTECTED]
> > Sent: Thursday, September 14, 2006
1:07 PM
> > To: Pekka Savola
> > Cc: Jun Bi;
[EMAIL PROTECTED]; [EMAIL PROTECTED];
> >
[EMAIL PROTECTED]
> > 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 PROTECTED]
> >
https://www1.ietf.org/mailman/listinfo/routing-discussion
>
>
>
> _______________________________________________
>
SAVA mailing list
> [EMAIL PROTECTED]
>
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 PROTECTED]
Cell: +86
1370-111-4749
_______________________________________________
routing-discussion
mailing
list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo
|
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
