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

  • To: Terry Manderson <terry at terrym dot net>
  • Subject: Re: [sig-policy] Requests from routing/packeting concerns
  • From: Seiichi Kawamura <kawamucho at mesh dot ad dot jp>
  • Date: Wed, 18 Feb 2009 14:05:23 +0900
  • Cc: Izumi Okutani <izumi at nic dot ad dot jp>, sig-policy at apnic dot net
  • Delivered-to: sig-policy at mailman dot apnic dot net
  • In-reply-to: <361110AF-1C90-4047-8D29-300D80972DE8 at terrym dot net>
  • 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> <361110AF-1C90-4047-8D29-300D80972DE8@terrym.net>
  • User-agent: Thunderbird 2.0.0.19 (Windows/20081209)
    • 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 at lists dot apnic dot net
      >>>> http://mailman.apnic.net/mailman/listinfo/sig-policy
      >>>>
      *              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)
      
      iD8DBQFJm5cScrhTYfxyMkIRApYNAJ9xk3WHCxjbxUom1kDkuTM/DJK0uQCfQcgb
      nPVUa6qGNhKHPIqjYi867ww=
      =uXmb
      -----END PGP SIGNATURE-----