[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21

[Jason Schiller]

> On Wed, Jul 26, 2017 at 3:24 PM, Owen DeLong <owen at delong.com> wrote:

> > On Jul 26, 2017, at 07:20 , Michael Peddemors <michael at linuxmagic.com>
wrote:
> >
> > But, in keeping with your 'flippant' style, we do have some ISP's that
aren't responsible for the traffic that happens on their networks too ;)

> Well… We have ISPs that fail to act responsibly about traffic that
happens on their network. Saying they are not actually responsible is
another
> question which I don’t necessarily agree with.

three points:
1. This proposal is not trying to address the problem of how ISPs handle
abuse.

If that is a problem the community wants to tackle, lets define the problem
and propose policy in a DIFFERENT proposal

2. I do not believe the suggested changes impact how ISPs handle abuse.

How ISPs handle abuse is orthogonal  to this proposal.

3. How ISPs handle abuse is complicated and opaque and requires more
nuance and clarity about what is actually required for compliance.


As is said before compliance tends to be very good when it is either
required, or beneficial to the organization.


If an organization is trying in good faith, to follow ARIN rules, then they
will try to keep SWIP information for their networks accurate, as well as
for their down stream customers.

There is no ARIN requirement that a provider need to process or respond
to abuse complaints on their network space, nor that they take action on
downstream customers who fail to process  abuse complaints.

In some cases their are particular legal rules in particular countries that
some
types of abuse complaints are required to be processed, for example legal
take
down requests. I suspect you will find very high compliance in processing
these
types of abuse complaints.

In other cases there are unwritten standards of conduct that when violated
results
in a TOS agreement violation leading to loss of service.  I suspect you
will find a
wide mix in terms of what is permitted under various TOS (although
generally it is
expected that the requirements are at least as strict for down stream
customers)
as well as a wide mix on level of compliance in processing TOS abuse
complaints.

In yet other cases, media agreements will contractually require DMCA
violations to
be processed.  These are often completed by a pre-defined process and not
through
abuse@ email contact.   These will also have a wide range of compliance
directly
proportional to the strength of the contract and importance of the media
agreement.

In yet other cases there is an unwritten standard of conduct that when
violated results
in being published on a black list.  This also has a wide mix in terms of
what is needed
to be added and removed from the blacklist.  Furthermore there is a wide
mix of
corresponding behavior by blacklisted organizations from aggressively
cleaning up
black listed space and maintain a positive reputation (and usable IP space
for its
customers), to organizations that do not engage black listers.  Often times
innocent
customers are caught in the middle, and network abusers move on to new IP
space
often with newly stolen credentials, with very little that well meaning
providers can do
to prevent re-occurrence.


On Wed, Jul 26, 2017 at 3:24 PM, Owen DeLong <owen at delong.com> wrote:

>
> > On Jul 26, 2017, at 07:20 , Michael Peddemors <michael at linuxmagic.com>
> wrote:
> >
> > On 17-07-25 02:31 PM, Owen DeLong wrote:
> >>> On Jul 25, 2017, at 10:34 , Michael Peddemors <michael at linuxmagic.com>
> wrote:
> >>>
> >>> On 17-07-24 05:06 PM, Tony Hain wrote:
> >>>> I still don’t see any value in specifying length. What you are
> looking for is contact info for someone with a clue about how a given
> network works and using length as a really poor proxy. I could live with a
> fourth line:
> >>>> Any end network emitting SMTP system SHOULD provide SWIP.
> >>>> I just don’t know how that gets enforced in any reasonable way. In
> general SMTP & independent routing are the big targets needing accurate
> contact info, and length has absolutely nothing to do with either.
> >>>> Tony
> >>>
> >>> While I agree in principle, it CAN be provided by "SWIP" OR 'rwhois',
> and that should be pointed out, as rwhois is more flexible in the IPv4
> space, eg providing allocation information to the /32 level.
> >>>
> >>> This again goes to an earlier email where I described that it should
> be more conceptual, than specific ranges..
> >>>
> >>> It should be, "if a party is responsible for the originating traffic",
> then that party should be displayed via SWIP/rwhois.
> >> Well… That’s hard to implement in practice. How do we go about SWIPing
> all those home windows boxes to the hackers that are actually controlling
> the emitted traffic?
> >> Owen
> >
> > I assume you were being flippant/joking.  The person who should be
> contacted if the device is hacked in that case, would 'normally' be the
> ISP, unless the person notified the ISP that they were taking
> responsibility.  (Same way as they now request a static IP address instead
> of dynamic)
>
> Yes, Of course I was joking, but my point is that it really isn’t “the
> party responsible for originating the traffic” rather than “the closest
> knowledgeable party to the party responsible for the operation of the
> machine originating the traffic.
>
> > But, in keeping with your 'flippant' style, we do have some ISP's that
> aren't responsible for the traffic that happens on their networks too ;)
>
> Well… We have ISPs that fail to act responsibly about traffic that happens
> on their network. Saying they are not actually responsible is another
> question which I don’t necessarily agree with.
>
> Owen
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170727/075e544e/attachment.htm>