From: ccie2be (ccie2be@nyc.rr.com)
Date: Fri Sep 24 2004 - 11:51:37 GMT-3
James,
This is the error I report I get when sending you email.
******
The original message was received at Fri, 24 Sep 2004 10:48:12 -0400 (EDT)
from 24-90-216-214.nyc.rr.com [24.90.216.214]
----- The following addresses had permanent fatal errors -----
<james@towardex.com>
(reason: 550 <ms-smtp-01-smtplb.rdc-nyc.rr.com[24.29.109.5]>: Client
host rejected: Please use your ISP SMTP server to send emails.)
----- Transcript of session follows -----
... while talking to mx01.bos.ma.towardex.com.:
>>> DATA
<<< 550 <ms-smtp-01-smtplb.rdc-nyc.rr.com[24.29.109.5]>: Client host
rejected: Please use your ISP SMTP server to send emails.
550 5.1.1 <james@towardex.com>... User unknown
<<< 554 Error: no valid recipients
***********
Tim
----- Original Message -----
From: "James" <james@towardex.com>
To: <jean.paul.baaklini@accenture.com>
Cc: <ccielab@groupstudy.com>
Sent: Friday, September 24, 2004 10:33 AM
Subject: Re: Unicast RPF
> On Fri, Sep 24, 2004 at 10:09:36AM +0200, jean.paul.baaklini@accenture.com
wrote:
> > James,
> >
> > Thanks for your comments. I see what the issues are with URPF, what I
> > don't see is what the advantages are? Is it useful?
>
> It is a good BCP (Best Common Practice) to always enable uRPF at the edges
of
> your network. Edge, as in mostly aggregation routers that home in
downstream
> customers. uRPF not only helps you prevent your downstreams from spoofing
their
> source addresses, it helps the integrity of the internet as a whole.
Things like
> the recent "TCP scare" with respect to BGP sessions when someone found
> "vulnerability" with TCP (remember how everyone started crawling trying to
md5
> their bgp sessions a months ago?), would not have been *too* serioous if
many more
> ISP's utilized uRPF to prevent spoofed source addresses.
>
> Many service providers (not all of them) also employ uRPF at their border
routers
> with peering parties and transit providers (loose-mode uRPF in this case,
while
> using strict-mode on customer facing edge routers). Like I mentioned in
> previous email, having uRPF at the complete border line of your network
allows
> you to have another key security tool by having a scaled pseudo autonomous
> firewall for simple source address blocking thru a single ibgp/igp
advertisement.
>
> The industry trend today is that more and more providers are enabling uRPF
at
> least on their edge routers. At least one BIG "tier-1" backbone (Qwest)
recently
> enabled uRPF on almost all of their edge routers, and they are continuing
to do
> that to remaining routers, as a security policy change. And a lot of small
to
> medium sized networks, including former AT&T Broadband (now Comcast)
areas, and
> Road Runner also tend to install networks with uRPF enabled as well to
prevent
> their customers from spoofing their source addresses.
>
> Lastly though, one should be careful about potential performance impact
when using
> uRPF. Know your router first (although if it is all same, its probably not
much
> of an issue. but if your network uses different vendors, you shoud know
the limits
> of each product first before being too liberal with network changes)
before you
> really go out and do it. While uRPF is not a huge problem for an edge
router in
> general, it can become a performance issue when you put this on a border
router
> moving lots of bits, when the border router does not have an ASIC to deal
with
> this specific task. This is just like potential performance implication as
with
> adding an ACL on a router moving tons of bits :)
>
> What you have to know is when you turn on uRPF, your router now has to
lookup
> the FIB two times instead of once. First, to check the source address
against the
> FIB for RPF check, second to check the destination IP for respective
route. This
> may or may not be better as opposed to using ACL's depending on your
config..
> Cisco recommends uRPF as less-cpu-burden tool, but experiences from
certain
> network implementations show exceptional cases as well. (Like for example,
> checking against a two-line long input ACL will most likely be better over
uRPF in
> most cases[1]).
>
>
> [1] Two line long linear ACL being O(2) constant, where as MTRIE FIB is
mostly
> O(5) constant to come to a lookup match. Ofcourse there are other
factors
> involved too as algorithm between linear and trie, and RPF
implementation
> is a bit different.
>
> HTH,
> -J
>
> --
> James Jun TowardEX
Technologies, Inc.
> Technical Lead Network Design, Consulting, IT
Outsourcing
> james@towardex.com Boston-based Colocation & Bandwidth
Services
> cell: 1(978)-394-2867 web: http://www.towardex.com , noc:
www.twdx.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:48 GMT-3