Subject: addrsel: privacy addresses within/out of a site

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Jan 2011 11:51:38 +0200 (EET)

Hi,

Operational input: when discussing the use of RFC4941 (privacy) addresses with 
our LAN/workstation admins, it seemed as if there would be great benefit from 
being able to specify an RFC3484 rule which would in essence say:

"do not use privacy addresses when communicating inside the site [a set of 
designated destination prefixes], use it by default otherwise"

I don't think this is possible today because rfc3484 policy table only allows 
matching by prefixes, not by address type.

Has this come up in discussions / has anyone else thought about this?

Btw: in draft-ietf-6man-rfc3484-revise-01, "fec::/16" should be "fec0::/10". 
fec:: would mean 0fec:: and the prefix length is also wrong.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Mark Smith <[email-masked]>
Date: Mon, 3 Jan 2011 20:40:31 +1030

Hi Pekka,

On Mon, 3 Jan 2011 11:51:38 +0200 (EET)

> designated destination prefixes], use it by default otherwise"

I'd be curious what the benefits are.

The only reason I could think of as to why to do this is to be able to
associate internal application access logs with internal hosts. At face
value that sounds useful, however if you really care about auditing
application access and use, it isn't the hosts you need to worry about,
but the people behind them - and they can usually easily change hosts.
So I think those applications should be using proper AAA to identify the
user, rather than using IPv6 host identifiers as very poor substitutes
for user identities. 

> Has this come up in discussions / has anyone else thought about this?

Regards,
Mark.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Jan 2011 12:21:41 +0200 (EET)

> user, rather than using IPv6 host identifiers as very poor substitutes

One use case is administrators running ssh, vnc or some such remote 
management to the client OS.  The conclusion from looking at various 
similar cases was that systems need to have a well-known (non-privacy) 
IP where they can be reached and run TCP services at, or the privacy 
IP needs to be stored in DNS (not much point in that..).

Also, many site-internal access control mechanisms (for example, 
hosts.allow for ssh, some others for e.g. web browsing) use 
host-specific IPs in addition to other checks.  In some cases these 
could be substituted with stronger upper-layer identities e.g with 
certificates.

On the other hand, user identification due to static EU64 is a little 
bit of concern e.g. with web surfing, but this also applies to other 
applications so the issue does not go away with application-specific 
tuning.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Jan 2011 08:30:35 +1300

Pekka,

Wouldn't the rule "Use ULA prefix inside the site and PA prefix (with
privacy addresses if desired) otherwise" be simpler? And, by default,
it would prevent the "inside" address being exported by mistake.

Regards
   Brian

On 2011-01-03 23:21, Pekka Savola wrote:
> IP where they can be reached and run TCP services at, or the privacy IP
> needs to be stored in DNS (not much point in that..).
>

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Jan 2011 08:33:13 +0200 (EET)

> it would prevent the "inside" address being exported by mistake.

Two prefixes in access lists doesn't seem simpler, though I see it 
could be an option in some other contexts. In our case, we have 20+ 
subnets which are not behind a single big firewall, so there is no 
"inside" and "outside". Also for that reason, using only globals would 
be preferable.

---

From: Mark Smith <[email-masked]>
Date: Wed, 5 Jan 2011 08:17:16 +1030

On Mon, 3 Jan 2011 12:21:41 +0200 (EET)

> IP needs to be stored in DNS (not much point in that..).

I think that could be achieved by using another address/prefix for that
purpose, which has a preferred lifetime of 0 and an ordinary valid
lifetime, although RFC3484 needs to be updated to use the largest
preferred lifetime as a tie-breaker when multiple valid addresses
remain as candidate sources. As the addresses have a zero preferred
lifetime, they wouldn't be used for outbound connections, but they're
still valid for inbound ones.

> could be substituted with stronger upper-layer identities e.g with 

I think it is inevitable that some of IPv6's more advanced and
dynamic addressing mechanisms and properties are going to make
traditional IPv4 addressing related security methods obsolete. When
ever a function is to be achieved in IPv6 that is being achieved in
IPv4, I think it is better not to assume that the IPv4 method is
directly translatable, and to see if there are methods which don't
constrain some of IPv6's new addressing mechanisms or possibly takes
advantage of them.

Regards,
Mark.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 5 Jan 2011 05:20:43 -0500

Hi Pekka,

> Operational input: when discussing the use of RFC4941 
> (privacy) addresses with our LAN/workstation admins, it 
> seemed as if there would be great benefit from being able to 
> specify an RFC3484 rule which would in essence say:
> 
> "do not use privacy addresses when communicating inside the 
> site [a set of designated destination prefixes], use it by 
> default otherwise"
> 
> I don't think this is possible today because rfc3484 policy 
> table only allows matching by prefixes, not by address type.

I agree with you that this would be useful.

> Has this come up in discussions / has anyone else thought about this?

Not exactly this point, but the ability to add specific prefixes into the policy table dynamically has been discussed several times before (e.g. in ULA scenarios) and will hopefully be solved soon.

On a side note, if you control the application you could use the IPV6_PREFER_SRC_PUBLIC flag defined in RFC5014 to effect such behavior.

Thanks
Suresh