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

  • To: Seiichi Kawamura <kawamucho at mesh dot ad dot jp>
  • Subject: Re: [sig-policy] Requests from routing/packeting concerns
  • From: Terry Manderson <terry at terrym dot net>
  • Date: Wed, 18 Feb 2009 10:05:30 +1000
  • 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: <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>
  • Sender: Terry Manderson <terry.mndrsn@gmail.com>
    • Seiichi,
      
      
      I think you are stepping into a world of litigation that probably won't exist.
      
      
      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.
      
      
      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).
      
      
      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:
      
      
      -----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