Subject: rfc4941bis: temporary addresses as "outgoing-only"?

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Feb 2020 06:33:19 -0300

Folks,

Since we are at it, I wonder if rfc4941bis should say anything about the
use of temporary addresses for incoming connections. (see
https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations-04#section-4.3).
(e.g., "an implementation MAY....")

Particularly for connection-oriented protocols, hosts that prevent
incoming connections on temporary addresses reduce exposure even when
their temporary addresses become "exposed" by outgoing sessions.

i.e., if the model is that temporary addresses are employed for outgoing
connections, unless a host uses temporary-only, there's no reason to
receive incoming connections on temporary addresses. (e.g., browsing the
web or sending email should not be an invitation for folks to e.g.
port-scan you).

The caveats here are:

1) If a host does temporary-only, these are the only addrs you have, and
hence they should allow incomming connections

2) It could be easily done for connection-oriented protocols such as
TCP, but not so easily (if at all possible) for e.g. connectionless
protocols.

As noted in
https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations-04#section-4.3
, *in theory* there are other ways in which the same effect could be
achieved... so one could certainly argue that this policy should not be
enforced on the addresses, but rather we should have a more appropriate
API that could allow apps to e.g. bind() subsets of all the available
addresses.

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Feb 2020 07:46:46 +1100

On Tue, 11 Feb 2020, 03:13 Fernando Gont, <[email-masked]> wrote:

> ).

This would prevent peer-to-peer connections between end-user devices, as it
means devices become clients only, and they therefore cannot provide a
temporary server/service.

So, for example, ad hoc file transfer applications like AirDrop couldn't
work on a temporary address only and client-only end-user device.

https://en.m.wikipedia.org/wiki/AirDrop

Peer-to-peer application communications architectures have the node
effectively act as both a client and server at the same time, providing and
receiving service concurrently.

A temporary "server"/service is useful and valid, the privacy issue for
end-user devices comes about if the server/service had a permanent unique
address or IID.

Forcing end-user devices to be clients only is actually the fundamental
constraint that NAT has imposed on IPv4. Certain applications for which
peer-to-peer communications architectures would be better are forced to
adopt a client/server communication architecture just to be able to work in
the presence of NAT.

Regards,
Mark.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Feb 2020 11:17:25 +1300

On 11-Feb-20 09:46, Mark Smith wrote:
> 
> 
> On Tue, 11 Feb 2020, 03:13 Fernando Gont, <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Folks,
> 
> This would prevent peer-to-peer connections between end-user devices, as it means devices become clients only, and they therefore cannot provide a temporary server/service.

If a node has a stable address as well as a temporary address, that isn't the case. However, I think it is rather out of scope for 6man to regulate this point. What might be good, but is also probably out of scope,
is a socket option to allow/disallow incoming connections to temp addresses, and a socket error code if they are disallowed and an upper layer tries to bind a socket to a temp address.

    Brian

> 
> So, for example, ad hoc file transfer applications like AirDrop couldn't work on a temporary address only and client-only end-user device.
> 
> Peer-to-peer application communications architectures have the node effectively act as both a client and server at the same time, providing and receiving service concurrently.
> 
> A temporary "server"/service is useful and valid, the privacy issue for end-user devices comes about if the server/service had a permanent unique address or IID.
> 
> Forcing end-user devices to be clients only is actually the fundamental constraint that NAT has imposed on IPv4. Certain applications for which peer-to-peer communications architectures would be better are forced to adopt a client/server communication architecture just to be able to work in the presence of NAT.
> 
> Regards,
> Mark.
> 
> 
> 
> 
> 
>     The caveats here are:
> 
>     e-mail: [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 10 Feb 2020 19:17:52 -0500

> API that could allow apps to e.g. bind() subsets of all the available

  I agree it below makes sense excerpt from the bottom of that section.  So
with temporary address enabled are you stating that the “stable” address is
what we want to use but based on OS implementations they may not always be
the case due to lack of API support.  Is the issue with default source
address selection used which may differ from OS to OS and in that case is
it possible the temporary address could be bound to services thus exposing
the host to attacks.  Kind of defeats the purpose of having a temporary
address.

It really sounds like we desperately need API development.

Binding services only to stable addresses provides a clean separation
   between addresses employed for client-like outgoing connections and
   server-like incoming connections.  However, we currently lack an
   appropriate API for nodes to be able to specify that a socket should
   only be bound to stable addresses.

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 10 Feb 2020 19:25:28 -0500

On Mon, Feb 10, 2020 at 7:17 PM Gyan Mishra <[email-masked]> wrote:

>   I agree it below makes sense excerpt from the bottom of that section.
> So with temporary address enabled are you stating that the “stable” address
> is what we want to use but based on OS implementations they may not always
> be the case due to lack of API support.  Is the issue with default source
>> I think that most client mobile devises in an enterprise use “client
>> like” and SOHO
>
>         user at home typically is peer2peer “server like”,  so the home
users connected to broadband internet would have privacy exposure issues
with “server like” setup.

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Feb 2020 13:10:18 +1100

On Tue, 11 Feb 2020, 09:17 Brian E Carpenter, <[email-masked]>
wrote:

> > This would prevent peer-to-peer connections between end-user devices, as
> it means devices become clients only, and they therefore cannot provide a
> If a node has a stable address as well as a temporary address, that isn't
> the case.

True, however one of the goals of this update is to allow temporary address
only nodes, removing the assumption that hosts with temporary addresses
will also always have a stable address.

However, I think it is rather out of scope for 6man to regulate this point.

Yes, I agree it is out of scope for 6man.

Although it is common to imagine devices as "clients" or "servers", those
definitions are really only application layer roles and definitions. A
device might be a client for one running application and a server for
another.

It may also be a peer for another running application, because it both uses
and provides services to other instances of the application residing on
other hosts.

At the transport and network layers below, end points are peers.

Regards,
Mark.

What might be good, but is also probably out of scope,
> is a socket option to allow/disallow incoming connections to temp
> addresses, and a socket error code if they are disallowed and an upper
> layer tries to bind a socket to a temp address.
>
>     Brian
>
> >

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Feb 2020 00:44:14 -0300

On 10/2/20 19:17, Brian E Carpenter wrote:
> If a node has a stable address as well as a temporary address, that isn't the case. 

That's what I had in mind.

> However, I think it is rather out of scope for 6man to regulate this point. What might be good, but is also probably out of scope,

The thing here is that, unless the address has been generated upon 
request of an app (something not possible at the time of this writing), 
apps share addresses and thus no app has authority over any address...

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Feb 2020 01:33:31 -0300

On 10/2/20 21:17, Gyan Mishra wrote:
> 
> 
> On Mon, Feb 10, 2020 at 11:12 AM Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Folks,
> 
>    I agree it below makes sense excerpt from the bottom of that 
> section.  So with temporary address enabled are you stating that the 
> “stable” address is what we want to use but based on OS implementations 
> they may not always be the case due to lack of API support.  Is the 
> issue with default source address selection used which may differ from 
> OS to OS and in that case is it possible the temporary address could be 
> bound to services thus exposing the host to attacks.  Kind of defeats 
> the purpose of having a temporary address.
> 

Indeed. We did all the machinery but the tool apps can use to leverage 
IPv6 addressing: an API.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Feb 2020 02:14:18 -0300

On 10/2/20 23:10, Mark Smith wrote:
> 
> 
> On Tue, 11 Feb 2020, 09:17 Brian E Carpenter, 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>      > On Tue, 11 Feb 2020, 03:13 Fernando Gont, <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >     Folks,
>      >
>      > This would prevent peer-to-peer connections between end-user
>     devices, as it means devices become clients only, and they therefore
>     cannot provide a temporary server/service.
> 
> True, however one of the goals of this update is to allow temporary 
> address only nodes, removing the assumption that hosts with temporary 
> addresses will also always have a stable address.

In that case,  one would expect that in temp-only scenarios, this policy 
would not be enforced.

That said, I guess that based on your other comments, it would best, if 
anything, to leave this for future work.

In that sense, would it make sense for this to be called out in the 
"Future work" section?

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Feb 2020 16:18:53 +1100

> That's what I had in mind.

So if we want to support adhoc peer-to-peer file transfers between
e.g. smartphones via NFC/Bluetooth/Adhoc Wifi, then stable addresses
are required, even if the file transfer takes say 30 seconds, well
within the valid lifetime of the RFC4291bis temporary addresses?

I think it is a very dangerous path to codify client only IPv6 hosts
(as distinct from temporary address only IPv6 hosts). I think it is
counter to the fundamental goals of the ARPANET and the Internet:

RFC871, "A PERSPECTIVE ON THE ARPANET REFERENCE MODEL", September 1982

'Historical/Philosophical Context

...
     By "intercomputer networking"  we mean the attachment of
     multiple, usually general-purpose computer systems--in the sense
     of Operating Systems of potentially different manufacture (i.e.,
     "Heterogeneous Operating Systems")--to some communications
     network, or communications networks somehow interconnected, for
     the purpose of achieving resource sharing amongst the
     participating operating systems, usually called Hosts.  (By
     "resource sharing" we mean the  potential ability for programs on
     each of the Hosts to interoperate with programs on the other
     Hosts and for data housed on each of the Hosts to be made
     available to the other Hosts in a more general and flexible
     fashion than merely enabling users on each of the Hosts to be
     able to login to the other Hosts as if they were local; that is,
     we expect to do more than mere "remote access" to intercomputer
     networked Hosts.)'

Client only IPv6 hosts would not be able to be more than '"remote
access" to intercomputer networked Hosts.', despite having CPU, memory
and network bandwidth resources 10s and 100s of 1000s of times greater
than the hosts had in the 1970s and 1980s.

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Feb 2020 02:27:15 -0300

On 10/2/20 17:46, Mark Smith wrote:
> it means devices become clients only, and they therefore cannot provide 
> a temporary server/service.
> 

Maybe one would expect that if you're doing temp-only, you wouldn't 
enforce this policy?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Feb 2020 02:38:32 -0300

> within the valid lifetime of the RFC4291bis temporary addresses?

I see your point. And if one were to implement this policy, yes, stable 
addresses would be required.

That said, it is clear to me that this is out of scope for this document 
(I just wanted to check with the group). Once again, if we had 
appropriate APIs, applying this sort of policy host-wide wouldn't even 
make sense.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Feb 2020 16:55:45 +1100

On Tue, 11 Feb 2020 at 16:38, Fernando Gont <[email-masked]> wrote:
> (I just wanted to check with the group).

Yes, I agree out of scope.

I think we want to restrict this document to temporary addresses and
what we expect to work when only temporary addresses are used or
available. That's naturally bounded by the properties of the temporary
addresses, which is why for example, connections that are longer lived
than the valid lifetime of the temporary address are going to break
and are expected to break.

Regards,
Mark.

> Once again, if we had

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 11 Feb 2020 01:10:10 -0500

On Tue, Feb 11, 2020 at 12:19 AM Mark Smith <[email-masked]> wrote:

> > >> This would prevent peer-to-peer connections between end-user devices,
> as it means devices become clients only, and they therefore cannot provide
> ....
>    Gyan> I agree.  We definitely don't want to go backwards with IPv6 -
being forward looking from a technology standpoint and not being able to do
basic pee-to-peer networking is a giant step backwards.   The issue that
you called out at the bottom of section 4.3 regarding binding to stable
address I think is something that needs to be fixed if that is an issue
with multiple addresses.  I don't think its a reason to remove the stable
address.

I don't think that is a reason to abandon the "stable" address usage for
incoming connections.  With IPv4 you have a single address and its easy to
bind() services to the connection.  With IPv6 with the temporary address
disabled and when a single GUA exist on the NIC then its as well easy to
bind() services to the IP.  However, when there are multiple addresses
employed with the privacy extension temporary address, source address
selection comes into play when binding a service to an IP.  That is the
crux of the issue with source address selection appropriately picking the
correct address for incoming connections.   Using the temporary address for
incoming connections "server-like" registered in DNS -doing so circumvents
the shielding the identity of the client when it initiates communication.
 I am guessing that if you had a single temporary (preferred) address w/o a
stable address - the service would bind to the address and source address
selection would not come into play.

I think that part of RFC 4941 using the stable address for "incoming" and
temporary address for "outgoing" should remain unchanged in the 4941bis
update.

https://tools.ietf.org/rfc/rfc4941#section-2.4

   Many machines function as both clients and servers.  In such cases,
   the machine would need a DNS name for its use as a server.  Whether
   the address stays fixed or changes has little privacy implication
   since the DNS name remains constant and serves as a constant
   identifier.  When acting as a client (e.g., initiating
   communication), however, such a machine may want to vary the
   addresses it uses.  In such environments, one may need multiple
   addresses: a "public" (i.e., non-secret) server address, registered
   in the DNS, that is used to accept incoming connection requests from
   other machines, and a "temporary" address used to shield the identity
   of the client when it initiates communication.  These two cases are
   roughly analogous to telephone numbers and caller ID, where a user
   may list their telephone number in the public phone book, but disable
   the display of its number via caller ID when initiating calls.

  As far as operational impact & MTTR for enterprises by having (1)
preferred & and maximum (1) deprecated address with valid = 2 days
eliminating the stable address does reduce the total GUA addresses on the
endpoint to 2 addresses.  However I think removal of the stable address and
resulting impact to essential peer-2-peer communications "client-like" &
"server-like" in SOHO environments.  Also having the stable address does
give enterprises the option to disable the temporary address if desired for
"long lived" connections.

!  4941bis update - I would prefer to keep the stable address

Allows hosts to employ only temporary addresses (i.e.configuration of
stable addresses is no longer implied or required).

Allows hosts to employ only temporary addresses (i.e. configuration of
stable addresses is no longer implied or required)

>
> Regards,
> Mark.
>
>
>
>
>
>
>
> >
> > > However, I think it is rather out of scope for 6man to regulate this
> point. What might be good, but is also probably out of scope,

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Feb 2020 10:07:47 +1300

> apps share addresses and thus no app has authority over any address...

Technically, yes, but if the socket option required root privilege it could OK. Anyway it's part of a broader problem, not part of 4941bis, IMHO.

    Brian

---

From: David Farmer <[email-masked]>
Date: Tue, 11 Feb 2020 17:48:18 -0600

> appropriate APIs, applying this sort of policy host-wide wouldn't even

I think a specific requirement to use temporary addresses for outbound only
is out of scope for this document, if only because it permits the use
only temporary addresses by a node, and doesn't require permanent or stable
addresses. Nevertheless, it is an important point, that how temporary
addresses are used by applications impacts their traceability significantly.

Therefore, I think a recommendation like, temporary addresses are generally
most effective when applications prefer temporary addresses for outbound
connections and use other addresses for inbound connections when feasible,
especially for long-term well-known services, is in scope.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================