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

[Brian E Carpenter <[e-mail]>]

On 11-Feb-20 09:46, Mark Smith wrote:
> 
> 
> On Tue, 11 Feb 2020, 03:13 Fernando Gont, <[e-mail] <mailto:[e-mail]>> 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.

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