New Ideas for EINTAP Policies (was Re: [james@towardex.com: Re: [OCCAID] Proposal for EINTAP])

[James]

On Fri, Jan 14, 2005 at 11:01:22AM -0500, Miles Nordin wrote:
> >>>>> "j" == James  <james at towardex.com> writes:
> 
> anyway, i sent the story in before i conceded and then
> double-conceded, so now i'm in an awkward spot of still talking about
> this after i meant to shut up about it.  But, you said, if I don't
> like this policy you need more constructive ideas.

Thanks for your constructive ideas below. Please see my comments
in-line.

> 
> One idea is to make BGP mandatory.  

One issue with mandary BGP is, in our previous experience, IRC kids
actually found BGP intriguing due to the fact that they can actually
advertise their diverse and more "professional" type of connectivity
when they have next to no clue of what it does.

And quite frankly, OCCAID routers have too many BGP sessions that
sooner or later we are going to run with scalability problems. BGPd
on cr1.ewr2 is currently taking 20MB of active memory in just IPv6
stuff, not even taking full ipv4 internet routing table. (The 20MB
memory figure was taken out of 'top' output, not exaggerated) And
BGP convergence time on OCCAID lately has been noticeably slower than
it was one year ago due to too many sessions and the scan-based
approaches of bgp implementation in use.

Yet another reason for EINTAP -- get the load off of OCCAID backbone
routers.

> Maybe if you can make ``irc
> kiddies'' do some experimenting, you will still get abuse complaints
> and DDoSes, but at least you don't feel ill-used.  
> see actually a lot
> of the neatest stuff I've done is partly irc-related.  I'm running

There is a difference between an IRC kiddie and a systems/network
administrator using IRC. An IRC kiddie does not read the manual nor
find effort to locate clue, among other things.

I have no problem with neatest stuff done with IRC. But hopefully
what I just said above clearly identifies to you of the definition
of IRC kiddie amongst ourselves in the context of this discussion.

[ snip ]
> 
> But anyway, the best I've got is, if, with one member, you have a lot
> of the problems you have too many of, then take down the member's
> tunnel.  pow, that's it.  And write that up in the policy.  ``We don't
> have an abuse department, and too many DDoS can cost us sponsors, so
> whether it is your fault or not we may have to remove you, and the
> most we can promise is to talk to you first.''

This was the approach we took in the past, and nobody complained. But
we did lose one sponsorship due to this approach. When we took down
an abusive user like what you stated, that user launched an IPv4 DDoS
attack to OCCAID router's IPv4 end point.

This is another reason why we have formed EINTAP proposal to create
a framework to discourage new people from signing up whose intent is
to simply waste our time. Not only we have to deal with the end users
complaining here, we also have to deal with our bigger downstreams'
input as well as what our sponsors want to have for assurance that
their network will not be vulnerable by hosting an OCCAID router.
This is a far bigger issue than just free speech, internet censorship,
social engineering, etc.

Anyone who is new to the community should connect to an EINTAP first.
Once he can prove his usefulness to the community, then he may request
a direct connection. I think my "60 day review" proposal earlier does
just this, and I think in our sponsors' point of view, this creates an
assurance that hosting an OCCAID node will not get their whole network
DDoS'd. Unfortunately EINTAPs do take more risk now that they are
frontend interface for new members. But at the same time, EINTAPs
themselves are totally free to set their own policies, and we won't
even care if an EINTAP blocks IRC traffic or news traffic completely.
It is their network, their policy and we trust their judgement in
dealing with abuse from new users.

OCCAID itself creating policies to deal with new users is making some
users get way too angry about their free speech and first amendment
rights. It happened in the past, and it keeps happening. Which is why
we have the EINTAP framework so that we can leave the policies up to
each individual EINTAP's judgement, and OCCAID itself doesn't have to
get involved in the policies per se, and we can focus simply in
running the network.

So may be it does make sense to get rid of the dnsspam verbatim
completely out of the eintap.txt, and replace it with 60-day review
proposal I did earlier. What do you think? Sounds negotiable?

> 
> When I asked if it was okay to run an irc server, and you said ``well,
> people hide from DDoS in IPv6 though, because they can just drop their
> tunnel and keep using IPv4,'' I said, let me run it, and if you tell
> me it's a problem I'll move it back to v4-only, and if that happens I
> promise not to try to negotiate with you or bitch about it.

I said, you can run it. But if you get us DDoS attacked, we reserve
right to take measures to protect our network from such abuse.

> 
> It is pedantically broader and more restrictive since it gives you
> authority to drop any tunnel any time with a little warning---then no
> more abuse complaints.  It makes me a participant rather than an ``end
> user of the interweb.''  It gives me more power and flexibility in how
> I want to deal with the problems I'm causing, rather than forcing me
> to change a domain name which is transparently just trying to piss me
> off, not enlisting me for help.  It includes an obligation to the
> community rather than a ``disciplinary'' component or attitude.  And


> for irc problems this obligation is practical, becuase if you will
> just stop using IPv6 with your client or server, the DDoSes and the
> abuse whiney social-engineering noise should stop.  

Sorry I can't understand.. Could you re-elaborate this more?

[ snip ]
> month contract at any time after giving you one week notice to stop
> sucking and expect a pro-rated refund.''
> 
> But since I'm not getting bills, I just assume there is a vague policy
> like this under everything, whether it's written down or not.

This was the policy we had. Then you demanded that we write it out
so you know about it before signing up. But it wasn't just you who
demanded it, few others also have off the record. So I'm not trying
to put blame on you or anything. 

So now we are trying to write it out. But I think OCCAID shouldn't be
involved in this, we should just let the individual EINTAP's deal with it.

-J

-- 
James Jun                                            TowardEX Technologies, Inc.
Technical Lead                      Boston IPv4/IPv6 Web Hosting, Colocation and
james at towardex.com            Network design/consulting & configuration services
cell: 1(978)-394-2867           web: http://www.towardex.com , noc: www.twdx.net