[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sig-policy] Requests from routing/packeting concerns
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hello terry
> I think you are stepping into a world of litigation that probably won't
> exist.
I'm a network operator in an ISP in Japan. The 'lawsuit' part was just
an example (my imagination of) what may happen and thanks for the correction.
> As it is with RIRs and the statement of route suitability, any seller
> worth their salt will put in the deed of sale that they are not liable
> nor guarantee the prefix for any facets of routing, blacklisting, bogon,
> etc.
I'm sure they would. I would.
> As it is with conveyancing in .au (buying property), it is the buyers
> responsibility for due diligence in searching the titles office, and
> other databases for various effect that impact the property (I am not a
> lawyer).
yes. exactly. but knowing that the ex-ex-owner of
the prefix was notorious for spam would make it much easier to
determine its not worth the buy wouldn't it?
I tend to hear such opinion from data-center service operators
(providing collocation services, e-mail outsoursing, etc).
Its not just a routing issue that they are worried about.
spam blacklists, application blacklists, etc...
seiichi
>
> While I don't see harm in asking APNIC to publish the info. I have
> doubts as to its utility.
>
> Terry
>
> On 17/02/2009, at 7:53 PM, Seiichi Kawamura wrote:
>
> hi izumi
>
>>>> Another point that was mentioned that an operator wish to be aware of
>>>> the risks of "contaminated" space (black listed, etc) when obtaining
>>>> space and seeing past records help sometimes. you ofcourse have to do
>>>> more checks in addition.
>
> correct me if i'm wrong. my image of this problem.
>
> the following takes place inside one single ISP.
> A naughty customer-A will return the address after they have done
> all the bad stuff that needs to be done, and say the address was
> given to some good-behaving customer-B that were not effected by
> black lists (e.g the address was used for VPN puroposes).
> when cusotmer-C receives the address and gets blocked by blacklists,
> the ISP has ways to investigate to check if it was cutomer-B
> or customer-A that was doing the naughty behavior, such as
> checking customer profiles, logs, etc.
>
> now lets say if A was an ISP, B was one single corporate IT division,
> C was a small data-center. If C didn't know that the prefix was owned
> by A in the past, they may go and lawsuit B.
>
> seiichi
>
>
>>>> Hi Terry,
>>>>
>>>>
>>>> Nice to have a comment from another operator here.
>>>>
>>>> Terry Manderson wrote:
>>>>> Hi Izumi,
>>>>>
>>>>> On 16/02/2009, at 10:40 PM, Izumi Okutani wrote:
>>>>>
>>>>>> These were major requests from routing/packeting concerns.
>>>>>>
>>>>>> 1. To have a system that allows a third party to confirm
>>>>>> "authenticity" of address space. (prove you are the right holder)
>>>>>> A third party may mean an upsteam ISP, or to get internal approval
>>>>>> by non-tech people within an organization to obtain IPv4 resource
>>>>>>
>>>>>> Resource Certificate may provide an answer to the first needs, but
>>>>>> may be more studies are required for proving it to non-tech people.
>>>>> My reading of this, and do correct me if I'm wrong, is the underlying
>>>>> question of:
>>>>>
>>>>> "What, if any, tools are available that allows my non-technical people
>>>>> to verify that a new/existing customer has this 'new' prefix for which
>>>>> they are asking me to route?"
>>>>>
>>>>> yes?
>>>>>
>>>>
>>>> Not quite. (but thanks for trying to clarify)
>>>>
>>>> the idea is that a routing engineer might need to justify within their
>>>> organization (manager, account department, etc) that it is an authentic
>>>> address worth spending the budget when they obtain a resource.
>>>>
>>>> so it would help to have a tool/document published to do this. may be a
>>>> resource cert would be good enough but a concern is that it may be too
>>>> digital/techy for others to understand.
>>>>
>>>> That was a comment from one of the ISPs here. I wonder how general this
>>>> needs would be as the region?
>>>>
>>>>>> 2.Information from APNIC to help confirm the "cleaness" of address
>>>>>> Records on the past holders of the address space (not only the
>>>>>> previous, but all past holders by date) would help at the time of
>>>>>> obtaining the resource/trouble shooting for transfered space.
>>>>>> The public log defined in prop-050 is probably quite good overall to
>>>>>> but hope we can review more on other information which may be
>>>>>> required.
>>>>>>
>>>>> "cleaness" is interesting. I see the value in the immediately previous
>>>>> details, however due to the business climate and the way organisations
>>>>> are sold/bought/wound-up I suspect that the information used for
>>>>> trouble
>>>>> shooting, such as calling a 'long-ago' holder to get their upstream to
>>>>> change a filter, may not be all that useful due to ageing of details.
>>>>
>>>> I see. i wondered about this after your comment and asked Tomoya Yoshida
>>>> from OCN.
>>>>
>>>> Apparently, sometimes the issue or the problem doesn't just lie in the
>>>> previous holder, but could go a few times back, e.g. to remove address
>>>> from black list.
>>>>
>>>> Another point that was mentioned that an operator wish to be aware of
>>>> the risks of "contaminated" space (black listed, etc) when obtaining
>>>> space and seeing past records help sometimes. you ofcourse have to do
>>>> more checks in addition.
>>>>
>>>>>> They may sound more like operational details rather than policies, but
>>>>>> operators here feel it's quite important that we have them ready
>>>>>> before
>>>>>> implmenting this policy for the transfer policy to be work in real
>>>>>> life.
>>>>> I think bring forward operational realities is important. Any policy in
>>>>> the internet space that forgets the operational truths is at risk of
>>>>> being half-baked.
>>>>
>>>> right.
>>>>
>>>>>> i'll stop here for today...but I'll have to spam some more tomorrow
>>>>>> :-P
>>>>> :-)
>>>>>
>>>>> I don't consider this spam.
>>>>>
>>>> okay ~ you've encouraged me. I'll keep going.
>>>>
>>>> izumi
>>>> * sig-policy: APNIC SIG on resource management
>>>> policy *
>>>> _______________________________________________
>>>> sig-policy mailing list
>>>> sig-policy@lists.apnic.net
>>>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>>>
* sig-policy: APNIC SIG on resource management
policy *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
iD8DBQFJm5cScrhTYfxyMkIRApYNAJ9xk3WHCxjbxUom1kDkuTM/DJK0uQCfQcgb
nPVUa6qGNhKHPIqjYi867ww=
=uXmb
-----END PGP SIGNATURE-----
