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

[Gyan Mishra <[e-mail]>]

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

>
>
> On Mon, Feb 10, 2020 at 11:12 AM Fernando Gont <[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).
>>
>> 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?
>
>
>
>   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.
>
>
>> 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.

>

>> Thanks!
>>
>> Cheers,
>> --
>> 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]
>
>
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]