Re: [sig-policy] Requests from routing/packeting concerns
Thanks for sharing an example here.
It gave me a good picture of a case when we need records from the past -
hope it did to others on the list too.
izumi
Seiichi Kawamura wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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 at lists dot apnic dot net
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
>
> iD8DBQFJmokTcrhTYfxyMkIRAkzvAKCCDV76M5asq+H3iC1t3OrdUkYR8gCfe6Jb
> cGzoMoKRRt+V14ktYZdhx9w=
> =qkt+
> -----END PGP SIGNATURE-----
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy