Subject: [OPSEC] New Version Notification for draft-yourtchenko-opsec-humansafe-ipv6-00.txt

From: Andrew Yourtchenko <[email-masked]>
Date: Mon, 5 Mar 2012 12:06:44 +0100 (CET)

Hi all,

We will be very thankful for the review/comments on this draft and hope to 
present it in Paris.

--a

---------- Forwarded message ----------
Date: Mon, 05 Mar 2012 03:04:14 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: New Version Notification for
     draft-yourtchenko-opsec-humansafe-ipv6-00.txt

A new version of I-D, draft-yourtchenko-opsec-humansafe-ipv6-00.txt has been successfully submitted by Andrew Yourtchenko and posted to the IETF repository.

Filename:	 draft-yourtchenko-opsec-humansafe-ipv6
Revision:	 00
Title:		 Human-safe IPv6: Cryptographic transformation of hostnames as a base for secure and manageable addressing
Creation date:	 2012-03-02
WG ID:		 Individual Submission
Number of pages: 9

Abstract:
    Although the IPv6 address space within a single /64 subnet is very
    large, the typical distribution of the addresses in this space is
    very non-uniform.  This non-uniformity, together with the dictionary-
    based DNS brute-force enumeration, allows practical remote mapping of
    the IPv6 addresses in these subnets.  This document proposes a
    technique which can be used to decrease the exposure of the server
    subnets to trivial scanning.  As a side effect, the proposed
    technique allows to drastically simplify the address management.

The IETF Secretariat

---

From: Fernando Gont <[email-masked]>
Date: Tue, 06 Mar 2012 03:41:38 -0300

Hi, Andrew,

I read the I-D. Here are some comments:

* Section 4 states:
   The problem is twofold:  first, from the security point of view, one
   should try to avoid the easy to guess patterns that the traditional
   address assignment entails.  At the same time, the naive approach of
   assigning purely random addresses to servers is not very scalable in
   real world for maintenance reasons

I think this one is somewhat incorrect: What's usually deemed as hard to
manage is temporary addresses (RFC 4941), rather than the fact that the
identifiers are random (see e.g.,
<http://tools.ietf.org/id/draft-gont-6man-managing-slaac-policy-00.txt>).

* Section 5 states:
   The idea is to exploit the randomness property of the encryption
   function output.  The interface identifier, used within the IPv6
   address of the host, would be derived from the 64-bit data
   corresponding to hostname, encrypted with a site-wide "secret".

How would you distribute the secret.

That aside: have you read
<http://tools.ietf.org/id/draft-gont-6man-stable-privacy-addresses-00.txt>.
It solves the scanning problem and the management problem, with no need
to distribute secrets.

Thanks,
Fernando

On 03/05/2012 08:06 AM, Andrew Yourtchenko wrote:
> Hi all,
> 
> We will be very thankful for the review/comments on this draft and hope
> to present it in Paris.
> 
> --a
> 
> A new version of I-D, draft-yourtchenko-opsec-humansafe-ipv6-00.txt has
> been successfully submitted by Andrew Yourtchenko and posted to the IETF
> repository.
> 
> Title:         Human-safe IPv6: Cryptographic transformation of
> hostnames as a base for secure and manageable addressing
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
> 

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 6 Mar 2012 11:32:29 +0100 (CET)

Hi Fernando,

Thanks for the comments! inline..

> <http://tools.ietf.org/id/draft-gont-6man-managing-slaac-policy-00.txt>).

No, in this case I'm talking about permanently assigned addresses. It's 
just that telling the full IPv6 address over the phone or remembering it 
is a chore.

Example: 2001:db8:d923:297a:2068:d95d:cff5:308a. Make an experiment and 
measure how much it takes to get this address over to someone over the 
phone, without errors. That's the type of problem I had in mind.

> How would you distribute the secret.

USB stick, for example. Or write it on the wall in the ops room :-)

I probably should have not named it a "secret" - the idea was to have it 
secret enough so that a random script kiddie does not know it, yet it can 
be easily known by the staff. Any suggestions on how I should rename it 
so there's less confusion ?

> It solves the scanning problem and the management problem, with no need

It's nice, however it requires changes to host OSes.

--a

---

From: Fernando Gont <[email-masked]>
Date: Tue, 06 Mar 2012 09:28:10 -0300

Hi, Andrew,

> just that telling the full IPv6 address over the phone or remembering it

It wasn't clear to me that you were referring to this problem.

> phone, without errors. That's the type of problem I had in mind.

I know of quite a few folks that have already established the rule that
"you don't tell IPv6 addresses over the phone"

> USB stick, for example. Or write it on the wall in the ops room :-)

BTW, what are the types of systems that you have in mind for using this?
Host? Servers? Routers? All of them?

> secret enough so that a random script kiddie does not know it, yet it
> can be easily known by the staff. Any suggestions on how I should rename
> it so there's less confusion ?

Well, as far as the attacker is concerned, the "secret" is secret. So
the term is okay. But I guess it should be more clear to whom the
"secret" is secret, and how you plan to distribute it.

> It's nice, however it requires changes to host OSes.

Well, yes... but that's what you need to do to fix the underlying
problem of vulnerability to scanning...

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 6 Mar 2012 14:06:42 +0100 (CET)

Hi Fernando,

> It wasn't clear to me that you were referring to this problem.

Thanks! I will add the wording to make it more explicit.

> "you don't tell IPv6 addresses over the phone"

Indeed, precisely because of this problem, I suspect.

> Host? Servers? Routers? All of them?

Any of them - the doc does not set the policy on that. One example use 
will be using this approach for manually assigning link-local addresses to 
routers - then you can have the router names as next hops in the routing 
table.

Another could be a per-purpose addressing plans where the addresses 
in one "semantic domain" could use one secret, and the addresses in the 
other "semantic domain" could use another secret. And the NMS software 
could distinguish between them.

Yet another one is that if you know that your internal addressing follows 
this pattern, you can put a filter on the ingress firewall, and block the 
addresses that by definition can not belong to your space.

There are many possibilities one can come up with, that's why I did not 
want to explicitly limit them by enumerating.

> "secret" is secret, and how you plan to distribute it.

Thanks, I will put some more text for the next revision.

> problem of vulnerability to scanning...

Not really. From the pure scanning resistance standpoint, the lower /64s 
need to be as random as possible, that is it.

One trivial approach is to manually assign random MAC addresses to each 
host on the segment. It forces the attacker to scan the 2^48 space, 
which, even if 65536 times less than the full 2^64, is still a worthy 
challenge. The only thing it requires is the careful management of MAC 
addresses - however, this is already a given in some environments (e.g. in 
UCS) - where the VMs themselves need to have the MAC address assigned from 
the pool.

So, I think there's more than one way to skin a cat, with different 
tradeoffs.

--a

---

From: Fernando Gont <[email-masked]>
Date: Tue, 06 Mar 2012 10:51:11 -0300

> Indeed, precisely because of this problem, I suspect.

Exactly.

> Any of them - the doc does not set the policy on that. 

Well, if you do it for clients and servers, you'd need to move away from
slaac, at which point this would, by itself be a problem.

> One example use
> will be using this approach for manually assigning link-local addresses
> to routers - then you can have the router names as next hops in the
> routing table.

Sorry, are you using any specific pattern for the IID that helps to
identify whether an address has been generated with this scheme?

> Thanks, I will put some more text for the next revision.

Another comment: please specify the scheme with a function or
pseudocode, such that it's not necessary to go through the sample code
to grasp the proposal.

> need to be as random as possible, that is it.

Yes, but then there's the problem of tracking, and the operational
problem of temporary addresses. -- that's where the possible choices get
narrowed down.

> addresses - however, this is already a given in some environments (e.g.
> in UCS) - where the VMs themselves need to have the MAC address assigned
> from the pool.

At which point it becomes a 2^24 search space, since the OUI is known...

Thanks,

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 6 Mar 2012 15:35:12 +0100 (CET)

>> Indeed, precisely because of this problem, I suspect.

This approach could address it, I believe.

> slaac, at which point this would, by itself be a problem.

Again, at this stage I am not focusing at a particular use case.

> identify whether an address has been generated with this scheme?

The address that was not generated with the correct secret will most 
probably fail to decrypt correctly. You can try the code. Though would be 
good if you could help with some hard math on what is the probability of 
the false positives in this scenario.

> pseudocode, such that it's not necessary to go through the sample code

Any suggestions on the text ? I have in mind something like this, in a new 
section:

"Reference Implementation

The reference implementation derives the Interface Identifier by 
performing a logical XOR operation between the /64 prefix and the result 
of encrypting of the 8 characters of the hostname with an arbitrary 
network-wide secret. The reverse transformation can be used to verify the 
address / extract the hostname."

Would that be clear enough ?

> problem of temporary addresses. -- that's where the possible choices get

It is a separate problem, even if interrelated.

But my point was that changes on the hosts is only one of the ways to 
address this.

> At which point it becomes a 2^24 search space, since the OUI is known...

No. Strictly speaking it's 2^46 space. I flip the bit to specify the MAC 
address is locally administered, and there's no OUIs anymore because the 
*entire* MAC is generated randomly, minus the two bits.

--a

---

From: Fernando Gont <[email-masked]>
Date: Tue, 06 Mar 2012 19:46:51 -0300

Hi, Andrew,

> Again, at this stage I am not focusing at a particular use case.

I'm just noting that for nodes that already require manual
configuration, this technique might be feasible, but for those that
don't, this would impose other management burden (starting with
disabling slaac).

> probably fail to decrypt correctly.

It seems I need to look at the address more carefully, then.

> Any suggestions on the text ? I have in mind something like this, in a
> new section:

Avoid text, and use an expression. See e.g. how we specified the TCP SEQ
generation scheme in RFC 6528.

> *entire* MAC is generated randomly, minus the two bits.

Agreed. However, msot virtualization technologies seem to use, by
default, a specific OUI rather than setting the U/L bit to 1 and
randomizing the other 2^46 bits.

Thanks,