[SAVA] RFC2827-bis comments solicitation

Two thoughts:

First of all, I think that you should take a look at:
         Service Provider Infrastructure Security
         draft-ietf-opsec-infrastructure-security-00
         http://www.ietf.org/internet-drafts/draft-ietf-opsec-infrastructure-security-00.txt

and
         Operational Security Current Practices
         draft-ietf-opsec-current-practices-07
         http://www.ietf.org/internet-drafts/draft-ietf-opsec-current-practices-07.txt

Also, a wild personal thought:

It seems to me that there are two things that could slow down
the deployment of BCP38 (source address filtering): (i) Equipment
(routers) that have trouble with performance when filtering is turned
on; (ii) The effort to configure it.  The first of these I think is gradually
going away, and we (the IETF) doesn't need to do much (other than
what RFC3871 and opsec are already doing) to encourage this to
continue to go away as an issue. The second of these issues, how
much configuration is needed, is another issue that we could in
principle try to make easier.

Now, at least at AS boundaries, *most* of what you want can probably
be taken automatically from the routing protocol. Specifically, suppose
there are two ASs, ASx and ASy that are directly connected, via a link
from Router Rx (in ASx) to router Ry (in ASy). Router Rx can look at
the BGP update that it gets from Ry, and if it seems that Ry is in a
stub AS (ie, the routing advertisement from Ry to Rx does not contain
any routes via any other AS, and also does not contain a default route),
then Rx *automatically* turns on source address packet filters that
restrict traffic from Ry to Rx to having source addresses which correspond
to the addresses that Ry advertises in its BGP update to Rx. It would
seem that a router would want to have a simple command to turn this
on or off on a per-interface basis, and we might need to educate folks
that stub networks need to advertise all of their addresses to each of
their ISPs.

Now, my first thought is that turning on filters in this case, only where
a service provider is directly attached to a stub network, is a big win
and might be enough for a next step. In theory we could also pass
additional information in BGP (such as an indicator that says "I am a
stub AS, please turn on the source address filter", or even more
complete information to allow packet filters to be turned on in "non-stub"
situations), but I don't think that this is needed to significantly improve
the current situation.

Ross

At 06:35 PM 11/13/2006 +0000, Fergie wrote:
>First, sorry for any duplicates, but we wanted to reach all
>interested parties.
>
>After several discussions with many different folks last week
>at IETF 67 in San Diego, as well as various people over the
>course of the past few months, Dan Senie and I have decided to
>undertake an effort to "update" RFC2827/BCP38 [1].
>
>I know that I'm not the only person who has heard various
>discussions in the past couple of years that concluded that
>(paraphrased), "BCP38 needs to be updated."
>
>Now is your chance to speak up. :-)
>
>We would very much like to solicit comments & suggestions from the
>community-at-large on areas where you feel BCP38 is lacking, or in
>areas where you feel it does not properly address with regards to
>prohibiting source-spoofed traffic from any given administrative
>network boundary, given that some technical aspects of the Internet
>may have changed since it's publication.
>
>While we acknowledge that a uniform application of a source address
>verification architecture/ingress filtering scheme will not mitigate
>_all_ "unwanted traffic" [2] in the Internet, it will most certainly
>address the issue of hosts which attempt to source-spoof traffic into
>the Internet.
>
>I have not set up a mailing list for this yet, but if there is
>enough discussion/input, I will make an effort to do so (or perhaps
>the SAVA mailing list [3] might be a good place for discussion). In
>the interim, you can contact me or Dan directly:
>
>  Paul Ferguson: fergdawg(at)netzero.net
>  Dan Senie:     dts(at)senie.com
>
>
>Thanks,
>
>fergie & dan
>
>
>p.s. Also, for anyone who might be interesting in related work,
>there is an effort to bring some additional work into the IETF
>called SAVA, or Source Address Validation Architecture [4].
>
>
>[1] http://www.rfc-editor.org/rfc/rfc2827.txt
>[2] http://www.iab.org/about/workshops/unwantedtraffic/index.html
>[3] http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava
>[4]
>http://www.nrc.tsinghua.edu.cn/pipermail/sava/2006-September/000004.html
>
>
>
>--
>"Fergie", a.k.a. Paul Ferguson
>  Engineering Architecture for the Internet
>  fergdawg(at)netzero.net
>  ferg's tech blog: http://fergdawg.blogspot.com/
>
>
>_______________________________________________
>SAVA mailing list
>SAVA@nrc.tsinghua.edu.cn
>http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava