On Thu, Feb 27, 2020 at 11:36 PM Joseph Touch <[email protected]> wrote:
> > > On Feb 27, 2020, at 4:21 PM, Phillip Hallam-Baker <[email protected]> > wrote: > > IP end to end does not mean the IP address is constant end to end. It >> never has meant that and never will. >> >> >> Actually, that's the only thing it ever meant and always will. When >> addresses change, *by definition*, the*ends* change (and yes, that's what >> NATs do - they create end-to-end CONTENT transfer over separate end-to-end >> Internets). >> > > By whose definition? Not by mine. > > > I’d start with RFCs 791 and 1122, but there’s also the pseudo header in > RFC 793, to be very specific. > > TCP and TLS give me a reliable end-to-end stream. The fact that the IP > address is exposed is merely an unfortunate defect in the legacy APIs. > > As the application layer designer, I am the customer here. I do not care > about the IP address. > > > Hmmm. By what value do you call TCP endpoint? > > You must have magic sockets that don’t actually refer to IP addresses. > I have a library that implements RFC6763. So my application code doesn't actually consider IP addresses. Since the platform doesn't provide real DNS resolution, I have to write my own of course. And I will be putting DNSSEC in there at some point probably. But it is a feature set that should be in the platform. At some point, I am going to have to look at implementing TURN/STUN/PCP etc. for NAT traversal. That certainly isn't application layer code. So as far as i am concerned, I am resolving a triple of SRV prefix, DNS name and account name to a socket. The only case in which my application code would deal in a raw IP address and port is if the resolution is delegated to an external presence service. If Alice is trying to make a person-person call to Bob, we may want to route the packets direct. So there has to be some sort of presence service in the cloud to set up the connection which is going to end up telling one of them to place a call for an IP address/port and the other of them to listen for the incoming. The test of this design is straightforward, all the proposals for DNS privacy etc. sit inside the library. I can drop out regular client DNS for DPRIV. Or I can use my omnibroker version which makes use of the RFC6763 interface. Abstracting away from TLS and UDP means I can adapt to new transports like QUIC very easily. For certain types of message, I have my own UDP based transport. Most cryptographic service transactions consist of a single request packet followed by one to a dozen response packets. That sits in the same box. It really isn't 'magic', it is just understanding that this is platform code not application code. We do not have 'layers' in the Internet architecture but we have modules that we call layers. And those layers have interfaces to the layers above and beneath them that are mediated by a naming infrastructure. And we should be really explicit about what those interfaces are because they have to be stable over long periods of time.
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
