Re: [v6ops] [EXTERNAL] Re: Improving ND security

[Fernando Gont <[e-mail]>]

Hi, Fred,

On 3/8/20 16:55, Templin (US), Fred L wrote:
[....]
>>>
>>> That is fine; we can accommodate CGAs in OMNI, cumbersome as they are.
>>> I have this on my TODO list for after the adoption call.
>>
>> Why "cumbersome"?
> 
> I realize the addresses are cryptographically-generated, which implies a security property
> which is good. But, they would not be the primary link-local addresses that neighbor
> nodes will know each other by - the CGAs will be found in the IPv6 ND message source
> and destination addresses, while the primary addresses will be carried in an additional
> IPv6 encapsulation header and would be the addresses that the NCEs are indexed by.

Not sure what you mean...



> So, all the CGAs really are is placeholders in the IPv6 header to run security checks over.
> They need not even be checked for uniqueness on the link, because it is the primary
> addresses and not the CGAs which need to be maintained as unique.

The point of CGAs is that in order for you to ND-answer for PREFIX:IID, 
you need to have the key identified by "IID". So, assuming /64s, you'd 
need to be lucky to, given a CGA (PREFIX:IID), generate a key-pair where 
the public key is identified by "IID".



>>>>> But then, RFC4380 offers a “poor-man’s” alternative to SEND/CGA. It
>>>>> places a message authentication code in the encapsulation headers of IPv6 ND messages so
>>>>> that the messages can pass a rudimentary authentication check.
>>>>
>>>> You mean the Teredo spec? If so, I don't think it includes any sort of
>>>> poor-man's SEND-CGA.
>>>
>>> It provides for message authentication,
>>
>> But what's special about SEND/CGAs is that they tie the address to a key...
> 
> OK, that sounds good. So, we like that property but AFAICT that is about all the
> CGA is good for in my application.

The thing is that, while in theory you could *theoretically* extend the 
use of CGAs as a spoofing mitigation, in the context of SEND CGAs are 
just employed for mitigating ND attacks... and that's kind a lot of 
effort for mitigating something that we have learned to 
live_with/mitigate in IPv4 in simpler ways.

i.e., I find SEND smart... but, in the bigger picture, not very 
compelling to deploy.


[...]
> The usage we have for OMNI is that of an Internet-based Client sending an
> authenticated, encapsulated, unicast RS message to an Internet-based Server
> which then must authenticate the message. 

Depends on what you mean by "authenticated". CGAs prove that the node 
that sends the packet is the owner of the address. Not more than that.

That's different than authenticating the client.

Similarly, you could authenticate the client, but that wouldn't mean 
that a client is the owner of a given address.




>>>>> So someone with
>>>>> security experience please help me out here – is RFC4380 authentication an acceptably
>>>>> secure  replacement for SEND/CGA that might be easier to work with and less
>>>>> cumbersome?
>>>>
>>>> Nope. Tee point of CGAs is that they allow you to prove address
>>>> ownership. There's nothing in RFC4380 that provides the same or similar
>>>> functionality.
>>>
>>> Why do we have to prove address ownership
>>
>> Well, that's one of the goals of SEND/CGAs. :-)
>>
>>
>>> and use a whacky address format like CGA?
>>
>> The *address format* is not really whacky. At the end of the day, it's a
>> random number, with the specific property that it's part of the hash of
>> a public key.
>>
>> looking at a CGA, you probably wouldn't be able to tell CGA from RFC7217.
[...]
> 
> I think if you look inside the IPv6 ND message and find a CG option you can
> infer that the address in the IPv6 header is a CGA.

Yep... but CGA != CGA option.

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