Re: [sig-policy] Requests from routing/packeting concerns

[Seiichi Kawamura <kawamucho@mesh.ad.jp>]

-----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@lists.apnic.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-----