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

[Gyan Mishra <[e-mail]>]

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

> On Tue, 11 Feb 2020 at 15:32, Fernando Gont <[e-mail]> wrote:
> >
> > On 10/2/20 19:17, Brian E Carpenter wrote:
> > > 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.
> >
> > 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.
>
>    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.

https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations-04#section-4.3


   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.

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


-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]