Per,
your posting is insightful.
On enforcement of any measures: you are absolutely correct. SAVA, as a
technical approach cannot change the outline of the
political/sociological/economic discussion, nor should it aim to. The
aim is to change the values of some of the parameters that get plugged
into that discussion in such a way that the output changes.
For the scenario that you painted:
1. Forcing equipment vendors to make BCP038 the default behaviour of
their equipment. This is a good idea at first glance and may well prove
to be a good idea on deeper discussion as well. It has certainly cropped
up in discussion in the SAVA context.
Note however that BCP038 is defined in such a way as to be implemented
by an intelligent person on whatever equipment they may have in a
network they understand. It is not defined in a way that is easily
performed mechanically by equipment that does not think or know the
design of the network it is part of. Nor is there any consensus today
(mainly because it hasn't been dealt with in a standards forum) of what
making BCP038 the default behaviour really means. I suspect most people
who know their stuff would have a pretty good intuitive understanding
but it needs to be defined so router vendors can implement it and
operators know what to expect when they get the software load that
implements it.
Thinking about what happens in the period after this feature becomes
available, I can imagine that there would be quite a lot of effort
required a network of the scale of the IPv4 Internet to accommodate a
sudden change in the default behaviour of equipment. This is the reason
why SAVA has taken the approach of dealing with IPv6 only. At the
current level of deployment of IPv6, with a lot of the standards still
pretty fluent, we can still conceive of significantly altering the
behavior of routers in this way.
I would see a definition of how to make BCP038 compliant ingress filters
the default behaviour for IPv6 routers as a definite candidate for a
SAVA draft. It's definitely within the scope. (May also be within scope
for existing WGs)
2. This would certainly make a difference. There is in fact software out
there that can do this, freely downloadable from
http://spoofer.csail.mit.edu/
and if you follow some links you can see some very interesting and maybe
even surprising details of where you need to be if you want to spoof
source addresses.
3. This is also an area included within the SAVA framework. It is
non-trivial, however. How do you know when you trust a domain to be SAVA
compliant, and what can you and can't you do when you know that?
There is quite a large body of research around this topic in existence
and many solutions proposed, some as research papers and some already in
I-D format. To date we have been reticent to put forward too much detail
about the proposed solution, first because the body is large and
potentially confusing, second because we don't want to give the
impression that all the answers have been canvassed already and hence
discourage people with ideas from putting them forward and third because
the solutions are irrelevant to the discussion in hand at the moment,
which is to ascertain consensus on:
1. Does the forum consider spoofed source addressing to be a problem?
2. If Yes, does the forum consider it to be a problem that the IETF
should address?
If the first two answers are in the affirmative, then we would wish to
invite people to take part in the mailing list and if possible to attend
a BoF to go to the next question:
3. Does the forum regard this as a problem as one that should be
addressed by a WG within the IETF? (At this point some discussion of
potential solutions is of course relevant because the test fails if no
solution is possible or if there is nobody prepared to work on it.)
cheers,
Mark
Per Heldal wrote:
On Wed, 2006-09-20 at 01:06 +0800, Mark Williams wrote:
[snip]
A medicine that the patient is not taking cannot effect a cure.
Spot-on.
You may find any number of technical solutions to the problem, but it
won't help much unless the ops-community is prepared to enforce
implementation. I.e. it becomes a political issue more than a technical
one.
Imagine:
1. Operators agree to boycott equipment vendors who fail to make
BCP38-compliance the *default* behavior of their equipment.
2. A significant software supplier (e.g. OS vendor) including spoofing
probes in their SW. You can't reliably test BCP38 compliance of remote
networks unless probes are deployed within the tested network. Imagine
every internet-attached PC or MAC probing a couple times a year. That
should give a decent indication of which networks do allow spoofing or
not.
3. Transit-operators filter "spoofing-friendly" prefixes from
routes-received until the problem is fixed.
This could eliminate spoofing, with of without SAVA. The remaining
question is whether the ISP-industry is prepared to implement this kind
of self-regulation before influential but less-clued elements impose
measures that may be a lot more destructive.
SAVA may prove good for the future, but it'll take years for any
standard defined today to find its way to all corners of the net, and
for all non-compliant legacy equipment to be removed.
//per
--
"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
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
