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

On Tue, 11 Feb 2020, 03:13 Fernando Gont, <fgont@si6networks.com> wrote:

> 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).
>

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.

> 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: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>