Subject: [TLS] draft-kinnear-tls-client-net-address and 'public address'

From: Geoff Keating <[email-masked]>
Date: Thu, 21 Mar 2019 09:17:44 -0700

I see this draft describes the format of a network address as
   
   NetworkAddress.address carries the raw network-order byte-wise
   representation of the client IP address.
   ...
   Clients which receive a non-empty NetworkAddress extension may use
   it to record their public IP address.

This is an end-to-end operation, and so I see a few problems with it:

- There's no guarantee that the IP address seen by the server is a
  'public' address.  It's perfectly possible that the path looks like
  
  client - NAT - NAT - internet - NAT - NAT - server

  or it may not even be that simple.  There may not be any involvement
  of what we would call the 'internet' at all.  I think the intent of
  the draft is that the server should only implement this extension if
  it can see the client's address as visible on the Internet and if
  so, the draft should say this, along with MUST NOT prohibitions for
  returning local, link-local, site-local, private use, or similar
  addresses.

- There's no guarantee that the public IP address of the client is the
  same address family (IPv4/IPv6/whatever) as the private address,
  leading to ambiguity.  In fact there is no guarantee the client even
  implements that address family.  My suggestion is that
  NetworkAddress should be enhanced to include a value from the IANA
  'Address Family Numbers' table.

  Alternatively you might look at the SNMP TransportDomain and
  its related TransportAddress object from RFC 3419.