[要約] RFC 9324 は、RPKIに基づくポリシーを実行するBGPスピーカーが、新しいRPKIデータを受信した場合には、ルートリフレッシュを隣接するネイバーに発行すべきでないことを述べています。この文書は、RFC 8481を更新し、完全なAdj-RIB-Inを保持するか、ROVによってドロップされたパスを保存して新しいRPKIデータに関して再評価できるようにする方法を説明しています。
Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 9324 IIJ Research Lab & Arrcus, Inc.
Updates: 8481 K. Patel
Category: Standards Track Arrcus, Inc.
ISSN: 2070-1721 P. Smith
PFS Internet Development Pty Ltd
M. Tinka
SEACOM
December 2022
Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh
ルートリフレッシュなしのリソース公開キーインフラストラクチャ（RPKI）に基づくポリシー
Abstract
概要
A BGP speaker performing policy based on the Resource Public Key Infrastructure (RPKI) should not issue route refresh to its neighbors because it has received new RPKI data. This document updates RFC 8481 by describing how to avoid doing so by either keeping a full Adj-RIB-In or saving paths dropped due to ROV (Route Origin Validation) so they may be reevaluated with respect to new RPKI data.
リソース公開キーインフラストラクチャ（RPKI）に基づいたBGPスピーカーの実行ポリシーは、新しいRPKIデータを受け取っているため、近隣のルートリフレッシュを発行すべきではありません。このドキュメントは、ROV（ルートオリジン検証）のためにドロップされた完全なadj-rib-inまたは保存パスを維持することにより、そうすることを避ける方法を説明することにより、RFC 8481を更新し、新しいRPKIデータに関して再評価される可能性があります。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9324.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9324で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
2. Related Work
3. ROV Experience
4. Keeping Partial Adj-RIB-In Data
5. Operational Recommendations
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
Memory constraints in early BGP speakers caused classic BGP implementations [RFC4271] to not keep a full Adj-RIB-In (Section 1.1 of [RFC4271]). When doing RPKI-based Route Origin Validation (ROV) [RFC6811] [RFC8481] and similar RPKI-based policy, if such a BGP speaker receives new RPKI data, it might not have kept paths previously marked as Invalid, etc. Such an implementation must then request a route refresh [RFC2918] [RFC7313] from its neighbors to recover the paths that might be covered by these new RPKI data. This will be perceived as rude by those neighbors as it passes a serious resource burden on to them. This document recommends implementations keep and mark paths affected by RPKI-based policy, so route refresh is no longer needed.
初期のBGPスピーカーのメモリの制約により、古典的なBGP実装[RFC4271]が完全なadj-rib-in（[RFC4271]のセクション1.1）を維持しないようにしました。RPKIベースのルートオリジン検証（ROV）[RFC6811] [RFC8481]および同様のRPKIベースのポリシーを実行する場合、そのようなBGPスピーカーが新しいRPKIデータを受信した場合、以前は無効とマークされたパスを維持していない可能性があります。次に、これらの新しいRPKIデータでカバーされる可能性のあるパスを回復するために、近隣からルート更新[RFC2918] [RFC7313]を要求する必要があります。これは、深刻な資源の負担を渡すため、それらの隣人によって失礼と見なされます。このドキュメントでは、RPKIベースのポリシーの影響を受けるパスを維持およびマークする実装を推奨するため、ルートの更新は不要になりました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
It is assumed that the reader understands BGP [RFC4271], route refresh [RFC7313], the RPKI [RFC6480], Route Origin Authorizations (ROAs) [RFC6482], the Resource Public Key Infrastructure (RPKI) to Router Protocol [RPKI-ROUTER-PROT-v2], RPKI-Based Prefix Validation [RFC6811], and Origin Validation Clarifications [RFC8481].
ProT-V2]、RPKIベースのプレフィックス検証[RFC6811]、および起源検証明確化[RFC8481]。
Note that the term "RPKI-based Route Origin Validation" in this document means the same as the term "Prefix Origin Validation" used in [RFC6811].
このドキュメントの「RPKIベースのルートオリジン検証」という用語は、[RFC6811]で使用される「プレフィックス起点検証」という用語と同じことを意味することに注意してください。
As Route Origin Validation dropping Invalids has deployed, some BGP speaker implementations have been found that, when receiving new RPKI data (Validated ROA Payloads (VRPs) [RPKI-ROUTER-PROT-v2]), issue a BGP route refresh [RFC7313] to all sending BGP peers so that they can reevaluate the received paths against the new data.
Route Origin Validation Dropping Invalidsが展開しているため、新しいRPKIデータ（検証済みのROAペイロード（VRP）[RPKI-Router-Prot-V2]）を受信すると、BGPルートの更新[RFC7313]を発行するBGPスピーカーの実装がいくつか発見されています。すべてのBGPピアを送信して、新しいデータに対する受信パスを再評価できるようにします。
In actual deployment, this has been found to be very destructive, transferring a serious resource burden to the unsuspecting peers. In reaction, RPKI-based Route Origin Validation (ROV) has been turned off. There have been actual de-peerings.
実際の展開では、これは非常に破壊的であることがわかっており、疑いを持たない仲間に深刻なリソースの負担を伝えています。反応して、RPKIベースのルート起源検証（ROV）がオフになっています。実際の剥離がありました。
As RPKI registration and ROA creation have steadily increased, this problem has increased, not just proportionally, but on the order of the in-degree of ROV implementing BGP speakers. As Autonomous System Provider Authorization (ASPA) [AS_PATH-VER] becomes used, the problem will increase.
RPKIの登録とROAの作成が着実に増加するにつれて、この問題は比例的にだけでなく、BGPスピーカーを実装するROVの順序で増加しました。自律システムプロバイダー認証（ASPA）[AS_Path-ver]が使用されると、問題が増加します。
Other mechanisms, such as automated policy provisioning, which have flux rates similar to ROV (i.e., on the order of minutes), could very well cause similar problems.
ROVと同様のフラックス率を持つ自動化されたポリシープロビジョニングなどの他のメカニズム（つまり、数分の順序で）は、同様の問題を非常によく引き起こす可能性があります。
Therefore, this document updates [RFC8481] by describing how to avoid this problem.
したがって、このドキュメントは、この問題を回避する方法を説明することにより、[RFC8481]を更新します。
If new RPKI data arrive that cause operator policy to invalidate the best route and the BGP speaker did not keep the dropped routes, then the BGP speaker would issue a route refresh, which this feature aims to prevent.
オペレーターポリシーに最適なルートを無効にし、BGPスピーカーがドロップされたルートを維持しなかった新しいRPKIデータが到着した場合、BGPスピーカーはルートリフレッシュを発行します。
A route that is dropped by operator policy due to ROV is, by nature, considered ineligible to compete for the best route and MUST be kept in the Adj-RIB-In for potential future evaluation.
ROVによるオペレーターポリシーによってドロップされるルートは、本質的に、最良のルートを競う資格がないと考えられており、潜在的な将来の評価のためにadj-rib-inに保持する必要があります。
Ameliorating the route refresh problem by keeping a full Adj-RIB-In can be a problem for resource-constrained BGP speakers. In reality, only some data need be retained. If an implementation chooses not to retain the full Adj-RIB-In, it MUST retain at least routes dropped due to ROV for potential future evaluation.
完全なadj-rib-inを維持することでルートリフレッシュの問題を改善することは、リソースに制約のあるBGPスピーカーにとって問題になる可能性があります。実際には、一部のデータのみを保持する必要があります。実装が完全なadj-rib-inを保持しないことを選択した場合、将来の潜在的な評価のためにROVのために少なくともルートを落とす必要があります。
As storing these routes could cause problems in resource-constrained devices, there MUST be a global operation, CLI, YANG, or other mechanism that allows the operator to enable this feature and store the dropped routes. Such an operator control MUST NOT be per peer, as this could cause inconsistent behavior.
これらのルートを保存すると、リソース制約のデバイスに問題が発生する可能性があるため、グローバルな操作、CLI、YANG、またはオペレーターがこの機能を有効にし、ドロップされたルートを保存できる他のメカニズムが必要です。このようなオペレーターの制御は、一貫性のない動作を引き起こす可能性があるため、ピアごとであってはなりません。
As a side note, policy that may drop routes due to RPKI-based checks such as ROV (and ASPA, BGPsec [RFC8205], etc., in the future) MUST be run and the dropped routes saved per this section, before non-RPKI policies are run, as the latter may change path attributes.
サイドノートとして、ROV（およびASPA、BGPSEC [RFC8205]など）などのRPKIベースのチェックが原因でルートをドロップする可能性のあるポリシーは、将来的には実行され、このセクションごとにドロップされたルートを保存する必要があります。後者がパス属性を変更する可能性があるため、RPKIポリシーが実行されます。
Operators deploying ROV and/or other RPKI-based policies should ensure that the BGP speaker implementation is not causing route refresh requests to neighbors.
ROVおよび/またはその他のRPKIベースのポリシーを展開するオペレーターは、BGPスピーカーの実装が近隣にルート更新要求を引き起こさないようにする必要があります。
BGP speakers MUST either keep the full Adj-RIB-In or implement the specification in Section 4. Conformance to this behavior is an additional, mandatory capability for BGP speakers performing ROV.
BGPスピーカーは、完全なadj-rib-inを維持するか、セクション4に仕様を実装する必要があります。この動作への適合は、ROVを実行するBGPスピーカーにとって追加の必須機能です。
If the BGP speaker does not implement these recommendations, the operator should enable the vendor's control to keep the full Adj-RIB-In, sometimes referred to as "soft reconfiguration inbound". The operator should then measure to ensure that there are no unnecessary route refresh requests sent to neighbors.
BGPスピーカーがこれらの推奨事項を実装していない場合、オペレーターはベンダーの制御が「ソフト再構成インバウンド」と呼ばれることもある完全なadj-rib-inを維持できるようにする必要があります。その後、オペレーターは、隣人に送信される不要なルート更新リクエストがないことを確認するために測定する必要があります。
If the BGP speaker's equipment has insufficient resources to support either of the two proposed options (keeping a full AdjRibIn or at least the dropped routes), the equipment SHOULD either be replaced with capable equipment or SHOULD NOT be used for ROV.
BGPスピーカーの機器に、提案された2つのオプションのいずれかをサポートするためのリソースが不十分な場合（完全なアジリビンまたは少なくとも落とされたルートを保持）、機器は有能な機器に置き換えるか、ROVに使用しないでください。
The configuration setting in Section 4 should only be used in very well-known and controlled circumstances where the scaling issues are well understood and anticipated.
セクション4の構成設定は、スケーリングの問題がよく理解され、予想される非常によく知られた制御された状況でのみ使用する必要があります。
Operators using the specification in Section 4 should be aware that a misconfigured neighbor might erroneously send a massive number of paths, thus consuming a lot of memory. Hence, pre-policy filtering such as described in [MAXPREFIX-INBOUND] could be used to reduce this exposure.
セクション4の仕様を使用するオペレーターは、誤った隣人が誤って膨大な数のパスを送信し、多くのメモリを消費する可能性があることを認識する必要があります。したがって、[maxprefix-inbound]に記載されているようなポリ統合前のフィルタリングを使用して、この暴露を減らすことができます。
If route refresh has been issued toward more than one peer, the order of receipt of the refresh data can cause churn in both best route selection and outbound signaling.
ルートリフレッシュが複数のピアに向かって発行されている場合、更新データの受領の順序により、最適なルート選択とアウトバウンドシグナリングの両方で解約される可能性があります。
Internet Exchange Points (IXPs) that provide route servers [RFC7947] should be aware that some members could be causing an undue route refresh load on the route servers and take appropriate administrative and/or technical measures. IXPs using BGP speakers as route servers should ensure that they are not generating excessive route refresh requests.
ルートサーバー[RFC7947]を提供するインターネット交換ポイント（IXPS）は、一部のメンバーがルートサーバーで過度のルートリフレッシュロードを引き起こし、適切な管理および/または技術的な測定を行う可能性があることに注意する必要があります。BGPスピーカーをルートサーバーとして使用するIXPは、過度のルートリフレッシュリクエストを生成していないことを確認する必要があります。
This document describes a denial of service that Route Origin Validation or other RPKI policy may place on a BGP neighbor and describes how it may be ameliorated.
このドキュメントでは、ルートオリジンの検証または他のRPKIポリシーがBGPの隣人に配置される可能性があるサービスの拒否について説明し、それがどのように改善されるかについて説明します。
Otherwise, this document adds no additional security considerations to those already described by the referenced documents.
それ以外の場合、このドキュメントは、参照されたドキュメントですでに説明されているものに追加のセキュリティ上の考慮事項を追加しません。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, DOI 10.17487/RFC2918, September 2000, <https://www.rfc-editor.org/info/rfc2918>.
[RFC2918] Chen、E。、「BGP-4のルートリフレッシュ機能」、RFC 2918、DOI 10.17487/RFC2918、2000年9月、<https://www.rfc-editor.org/info/rfc2918>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y.、ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487/RFC4271、2006年1月、<https://www.rfc-editor.org/info/rfc4271>。
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/info/rfc6811>.
[RFC6811] Mohapatra、P.、Scudder、J.、Ward、D.、Bush、R.、およびR. Austein、「BGPプレフィックスオリジン検証」、RFC 6811、DOI 10.17487/RFC6811、2013年1月、<https：//www.rfc-editor.org/info/rfc6811>。
[RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced Route Refresh Capability for BGP-4", RFC 7313, DOI 10.17487/RFC7313, July 2014, <https://www.rfc-editor.org/info/rfc7313>.
[RFC7313] Patel、K.、Chen、E。、およびB. Venkatachalapathy、「BGP-4の強化されたルートリフレッシュ機能」、RFC 7313、DOI 10.17487/RFC7313、2014年7月、<https：//www.rfc-editor.org/info/rfc7313>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8481] Bush, R., "Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)", RFC 8481, DOI 10.17487/RFC8481, September 2018, <https://www.rfc-editor.org/info/rfc8481>.
[RFC8481] Bush、R。、「リソース公開キーインフラストラクチャ（RPKI）に基づくBGP起源の検証の明確化」、RFC 8481、DOI 10.17487/RFC8481、2018年9月、<https：//www.rfc-editor.org/info/RFC8481>。
[AS_PATH-VER] Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders, J., and K. Sriram, "BGP AS_PATH Verification Based on Resource Public Key Infrastructure (RPKI) Autonomous System Provider Authorization (ASPA) Objects", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-verification-11, 24 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-11>.
[AS_PATH-ver] Azimov、A.、Bogomazov、E.、Bush、R.、Patel、K.、Snijders、J。、およびK. Sriram、 "BGP AS_Path reassion public Key Infrastructure（RPKI）自律システムに基づくAS_Path検証プロバイダー認証（ASPA）オブジェクト」、進行中の作業、インターネットドラフト、ドラフト-ITSIDROPS-ASPA-Verification-11、2022年10月24日、<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-11>。
[MAXPREFIX-INBOUND] Aelmans, M., Stucchi, M., and J. Snijders, "BGP Maximum Prefix Limits Inbound", Work in Progress, Internet-Draft, draft-sas-idr-maxprefix-inbound-04, 19 January 2022, <https://datatracker.ietf.org/doc/html/draft-sas-idr-maxprefix-inbound-04>.
[Maxprefix-Inbound] Aelmans、M.、Stucchi、M.、およびJ. Snijders、「BGP最大接頭辞制限インバウンド」、進行中の作業、インターネットドラフト、ドラフトSAS-IDR-Maxprefix-Inbound-04、1月19日2022、<https://datatracker.ietf.org/doc/html/draft-sas-idr-maxprefix-inbound-04>。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、DOI 10.17487/RFC6480、2012年2月、<https://www.rfc-editor.org/info/rfc6480>。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.
[RFC6482] Lepinski、M.、Kent、S。、およびD. Kong、「ルートオリジナル認可（ROA）のプロファイル」、RFC 6482、DOI 10.17487/RFC6482、2012年2月、<https：//www.rfc-editor.org/info/rfc6482>。
[RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange BGP Route Server", RFC 7947, DOI 10.17487/RFC7947, September 2016, <https://www.rfc-editor.org/info/rfc7947>.
[RFC7947] Jasinska、E.、Hilliard、N.、Raszuk、R。、およびN. Bakker、「インターネット交換BGPルートサーバー」、RFC 7947、DOI 10.17487/RFC7947、2016年9月、<https：//ww.rfc-editor.org/info/rfc7947>。
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.
[RFC8205] Lepinski、M.、ed。およびK. Sriram編、「BGPSECプロトコル仕様」、RFC 8205、DOI 10.17487/RFC8205、2017年9月、<https://www.rfc-editor.org/info/rfc8205>。
[RPKI-ROUTER-PROT-v2] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2", Work in Progress, Internet-Draft, draft-ietf-sidrops-8210bis-10, 16 June 2022, <https://datatracker.ietf.org/doc/html/ draft-ietf-sidrops-8210bis-10>.
[RPKI-Router-Prot-V2] Bush、R.およびR. Austein、「リソース公開キーインフラストラクチャ（RPKI）からルータープロトコル、バージョン2」、進行中の作業、インターネットドラフト、ドラフト-ITF-SIDROPS-8210BIS-10、2022年6月16日、<https://datatracker.ietf.org/doc/html/ draft-ietf-sidrops-8210bis-10>。
Acknowledgements
謝辞
The authors wish to thank Alvaro Retana, Ben Maddison, Derek Yeung, John Heasley, John Scudder, Matthias Waehlisch, Nick Hilliard, Saku Ytti, and Ties de Kock.
著者は、Alvaro Retana、Ben Maddison、Derek Yeung、John Heasley、John Scudder、Matthias Waehlisch、Nick Hilliard、Saku Ytti、Ties de Kockに感謝したいと考えています。
Authors' Addresses
著者のアドレス
Randy Bush IIJ Research Lab & Arrcus, Inc. 1856 SW Edgewood Dr Portland, OR 97210 United States of America Email: randy@psg.com
Randy Bush IIJ Research Lab＆Arrcus、Inc。1856 SW Edgewood Dr Portland、または97210アメリカ合衆国電子メール：randy@psg.com
Keyur Patel Arrcus, Inc. 2077 Gateway Place, Suite #400 San Jose, CA 95119 United States of America Email: keyur@arrcus.com
Keyur Patel Arrcus、Inc。2077 Gateway Place、Suite＃400 San Jose、CA 95119アメリカ合衆国電子メール：keyur@arrcus.com
Philip Smith PFS Internet Development Pty Ltd PO Box 1908 Milton QLD 4064 Australia Email: pfsinoz@gmail.com
Philip Smith PFS Internet Development Pty Ltd PO Box 1908 Milton QLD 4064 Australiaメール：pfsinoz@gmail.com
Mark Tinka SEACOM Building 7, Design Quarter District Leslie Avenue, Magaliessig Fourways, Gauteng 2196 South Africa Email: mark@tinka.africa
マークティンカシーコムビル7、デザインクォーター地区レスリーアベニュー、マガリシグフォーウェイ、ガウテン2196南アフリカメール：mark@tinka.africa