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

[Andrew Yourtchenko <[e-mail]>]

Hi Fernando,

On Tue, 6 Mar 2012, Fernando Gont wrote:

> Hi, Andrew,
>
> On 03/06/2012 07:32 AM, Andrew Yourtchenko wrote:
>>> 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>).
>>
>> 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.
>
> It wasn't clear to me that you were referring to this problem.

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

>
>
>
>> 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.
>
> I know of quite a few folks that have already established the rule that
> "you don't tell IPv6 addresses over the phone"

Indeed, precisely because of this problem, I suspect.

>
>
>>> * 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.
>>
>> 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?

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.

>
>
>
>> 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 ?
>
> 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.

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

>
>
>>> 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.
>>
>> 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...

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


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