RE: Block traffic not orignating from ISP autonomous system

Then ISP-A should be doing unicast RPF at their edge to their upstream
providers to prevent this situation. Or ISP-B should be doing unicast RPF
towards the customer network to prevent this at the customer edge. Either
way this is out of your administrative control.

Regards,

Tyson Scott - CCIE #13513 R&S, Security, and SP

Managing Partner / Sr. Instructor - IPexpert, Inc.

Mailto: <mailto:tscott_at_ipexpert.com> tscott_at_ipexpert.com

From: jack daniels [mailto:jckdaniels12_at_gmail.com]
Sent: Wednesday, June 02, 2010 2:48 PM
To: Tyson Scott
Cc: Cisco certification
Subject: Re: Block traffic not orignating from ISP autonomous system

Hi Tyson,

User X is spoofing IP address of user of ISP-A and sending request out
(uplink to internet) via ISP-B.....Traffic is coming back from
internet(downlink) via ISP-A......which is issue for ISP-A....ISP-A wants to
block such requests , if request not going out from ISP-A....Hope it makes
clarity...Please ask me if more info required ...Thanks

On Thu, Jun 3, 2010 at 12:10 AM, Tyson Scott <tscott_at_ipexpert.com> wrote:

You are looking at a pretty tough scenario or I am not understanding your
situation. Your explanation is pretty confusing.

Are you saying User X on ISP-X is sending traffic from an IP that ISP-A owns
and they are allowing that traffic. If so why is ISP-A not doing unicast
RPF on their edge for their own networks. This is supposed to be
implemented by ISP's per RFC 3330.

Or are you saying that User X is duplicating your address space and sending
traffic and the return traffic is being sent back to you like with a SMURF
attack. If so again why is ISP-A not implementing RFC 3330 filtering for
their customer address space.

If the above two are not the scenario Then where is User X.

Regards,

Tyson Scott - CCIE #13513 R&S, Security, and SP

Managing Partner / Sr. Instructor - IPexpert, Inc.

Mailto: tscott_at_ipexpert.com

From: jack daniels [mailto:jckdaniels12_at_gmail.com]
Sent: Wednesday, June 02, 2010 12:52 PM
To: Tyson Scott
Cc: Cisco certification
Subject: Re: Block traffic not orignating from ISP autonomous system

traffic is coming back from ISP-A , but orignating from another ISP......

traffic needs to be filtered on ISP-A, if not orignating in ISP-A....

how URPF can help in this case.

On Wed, Jun 2, 2010 at 7:25 PM, Tyson Scott <tscott_at_ipexpert.com> wrote:

Put unicast reverse path filtering on your inside interfaces to stop user A
from originating traffic internally from an external address.

Regards,
 
Tyson Scott - CCIE #13513 R&S, Security, and SP

Managing Partner / Sr. Instructor - IPexpert, Inc.
Mailto: tscott_at_ipexpert.com
Telephone: +1.810.326.1444, ext. 208

Live Assistance, Please visit: www.ipexpert.com/chat
eFax: +1.810.454.0130

IPexpert is a premier provider of Self-Study Workbooks, Video on Demand,
Audio Tools, Online Hardware Rental and Classroom Training for the Cisco
CCIE (R&S, Voice, Security & Service Provider) certification(s) with
training locations throughout the United States, Europe, South Asia and
Australia. Be sure to visit our online communities at
www.ipexpert.com/communities and our public website at www.ipexpert.com
<http://www.ipexpert.com/>

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of jack
daniels
Sent: Wednesday, June 02, 2010 7:18 AM
To: Cisco certification
Subject: Block traffic not orignating from ISP autonomous system

Hi Guys,

I'm facing a issue and stuck on a thought process , would appreciate if some

way you guys can show with your experience in industry -

ISSUE ----

user X spoofs IP ADDRESS OF ISP-A and sends traffic out to internet...
now when traffic is comming back via ISP-A... I want to block such traffic
which is not orignating from my ISP...
but catch here is ---- filtering is to be done in ISP ...so putiing acl for
each users and ports is not scallable.....
Please help with any way out ...

Thanks and Regards

Blogs and organic groups at http://www.ccie.net <http://www.ccie.net/>
Received on Wed Jun 02 2010 - 15:05:08 ART