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

  • To: sig-policy at apnic dot net
  • Subject: Re: [sig-policy] Requests from routing/packeting concerns
  • From: Izumi Okutani <izumi at nic dot ad dot jp>
  • Date: Tue, 17 Feb 2009 19:00:41 +0900
  • Delivered-to: sig-policy at mailman dot apnic dot net
  • In-reply-to: <499A8913.3030601 at mesh dot ad dot jp>
  • List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy>
  • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
  • List-post: <mailto:sig-policy@lists.apnic.net>
  • List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
  • References: <49954E5C.90500@mesh.ad.jp> <m2skmiv82a.wl%randy@psg.com> <49995358.60508@nic.ad.jp> <49995D7F.9090505@nic.ad.jp> <49995ECE.8000906@nic.ad.jp> <38091C56-CF55-460A-96AC-45BF511C3678@terrym.net> <499A7FEE.7030403@nic.ad.jp> <499A8913.3030601@mesh.ad.jp>
  • User-agent: Thunderbird 2.0.0.19 (Windows/20081209)
    • 
      
      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