Hi Anthony,
Thanks for taking time to comment. Hmm, some things may be too obvious
to me. I'll try in-line. Also, please read my somewhat lengthy response
to Jen (but I was asked to 'elaborate' so that's my excuse)
On 3/28/23 06:49, Anthony Somerset wrote:
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.
Not sure what you mean by 'human elements preceding it'. Obviously
making hosts reachable is an action traceable to a human being. We're
talking about negotiation of the sort whatever tunnels you have in mind
have to do to resolve address overlap. VPNs on the other hand, place the
hosts in the control of the other network admin. Maybe you want that,
but if you have a service for a supplier, you don't necessarily force
your suppliers to lend their hosts to control by your admin.
I already explained a dubious assumption that technologies exist to
traverse NAT in the response to Jen.
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.
I wrote a follow up to a question about security asked during the
session which discusses encryption. IPREF is not going to make vanilla
IPv4 or IPv6 encrypted. It's not its mission. IPSEC, TLS, SSH are some
of the means of achieving that. I think people know neither IPv4 nor
IPv6 alone encrypt the traffic. It has nothing to do with private or non
private networks. Incidentally, the thinking that local 'private'
networks don't need encryption is a common misconception. That's very
unfortunate. IPREF is not about education in security measures.
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
The selection is a local decision. There is no need to standardize
because it does not affect interoperability, hence nothing in the
draft. However, to your point, there may be a need for a Best Practice
document. I'm OK with that. It's a bit early for it, but yes. To
explain a little, they are 'arbitrary' in the sense that it is the local
matter how this is done. Local admin can do it manually but in practice
it would be allocated automatically by some algorithm, perhaps randomly.
The point is, all these decision belong to the local admin. There is no
need to negotiate with peers hence no need to define a protocol for it.
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
There is no split horizon. Normally, organization designate a special
domain for local name resolution, for example 'mycompany.internal'.
These authoritative servers are visible only locally. There is also a
public, externally visible authoritative server that list address of the
same hosts for external access. Those addresses are obviously
different. With IPREF, it works exactly the same way. External public
authoritative server publish IPREF addresses, local 'mycompany.internal'
authoritative server publish local IP addresses. There is no need for
split horizon. There is no more mapping than with standard
external/internal domains. In that case, you have to map a DNS name to
a host for external use and again for internal use. Even with split
horizon (not needed) you still have to do it twice.
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
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
