Maybe its timely for a SWIP/rWHOIS review? I think there is a great deal to be said for establishing whether SWIP is going to become burdensome with IPv6 allocations and consider whether a different architect eg <i>("run their own server which provides an rwhois-like service to lookup the status of the provider's prefixes"..M.Dillon)</i> is going to be advantageous.<div>
<br></div><div>RD<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I believe that the resource review policy would preserve the<br>
need for ISPs to keep SWIPs up to date or risk having their<br>
resources audited.<br>
<br>
Owen<br>
<br>
On Nov 30, 2009, at 2:22 PM, Danny McPherson wrote:<br>
<br>
><br>
> I'd like to know what folks here are thinking regarding<br>
> IPv6 and SWIPs.  In particular, a primary driver for SWIPs<br>
> today is to enable justification of additional addresses<br>
> (when the time comes).  SWIP data is clearly invaluable to<br>
> network operations and security folks, as well as law<br>
> enforcement, when investigating or dealing with various<br>
> incidents (not to mention many other uses, as many of you<br>
> well know).<br>
><br>
> I suspect that with such large IPv6 allocations, the need<br>
> to keep SWIP/(rwhois) data up to date will diminish, severely<br>
> hindering folks that use SWIP data on a regular basis.<br>
><br>
> Furthermore, while development of an RPKI is underway, it<br>
> really only deals with certification of routed number spaces<br>
> (as currently specified).  While I _think we don't want all<br>
> subsequent assignment/allocation data in the RPKI, I'm worried<br>
> we won't have it anywhere with IPv6 -- or in many different<br>
> places and formats.<br>
><br>
> I suspect at least a BCP (some form, some where) and some<br>
> community guidance is in order along these lines (i.e.,<br>
> SWIP-esque data is a must to some reasonable level of<br>
> granularity), I'd like to see what folks here are thinking<br>
> along these lines..<br>
><br>
> If I've missed this discussion here (or in other forums)<br>
> references welcome, a cursory search yields nothing expressly<br>
> related to this topic.<br>
><br>
> Thanks in advance,<br>
><br>
> -danny<br>
><br>
><br>
> _______________________________________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Mon, 30 Nov 2009 23:25:54 -0600<br>
From: Stan Barber <<a href="mailto:sob@academ.com">sob@academ.com</a>><br>
To: Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>><br>
Cc: arin ppml <<a href="mailto:ppml@arin.net">ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] SWIPs & IPv6<br>
Message-ID: <<a href="mailto:4B14A8E2.5020800@academ.com">4B14A8E2.5020800@academ.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
Owen,<br>
<br>
How real is the risk of being audited?<br>
<br>
I am not asking that flippantly. I just wonder if ARIN has ever audited<br>
and if so, what was the reason? Was it because of bad SWIP information?<br>
<br>
Owen DeLong wrote:<br>
> I believe that the resource review policy would preserve the<br>
> need for ISPs to keep SWIPs up to date or risk having their<br>
> resources audited.<br>
><br>
> Owen<br>
><br>
> On Nov 30, 2009, at 2:22 PM, Danny McPherson wrote:<br>
><br>
>><br>
>> I'd like to know what folks here are thinking regarding<br>
>> IPv6 and SWIPs.  In particular, a primary driver for SWIPs<br>
>> today is to enable justification of additional addresses<br>
>> (when the time comes).  SWIP data is clearly invaluable to<br>
>> network operations and security folks, as well as law<br>
>> enforcement, when investigating or dealing with various<br>
>> incidents (not to mention many other uses, as many of you<br>
>> well know).<br>
>><br>
>> I suspect that with such large IPv6 allocations, the need<br>
>> to keep SWIP/(rwhois) data up to date will diminish, severely<br>
>> hindering folks that use SWIP data on a regular basis.<br>
>><br>
>> Furthermore, while development of an RPKI is underway, it<br>
>> really only deals with certification of routed number spaces<br>
>> (as currently specified).  While I _think we don't want all<br>
>> subsequent assignment/allocation data in the RPKI, I'm worried<br>
>> we won't have it anywhere with IPv6 -- or in many different<br>
>> places and formats.<br>
>><br>
>> I suspect at least a BCP (some form, some where) and some<br>
>> community guidance is in order along these lines (i.e.,<br>
>> SWIP-esque data is a must to some reasonable level of<br>
>> granularity), I'd like to see what folks here are thinking<br>
>> along these lines..<br>
>><br>
>> If I've missed this discussion here (or in other forums)<br>
>> references welcome, a cursory search yields nothing expressly<br>
>> related to this topic.<br>
>><br>
>> Thanks in advance,<br>
>><br>
>> -danny<br>
>><br>
>><br>
>> _______________________________________________<br>
>> PPML<br>
>> You are receiving this message because you are subscribed to<br>
>> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
>> Unsubscribe or manage your mailing list subscription at:<br>
>> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
><br>
> _______________________________________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 1 Dec 2009 06:53:15 -0500<br>
From: John Curran <<a href="mailto:jcurran@arin.net">jcurran@arin.net</a>><br>
To: Stan Barber <<a href="mailto:sob@academ.com">sob@academ.com</a>><br>
Cc: arin ppml <<a href="mailto:ppml@arin.net">ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] SWIPs & IPv6<br>
Message-ID: <<a href="mailto:2C7B54B5-3261-4691-A7C1-A5165A1532F4@arin.net">2C7B54B5-3261-4691-A7C1-A5165A1532F4@arin.net</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
On Dec 1, 2009, at 12:25 AM, Stan Barber wrote:<br>
<br>
> Owen,<br>
><br>
> How real is the risk of being audited?<br>
><br>
> I am not asking that flippantly. I just wonder if ARIN has ever audited and if so, what was the reason? Was it because of bad SWIP information?<br>
<br>
Stan -<br>
<br>
  The resource review policy is relatively new, but ARIN has indeed been making use of when we see strong indication of fraudulent activities or related misappropriation of number resources.<br>
<br>
  While in theory resource review could be performed for any reason (including lax updates to SWIP information), it has been our practice to only make use of it where that the community is potentially being deprived of the use of numbering resources.<br>

<br>
/John<br>
<br>
John Curran<br>
President and CEO<br>
ARIN<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 1 Dec 2009 11:57:23 -0000<br>
From: <<a href="mailto:michael.dillon@bt.com">michael.dillon@bt.com</a>><br>
To: <<a href="mailto:ppml@arin.net">ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] SWIPs & IPv6<br>
Message-ID:<br>
        <<a href="mailto:28E139F46D45AF49A31950F88C497458044FE712@E03MVZ2-UKDY.domain1.systemhost.net">28E139F46D45AF49A31950F88C497458044FE712@E03MVZ2-UKDY.domain1.systemhost.net</a>><br>
<br>
Content-Type: text/plain;       charset="us-ascii"<br>
<br>
> I suspect that with such large IPv6 allocations, the need to<br>
> keep SWIP/(rwhois) data up to date will diminish, severely<br>
> hindering folks that use SWIP data on a regular basis.<br>
<br>
I think that a good way to counter this would be to provide<br>
an easy to use, standard way, for providers to report this<br>
information. The current SWIP system is not the way forward.<br>
<br>
A better architecture would be for every provider to run<br>
their own server which provides an rwhois-like service to<br>
lookup the status of the provider's prefixes. This service<br>
should allow for richer information to be provided than<br>
just assigned/unassigned. This provides the possibilities<br>
for providers to cooperate under the auspices of some other<br>
organization like MAAWG and agree to provide each other<br>
certain status information. For instance they could flag<br>
an address as a former SPAM source that was dealt with, or<br>
a botnet infestation that was cleaned, or any other status<br>
information that is useful to share.<br>
<br>
ARIN's role would be to produce the open-source software<br>
package to run this service, to define a minimum set of status<br>
to be reported, and to provide a mirroring service. In this<br>
way, the ISP's responsibility is to record the status in<br>
their database and to make sure that their status reporting<br>
server has access to the database. People can then query<br>
the ISP's server directly, or ARIN's mirror, or a 3rd party<br>
mirror at their liberty.<br>
<br>
In addition to lookups, the server should provide support for<br>
mirroring, i.e. it should be possible to query for all updates<br>
since a certain time, and get a batch feed of the changes for<br>
the ARIN mirror.<br>
<br>
Included in the minimum status information to be reported,<br>
should be the identity and contact information for the people<br>
who are charged with managing the network which uses<br>
particular address range. This should never be assumed to<br>
be the party to whom the addresses were assigned, but should<br>
by default be the ISP who owns the allocation. Rather than<br>
overloading the existing whois data with multiple meanings,<br>
this new service should make a serious effort to separate<br>
things so that the current status of an address block is<br>
reported clearly and unambiguously. And the protocol used<br>
for this should be extensible, for instance don't use a<br>
yes/no value for "assigned", but use a 3 digit status code<br>
with value 000 meaning unused, 001 meaning assigned, and<br>
all the rest of the values open for definition in future.<br>
And don't return a single code, but return a list of codes<br>
so that you can have either "001," or "001,202" meaning<br>
assigned and blocked for non-payment. REST may be the best<br>
protocol to choose for this status reporting.<br>
<br>
We have the opportunity here to fix the whois system and<br>
replace it with something that makes sense for the long<br>
haul, and get rid of the legacy of identifying system<br>
users to justify DARPA funding.<br>
<br>
--Michael Dillon<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 1 Dec 2009 12:01:47 -0000<br>
From: <<a href="mailto:michael.dillon@bt.com">michael.dillon@bt.com</a>><br>
To: <<a href="mailto:ppml@arin.net">ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] SWIPs & IPv6<br>
Message-ID:<br>
        <<a href="mailto:28E139F46D45AF49A31950F88C497458044FE731@E03MVZ2-UKDY.domain1.systemhost.net">28E139F46D45AF49A31950F88C497458044FE731@E03MVZ2-UKDY.domain1.systemhost.net</a>><br>
<br>
Content-Type: text/plain;       charset="us-ascii"<br>
<br>
>   While in theory resource review could be performed for any<br>
> reason (including lax updates to SWIP information), it has<br>
> been our practice to only make use of it where that the<br>
> community is potentially being deprived of the use of<br>
> numbering resources.<br>
<br>
Sounds like you are following the old maxim "You'll catch<br>
more flies with honey than with vinegar" and reserving the<br>
use of vinegar for the outrageous offenders. As it should be.<br>
<br>
I think that where there is non-compliance with ARIN<br>
rules, it is most often because the rules are confusing<br>
and the systems that one must be compliant with are<br>
hard to use. A better action would be to talk to people,<br>
find out what barriers are leading to non-compliance,<br>
and work to remove or minimize those barriers.<br>
<br>
--Michael Dillon<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Tue, 01 Dec 2009 08:33:01 -0800<br>
From: Ted Mittelstaedt <<a href="mailto:tedm@ipinc.net">tedm@ipinc.net</a>><br>
To: Danny McPherson <<a href="mailto:danny@tcb.net">danny@tcb.net</a>><br>
Cc: arin ppml <<a href="mailto:ppml@arin.net">ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] SWIPs & IPv6<br>
Message-ID: <<a href="mailto:4B15453D.2070309@ipinc.net">4B15453D.2070309@ipinc.net</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
Danny McPherson wrote:<br>
> I'd like to know what folks here are thinking regarding<br>
> IPv6 and SWIPs.  In particular, a primary driver for SWIPs<br>
> today is to enable justification of additional addresses<br>
> (when the time comes).  SWIP data is clearly invaluable to<br>
> network operations and security folks, as well as law<br>
> enforcement, when investigating or dealing with various<br>
> incidents (not to mention many other uses, as many of you<br>
> well know).<br>
><br>
> I suspect that with such large IPv6 allocations, the need<br>
> to keep SWIP/(rwhois) data up to date will diminish, severely<br>
> hindering folks that use SWIP data on a regular basis.<br>
><br>
<br>
I think it would be foolish to assume this.  You bought into<br>
this naieve notion that SWIP data is mainly of benefit to OTHER people,<br>
promulgated by all the bonehead privacy-terrorists out there who think<br>
that a SWIP filed on them will let the identity thieves steal<br>
them blind.<br>
<br>
In reality, SWIPs aren't for the rest of the Internet, they help<br>
make YOUR job easier.<br>
<br>
If you don't file SWIP data or run RWhois on your subnets, then<br>
the only SWIP<br>
entry that will exist for your subnet that's assigned by the RIR is<br>
going to be the one that the RIR inserted when they gave<br>
you your IPv6 assignment.  Thus, any time one of the orgs<br>
that you assigned subnets to goes and honks-off ME, well<br>
then YOU are going to get my complaint.<br>
<br>
If YOU want to waste all your time handling these complaints<br>
well then I don't give a rat's ass, but if you DON'T -handle- the<br>
complaint and your customer continues honking me off, well then I'm<br>
going to block YOUR ENTIRE BLOCK - because since you didn't<br>
file a SWIP how the hell am I going to know what part of<br>
your assigned numbers does this org have access to that<br>
is honking me off?  From my point of view, your ENTIRE block is<br>
suspect, not just the piece that you assigned to Wonkulating<br>
Gronkulators.<br>
<br>
So, for LIRS that want to pee all over themselves, well<br>
then don't file SWIPS.  In fact I ENCOURAGE IT STRONGLY because<br>
then all I have to do is null-route your ENTIRE AS, I don't even<br>
have to waste CPU cycles blocking just the obnoxious traffic<br>
from Wonkulating.<br>
<br>
><br>
> If I've missed this discussion here (or in other forums)<br>
> references welcome, a cursory search yields nothing expressly<br>
> related to this topic.<br>
><br>
<br>
Probably because of the same reason that a cursory search<br>
won't find any discussions about the pros and cons of<br>
staring straight into the sun for an hour at high noon.<br>
<br>
Ted<br>
<br>
> Thanks in advance,<br>
><br>
> -danny<br>
><br>
><br>
> _______________________________________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
ARIN-PPML mailing list<br>
<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a><br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
<br>
End of ARIN-PPML Digest, Vol 54, Issue 1<br>
****************************************<br>
</blockquote></div><br><br clear="all"><br><br><br>
</div>