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

From: "Martin Thomson" <[email-masked]>
Date: Wed, 20 Mar 2019 05:26:24 -0400

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?

The term of art is reflexive address (or reflected address).

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 20 Mar 2019 06:59:55 -0700

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 <[email-masked]> wrote:
> 

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 20 Mar 2019 17:54:02 +0200

On Wed, Mar 20, 2019 at 06:59:55AM -0700, Tommy Pauly wrote:
> 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.

Quickly reading the draft:

struct {
       opaque address<32..255>;
} NetworkAddress;

Address is at least 32 octets? Even IPv6 addresses are only 16 octets
(and IPv4 is 4 octets).

-Ilari

---

From: Chris Wood <[email-masked]>
Date: Wed, 20 Mar 2019 08:56:11 -0700

> On Mar 20, 2019, at 8:54 AM, Ilari Liusvaara <[email-masked]> wrote:
> 

This is a silly bug. Oops!

Best,
Chris

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Mar 2019 17:10:46 +0000

I had a quick scan of that.

I wondered what'd the server send if MPTCP was being used?

(But I forget how TLS/MPTCP works, so maybe it's a dumb
question;-)

S.

---

From: Jim Schaad <[email-masked]>
Date: Wed, 20 Mar 2019 19:56:49 +0100

I have not looked at this draft yet, but what about DTLS/UDP?

Jim

> -----Original Message-----
> From: TLS <[email-masked]> On Behalf Of Tommy Pauly
> Sent: Wednesday, March 20, 2019 3:00 PM
> To: Martin Thomson <[email-masked]>
> Cc: [email-masked]
> 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
> 
> > 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?

---

From: Dan Wing <[email-masked]>
Date: Thu, 21 Mar 2019 13:11:49 +0530

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 <[email-masked]> wrote:
>