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. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
