Hi Waldemar I concur with Jen’s comments
I’m struggling to find an actual problem statement that makes this proposed draft a useful and unique fit. For me, 2 “private” networks are private for a reason, if there is a need to connect them together in some way. I either control both networks or I have some open line of communication with the other network manager and will be negotiating at a human level the interconnection. Yes this includes a mutually agreed level of trust I certainly don’t believe there’s a use case for random network to network interconnection without the human elements preceding it. Given the above statements, there are far better ways to be able to route between 2 private networks compared to the proposed solution especially as your draft is silent to actual security implications, in fact as far as I can tell, there is zero encryption of traffic being routed over ipref – this could easily falsely lead network users to assume that the IP traffic between the networks is secure, because hey its private to private networking right… any commonly available site to site vpn tunnel would be far simpler to implement in a secure manner and won’t require any kinds of translations at the DNS layer or weird translations at the IP layer to start with. Having read the draft a bit more – its 100% not clear how the encoding subnets are chosen or the ipref values – if I read correctly it looks like they are entirely selected arbitrarily – there is no schema or standard to follow with synthesizing these values? – therefore the would become an implicit human “negotiation” aspect to this as you make sure you select non-overlapping encoding subnets and exchange (via DNS) the iprefs – you cannot say that there is no negotiation at all, also the human choice aspect will lead to humans being humans and picking things that logically make sense and therefore it provides an extra vector for a malicious actor to potentially enumerate network devices To me the biggest overhead becomes – how does one map DNS for hostnames to the “mapped” IP which gets converted to an IPREF encoding – it sounds like one would need to just like they are maintaining those mappings for IPREF on the gateways, they have to map some split horizon DNS which is already not a recommended approach from a maintenance and scalability perspective. Yet more things to manually map and maintain Overall I am struggling to see how this draft would be useful. Thanks Anthony Waldemar, Would you be able to elaborate on the problem statement and the benefits of the proposed solution? After reading the draft and listening to the presentation I'm not sure I fully understand the problem. It looks like your goal is to achieve a kind of end2end. However: 1) We do not need anything for IPv6-to-IPv6 end2end. 2) For IPv6-to-IPv4 we have NAT64, and for IPv4-to-IPv6 we have SIIT. 3) For IPv4-to-IPv4 we have some forms of NAT-T and STUN. If your goal is to replace #2 and #3 with a one protocol to rule them all, I'm not sure we shall put too much effort (time and money) into developing new solutions for the legacy protocol version. Especially as we expect IPv4 to decline over time. Am I missing some key benefits of the proposed solution which would make IPREF attractive enough to deploy instead of existing solutions? -- SY, Jen Linkova aka Furry This email disclaimer applies to the original email, all attachments and any subsequent emails sent by Liquid Telecom. This email contains valuable business information that is privileged, confidential and/or otherwise protected from disclosure, intended only for the named person or entity to which it is addressed. If you are not the intended recipient of this email and you received this e-mail in error, any review, use, dissemination, distribution, printing or copying of this e-mail is strictly prohibited and may be unlawful and/or an infringement of copyright. Please notify us immediately of the error and permanently delete the email from your system, retaining no copies in any media. No employee or agent is authorized to conclude any binding agreement on behalf of Liquid Telecom with another party or give any warranty by email without the express written confirmation by an authorized representative or a director of Liquid Telecom. Nothing in this email shall be construed as a legally binding agreement or warranty or an offer to contract. Liquid Telecom will not be responsible for any damages suffered by the recipient as a result of the recipient not taking cognizance of this principle. Liquid Telecom accepts no liability of whatever nature for any loss, liability, damage or expense resulting directly or indirectly from the access of any files which are attached to this message. Any email addressed to Liquid Telecom shall only be deemed to have been received once receipt is confirmed by Liquid Telecom orally or in writing. An automated acknowledgment of receipt will not suffice as proof of receipt by the Liquid Telecom. This email disclaimer shall be governed by the laws of South Africa. Internal All Employees
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
