[ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact

[Owen DeLong]

--On Wednesday, March 12, 2003 8:52 AM -0700 "John M. Brown" 
<john at chagres.net> wrote:

> forgive me if I seem nieve....
>
That's OK, John, we forgive you :-)  (Sorry, John, couldn't resist)

> packet enters NSP's network,
> SRC_IP is 192.168.1.1
> DST_IP is 209.152.187.30
>
> router looks for a route to the DST_IP and fwds
> the packet out the appropriate interface.
>
Um, yeah.

> otherwords, Routers look at DST IP when making
> fwd'ing decisions, NOT SRC ip.
>
Absent policy routing or URPF, that's true.

> hence  a ip route 192.168.0.0/16  null0 15 would
> do nothing for this packet, since its the SRC
> that is spoofed.
>
Right.

> Null routing would drop the reply packet that 209.152.187.30
> generates and sends back in response.   But in general
> that is already done because 192.168.1.1 isn't in
> 209.152.187.30's next hop routers table.
>
Um only if the router doesn't have a default route, which, in my experience,
would not be the majority of routers on the internet.  Most routers in my
experience, especially the ones suffering from out-of-date bogon filters,
tend to be in the DEFAULT zone, not the DEFAULT-FREE zone.

>
> Ergo, you have to filter based on the SRC_IP at the
> ingress to the network.
>
That would be nice.  If you have a way to get routers to dynamically update
their SRC_IP ingress filters based on some form of distribution protocol,
I'm all ears.  I didn't say I solved the whole problem (in fact, I'm pretty
sure I said I didn't).  However, I think I solved _PART_ of the problem.

> If I missed some new cisco or juniper feature that
> now causes a router to forward based on SRC_IP, other
> than URPF thingy.
>
Nope... The URPF thingy goes a long way on solving the other half if we
implement my half, though.

Owen

>
>> -----Original Message-----
>> From: McBurnett, Jim [mailto:jmcburnett at msmgmt.com]
>> Sent: Wednesday, March 12, 2003 4:30 AM
>> To: john at chagres.net; Dr. Jeffrey Race; ppml at arin.net
>> Subject: RE: [ppml] Policy Proposal 2003-1a: Required
>> Performance of Abuse Contact
>>
>>
>> JOhn,
>> I don't see it quite that way...
>> Unless Sprint is using RFC1918 address in it's network
>> infrastructure, why not just use Null routing? 1 instace
>> takes care of the whole network... And if it is redistributed
>> via iBGP then no need for a blue gazillin of ACLs..
>>
>> Anyway,
>> Jim
>>
>>
>>
>>
>> > -----Original Message-----
>> > From: John M. Brown [mailto:john at chagres.net]
>> > Sent: Wednesday, March 12, 2003 4:07 AM
>> > To: 'Dr. Jeffrey Race'; ppml at arin.net
>> > Subject: RE: [ppml] Policy Proposal 2003-1a: Required
>> Performance of
>> > Abuse Contact
>> >
>> >
>> > Yes the system is broken.  Service providers need to start
>> filtering
>> > on the edge of their networks to prevent bad packets from entering
>> > their networks.
>> >
>> > Socially SPAM needs to be addressed in a manner that allows
>> > people(natural or otherwise) to affect self-help and be
>> provided the
>> > tools to take legal action against the spammers.  Much like
>> the TCPA
>> > does with junk-fax.  You don't see the "phone company" revoking a
>> > phone line because its been used for sending junk faxes.
>> >
>> >
>> > When service providers like Sprint (AS 1239) and UUNET (AS 701)
>> > actually apply ingres filtering in such a manner that we no
>> longer see
>> > RFC-1918 packets on edge transit links, then we will be getting
>> > someplace.
>> >
>> > Oh BTW  filters on a Sprint Ingress link show:
>> >
>> > rt01#sh access-list as1239-in
>> > Extended IP access list as1239-in (Compiled)
>> >     deny ip 10.0.0.0 0.255.255.255 any (618129 matches)
>> >     deny ip 172.16.0.0 0.15.255.255 any (254224 matches)
>> >     deny ip 192.168.0.0 0.0.255.255 any (488749 matches)
>> >     deny ip 169.254.0.0 0.0.255.255 any (716 matches)
>> >
>> > This is during a 24 hour window, on ONE customer DS3
>> interface. Wonder
>> > what the aggregate count would be across their entire net. (Prolly
>> > less than a OC12 worth of traffic)
>> >
>> > (ARIN, RIPE, APNIC Please revoke their AS, all their routes from the
>
>> > internet because they allow spoofed packets to enter their networks)
>> >
>> > This is clearly ABUSE as the IETF has specified that IP
>> packets labled
>> > with these integers (RFC-1918) MUST NOT be routed to the global
>> > Internet.
>> >
>> >
>> > So "We can conclude" that Sprint is abusing a majority of its
>> > customers with low volume DDOS by allowing these packets to
>> > exist....
>> >
>> > May I ask, who is going to Pay Sprint to place these filters on
>> > every edge router in their global network???
>> >
>> > May I ask, who is going to revoke AS 1239 and remove its ability to
>> > be used in the global BGP routing tables ??   I think, speaking
>> > for our client, that should that happen the org that causes this
>> > problem (in this case ARIN) would be facing legal action for
>> > interfering with interstate commerce and for possible RICO,
>> anti-trust
>> > practices, and interfering with contractual relations that
>> it is not a
>> > party to.
>> >
>> > Bluntly, this is a bad idea and deserves a red t-shirt.
>> >
>> > And for the record.  Our client thinks Sprint runs a pretty
>> darn good
>> > network.  We only used their name and stats as a way of putting
>> > reality to this proposal.
>> >
>> >
>> > Msg to ARIN AC and BOT.  Please spend your time on
>> something like say,
>> > IPv6 and making those resources more available to people
>> that want to
>> > start using them.
>> >
>> > john brown
>> >
>> >
>> > >  We can also conclude that
>> > > unless a discipline mechanism is adopted, problems of viruses,
>> > > trojans, spam and ddos will continue to multiply, as they are now.
>
>> > > The rising numbers for all of these metrics show the system as now
>
>> > > operated is broken.
>> > >
>> > > Jeffrey Race
>> > >
>> > >
>> > >
>> >
>> >
>>
>