Re: [TLS] draft-kinnear-tls-client-net-address comments

Good point.  Furthering that point:

- what about DTLS/SRTP when that is used with ICE (RFC8445 and its precursor RFC5245) and QUIC (c.f., https://w3c.github.io/webrtc-quic/).  Need guidance in the document to use ICE and/or quic-address-extension, as well as what it means if they differ (heaven forbid they differ, but ...).  
- Some motivational text and advice-to-implementor text explaining how ICE-over-QUIC-over-UDP is unsuitable compared to draft-pauly-quic-address-extension (lack of specification, desire to use same technique for both TLS-over-TCP and QUIC-over-UDP (perhaps), ICE too heavy (and can't be profiled?), or whatever the reasons are.  Such guidance will help developers who might happen to notice several IETF protocols that could be made to achieve the same ends.  
- Also need guidance that the information is time-limited, source network specific (different answers on Ethernet vs WiFi vs LTE) and destination specific (different answer is possible depending on the server queried, due to a NAT or Carrier Grade NAT using multiple outbound interfaces ("pooling") and whatever the NAT's algorithm to choose whichever outbound interface (based on client VLAN, performance of each outbound interface, etc., who knows).  NAT pooling can be a significantly complicated issue (https://tools.ietf.org/html/rfc4787#page-7.
- Does anyone see a need for a well-known underscore name to retrieve this information from a web server?  As written both drafts work with TLS and with QUIC, which means they don't require an HTTP server on the far side so works with SMTP, IMAP, etc.  However, I could see it being difficult for an application to learn its public IP address (needs to get its TLS or QUIC implementation to support these I-Ds).  Supporting this over HTTP has the advantage that both the OS and an application can programmatically learn its public IP address.  
- As already mentioned, MPTCP complicates the answer from the server, as will multipath QUIC (which publicly appears to be stalled, but we should reasonably expect it might come to life again).  Guidance text needs to be added, or perhaps we can safely punt the problem with 'for further study' and recommend against using it with MPTCP?
- Finally, the datastructure doe not convey protocol; I worked on a TCP-to-SCTP gateway a few years ago and one might envision a TCP-to-QUIC gateway or QUIC-to-QUIC8 gateway in 2030.  Should we anticipate that and include protocol number to fully qualify the port number that exists already in the datastructure?  I honestly don't know the answer to that, but throwing it out for consideration.

-d

> On Mar 21, 2019, at 12:26 AM, Jim Schaad <ietf@augustcellars.com> wrote:
> 
> I have not looked at this draft yet, but what about DTLS/UDP?
> 
> Jim
> 
> 
>> -----Original Message-----
>> From: TLS <tls-bounces@ietf.org> On Behalf Of Tommy Pauly
>> Sent: Wednesday, March 20, 2019 3:00 PM
>> To: Martin Thomson <mt@lowentropy.net>
>> Cc: tls@ietf.org
>> Subject: Re: [TLS] draft-kinnear-tls-client-net-address comments
>> 
>> The QUIC and TLS drafts were written together, and are quite similar as
> you
>> note. The intention is to use the TLS extension over TLS/TCP connections,
>> and the QUIC extension for QUIC/UDP.
>> 
>> I agree that QUIC as a protocol benefits more from the extension than TLS
>> does, but applications on top of both can benefit by detecting NATs, for
>> making decisions about long-lived connections and privacy mitigations.
>> 
>> Thanks,
>> Tommy
>> 
>>> On Mar 20, 2019, at 2:26 AM, Martin Thomson <mt@lowentropy.net>
>> wrote:
>>> 
>>> I see a substantially similar draft in
> draft-pauly-quic-address-extension.  I'd
>> like to understand how these might be complementary, or whether the idea
>> is to pursue only one.  The QUIC extension seems superior, if you have
> QUIC.
>> There are a lot more plausible reasons to want this information in QUIC
>> though.
>>> 
>>> Nits:
>>> 
>>> The format of the extension is not ideal.  Wouldn't you want to know
> which
>> family it came from?
>> 
>> I think the intention was to use the length to infer the family.
>>> 
>>> The term of art is reflexive address (or reflected address).
>> 
>> Thanks, good to know!
>>> 
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls