Subject: RE: [EXTERNAL] Re: Improving ND security

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 3 Aug 2020 14:22:31 +0000

Here’s another think about SEND. RFC3971 SEND says that it works in conjunction with
Cryptographically Generated addresses (CGA) per RFC3972. But, CGAs are cumbersome
to work with as the source and destination addresses of IPv6 packets, and SEND hints
that it can be used without CGA but does not tell how to do so.

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

Thanks - Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
Sent: Friday, July 31, 2020 3:13 PM
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: 6man <[email-masked]>; v6ops list <[email-masked]>
Subject: RE: [EXTERNAL] Re: Improving ND security

Hi Pascal, see below:

A major attack vector is an external attacker sending packets to the 2^64 or so possible addresses in the subnet.
[>] Subnet?? As in, an on-link IPv6 prefix? The large NBMA link that I want to use SEND
on will not have any of those – link-local only.

The attack causes a denial of service at the router that MUST store one packet for one second and multicast a NS lookup, which multiplies the effect.
[>] Again, we are talking about different kinds of links; there will not be any sort of
multicast explosion on the NBMA link based on a router receiving a SEND-protected
IPv6 ND message.

The attack is easy to perform from the outside and send offers no protection.
[>] For the OMNI NBMA link, the process is based on a Client sending a SEND-protected
RS message to exactly one router. The router authenticates the RS before processing it
further, which may include returning a unicasted RA. No NCEs are created until the RS
has been authenticated, and no multicast storms are initiated.

The only clear protection is to know in advance all the addresses present in the network and drop the rest. GRAND offers a way to preset the ND cache which is better than nothing but it offers no guarantee that the router has the full set of addresses I. Cache. In fact the concept of a cache is dated from the days memory was scarce and expensive. This concept is not needed And rather harmful in modern networks.
[>] The OMNI routers are not going to require any kind of ND cache presets; they
simply establish NCEs upon receipt *and* authentication of good RS messages.

Thanks - Fred

Regards,

Pascal

Le 31 juil. 2020 à 19:49, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Ted,

By “NM” I think you mean “Mobile Node?” That’s not really one of the use cases we’re talking about here. Or am I missing something?
[>]
Or, just call it a (mobile) “Stub-Network” – I think we are talking about the same
thing here.

In any case, you’re presuming some kind of trust establishment for non-router nodes, right? SEND only talks about trust establishment for routers. And, let’s be frank, doesn’t actually give us enough operational guidance that we would expect what _is_ said to be generally practicable.
[>]
OK, the specs I have been working dip their toes into the SEND pool but maybe they
should be updated to dive in completely? With an adoption call in progress, I don’t
know if it would be a good idea to make changes right now but be assured that it
will be added to the TODO list – would that be acceptable for now?

Thanks - Fred

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 3 Aug 2020 15:37:54 +0000

IMHO: Forget about Authentication – it would not fly.
Any Authentication would need to possess a key against every neighbor.

The same RFC that you mentioned: “The receiver deems the authentication successful if the two values match.”
PKI is the best place for key materials (and much more). But only strict security requirements could push people to PKI complexity.

Compromise is needed between:

1.      Distributed database of SLAAC (6lo and SAVI are centralized)

2.      No complexity of key management (Authentication is out)

3.      Security that is possible in such circumstances (no “man-in-the-middle”, low pressure from DoS)
Full fix of all security problems are not possible.
If one would change (1) or (2) then it would be not SLAAC anymore.

Ed/
From: v6ops [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
Sent: 3 августа 2020 г. 17:23
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: v6ops list <[email-masked]>; 6man <[email-masked]>
Subject: Re: [v6ops] [EXTERNAL] Re: Improving ND security

Thanks - Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
Sent: Friday, July 31, 2020 3:13 PM
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>; v6ops list <[email-masked]<mailto:[email-masked]>>
Subject: RE: [EXTERNAL] Re: Improving ND security

Hi Pascal, see below:

Thanks - Fred

Regards,

Pascal

Hi Ted,

Thanks - Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 3 Aug 2020 15:51:33 +0000

Thanks for your opinion, Ed, but it does not apply for the OMNI use case because
the keys only need to be known to a fixed (and finite) set of Servers which can
keep in sync via a shared filesystem. Again, if anyone can speak to the security
of RFC4380 in relation to SEND/CGA *within this context* I would be interested.

Fred

From: Vasilenko Eduard [mailto:[email-masked]]
Sent: Monday, August 03, 2020 8:38 AM
To: Templin (US), Fred L <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>
Cc: v6ops list <[email-masked]>; 6man <[email-masked]>
Subject: Re: Improving ND security

Ed/
Cc: v6ops list <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>

Thanks - Fred

Hi Pascal, see below:

Thanks - Fred

Regards,

Pascal

Hi Ted,

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Mon, 03 Aug 2020 18:32:37 +0200

>    keep in sync via a shared filesystem. 

Maybe we should first look at which application domains we want to discuss.
For most people, if you have a fixed set of servers connected to a single
LAN, then you typically don't have a security problem with ND. Of course,
there could still be networks where ND security is an issue even if all
devices are known.

I think the common case for ND security issues is a an ethernet (or
ethernet-like wifi) where untrusted devices can connect. However for
the common case where bridges just accept any MAC address, what prevents
the attacker from sending packets with the MAC address of a victim?

Of course there is the special case where bridges lock the MAC addresses of
devices connected to ports, but in those cases, bridges could also lock the
IPv6 address and otherwise limit ND traffic.

The easiest way to solve the issue for small networks is to give each host
a private vlan. The would break multicast, but multicast in an untrusted 
environment is probably not such a great idea anyhow.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 3 Aug 2020 13:06:10 -0300

On 3/8/20 11:22, Templin (US), Fred L wrote:
> Here’s another think about SEND. RFC3971 SEND says that it works in 
> conjunction with Cryptographically Generated addresses (CGA) per RFC3972. But, CGAs are 
> cumbersome to work with as the source and destination addresses of IPv6 packets, 
> and SEND hints that it can be used without CGA but does not tell how to do so.

Of the top of my head, CGAs are a core part of send.

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

> So someone with 
> security experience please help me out here – is RFC4380 authentication an acceptably

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.

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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 3 Aug 2020 16:45:33 +0000

Hi Fernando,

It has come to my attention that my message response formatting has become
unwieldy, so I am leaving big spaces intentionally so folks can see where my
responses fall - see below:

Fred

> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]]
> Sent: Monday, August 03, 2020 9:06 AM
> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
> know that the content is safe.

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.

> You mean the Teredo spec? If so, I don't think it includes any sort of

It provides for message authentication, and it is widely-deployed which suggests
to me that the vendors who support it believe it is secure. So, if it is secure enough
for RFC4380, then shouldn't it also be secure enough for OMNI?

> ownership. There's nothing in RFC4380 that provides the same or similar

Why do we have to prove address ownership and use a whacky address format like
CGA? There is nothing in the OMNI spec that needs or wants CGAs in any fashion
unless they are absolutely required for security. Isn't it enough to prove message
authentication using the mechanisms of RFC4380 without having to accommodate
the excess baggage of CGAs??

---

From: Christian Huitema <[email-masked]>
Date: Mon, 3 Aug 2020 10:01:52 -0700

> On Aug 3, 2020, at 9:35 AM, Fernando Gont <[email-masked]> wrote:
> 
>> ...
>> 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.

Configuration mistakes were a big concern during the design of Teredo, and that's a reason why Teredo embeds continuity tests. But these tests will not resist an on-path attacker, let alone an on-link attacker.

>> ...

-- Christian Huitema

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 3 Aug 2020 17:20:24 +0000

Christian,

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Monday, August 03, 2020 10:02 AM
> To: Fernando Gont <[email-masked]>
> Cc: Templin (US), Fred L <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>; v6ops list
> <[email-masked]>; 6man <[email-masked]>
> >> 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.
> >
> Configuration mistakes were a big concern during the design of Teredo, and that's a reason why Teredo embeds continuity tests. But
> these tests will not resist an on-path attacker, let alone an on-link attacker.

What has been the experience with RFC4380 security in-the-wild? Is it considered
"secure enough" out of the box? Or, if you had to do it again would you incorporate
something "more secure" like SEND/CGA?

Thanks - Fred

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 3 Aug 2020 18:02:07 +0000

Hi Fred,
SEND assumes RSA "RSASSA-PKCS1-v1_5  algorithm and SHA-1 hash" that is good enough for majority of purposes.
Currently Elliptic-curve cryptography is more popular, but it is not mandatory - RSA is good enough.

Teredo specification assumes that "authentication algorithm, shared with the server", "agreed-upon authentication algorithm".
Hence, it is not possible to tell exactly how secure it is.
But because by default "To maximize interoperability, this specification defines a default algorithm in which the authentication value is computed according the HMAC specification [RFC2104] and the SHA1 function [FIPS-180]."
We could say that it is much weaker then SEND, because HMAC in principle is much weaker then open key cryptography (RSA).

And we are comparing orange to apple here, because
- SEND is used for neighbor authentication
- Teredo is the tunnel
They have different purpose in networking.

Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
Sent: 3 августа 2020 г. 20:20
To: Christian Huitema <[email-masked]>; Fernando Gont <[email-masked]>
Cc: 6man <[email-masked]>; v6ops list <[email-masked]>
Subject: Re: [v6ops] [EXTERNAL] Re: Improving ND security

Christian,

> Cc: Templin (US), Fred L <[email-masked]>; Pascal Thubert 
> (pthubert) <[email-masked]>; v6ops list <[email-masked]>; 6man 
> <[email-masked]>
> This message was sent from outside of Boeing. Please do not click 
> links or open attachments unless you recognize the sender and know that the content is safe.
> 
> >> places a message authentication code in the encapsulation
> Configuration mistakes were a big concern during the design of Teredo, 
> and that's a reason why Teredo embeds continuity tests. But these tests will not resist an on-path attacker, let alone an on-link attacker.

What has been the experience with RFC4380 security in-the-wild? Is it considered "secure enough" out of the box? Or, if you had to do it again would you incorporate something "more secure" like SEND/CGA?

Thanks - Fred

> -- Christian Huitema

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fernando Gont <[email-masked]>
Date: Mon, 3 Aug 2020 15:52:35 -0300

Hi, Fred,

On 3/8/20 13:45, Templin (US), Fred L wrote:
[....]
> I have this on my TODO list for after the adoption call.

Why "cumbersome"?

> It provides for message authentication, 

But what's special about SEND/CGAs is that they tie the address to a key...

> and it is widely-deployed which suggests
> to me that the vendors who support it believe it is secure. 

I'm sure others probably know better, but... I think Teredo is mostly MS 
+ Miredo. (when it comes to implementation)

And Re: deployment, IIRC Teredo has been phased out.

> So, if it is secure enough for RFC4380, then shouldn't it also be secure enough for OMNI?

I believe Auth in Teredo is a totally different thing from SEND/CGAs.

Regarding OMIN, I Haven read the draft/spec, yet...

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

> There is nothing in the OMNI spec that needs or wants CGAs in any fashion

Both are different things.

One thing is to authenticate the contents of a message. And a different 
one is to be able to tell that one specific host is "authorized" to use 
one specific address...

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 3 Aug 2020 19:55:47 +0000

Hi Fernando,

> Sent: Monday, August 03, 2020 11:53 AM

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

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

> Regarding OMIN, I Haven read the draft/spec, yet...

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. (The "link" in this case is the
Internet itself.) The encapsulation format is based on RFC4380 encapsulation
but with a different UDP port number than specified for RFC4380. A second
level of encapsulation is also added per RFC2473. The CGA of the Client is
in the IPv6 ND source address, "All-Routers" is in the IPv6 ND destination
address, the OMNI ULA of the Client is in the RFC2473 source address, and
either the OMNI ULA of the Server or Subnet Router Anycast is in the
RFC2473 destination address. The outer UDP/IP header has the Internet
source address of the Client and the Internet destination address of the
Server. That is a lot of addresses to carry around in a single packet, but if
we must use CGAs then we do what we have to do.

In the reverse direction, the Server must also include its CGA as the source
of the RA message, the CGA of the Client as the destination address, and
with the RFC2473 header having the Server's OMNI ULA as the source and
the OMNI ULA of the Client as the destination. The UDP/IP header has the
Internet addresses as before. Again, lots of addresses to juggle around due
to the need to include CGAs. 

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

> one is to be able to tell that one specific host is "authorized" to use

The only reason I am hesitant is that it just seems that the usage of CGAs
envisioned for OMNI is just as a cryptographically-generated "bag of bits".
They are not used as indexes into the neighbor cache. They are not
examined by routers, bridges or switches, etc. They are simply payload
bits carried in a special place known as the IPv6 source and destination
address. Is that good enough?

Thanks - Fred

---

From: Fernando Gont <[email-masked]>
Date: Mon, 3 Aug 2020 19:32:10 -0300

Hi, Fred,

On 3/8/20 16:55, Templin (US), Fred L wrote:
[....]
> IPv6 encapsulation header and would be the addresses that the NCEs are indexed by.

Not sure what you mean...

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

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

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

>> looking at a CGA, you probably wouldn't be able to tell CGA from RFC7217.
[...]
> infer that the address in the IPv6 header is a CGA.

Yep... but CGA != CGA option.

Thanks,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Aug 2020 05:35:18 +0000

I agree that a valuable ND security should not only protect address ownership but also provide SAVi, which send does not.

SeND has to protect distributed stateless address claim so they decided to embed the proof of ownership in the address. This limits the size of the security proof to 64 bits which is far from sufficient. So CGA added those 3 bits that optionally make the computational cost more cumbersome. Nobody uses that so the protection is low. Very powerful devices could potentially do that but smaller devices will be left with little protection and hardship to form new addresses.

In a stateful architecture the proof of ownership can be separated from the address and made bigger. It is stored in the infrastructure together with the address on the first come. A same proof can be used for multiple addresses (and obfuscated with rehashing) so it does not affect privacy addressing.

https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/ Is sitting in the rfc editor queue and soon on the shelf. It does all the above. SAVI. Proof of ownership. But it only works for addresses that are registered through rfc 8505, which makes ND proactive/stateful.

All the best,

Pascal

Le 5 août 2020 à 01:41, Fernando Gont <[email-masked]> a écrit :

Hi, Fred,

Why "cumbersome"?

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

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.

[...]

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.

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

So someone with

Thanks,

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 5 Aug 2020 08:30:16 +0000

Hi Pascal,
I believe that you are a little misleading audience on SeND.

Yes, they did something terrible: they have invented their own crypto algorithm for Interface ID generation.
It is something like HMAC: based on “proof of work”. It is a some sort of signature, but weak and expensive (a lot of computations). Yet could be simple -  complexity regulated by special 3 bits.
Good security rule has been broken: never ever develop your own crypto algorithm! One should have very good reasons to do it. Even more, never develop crypto protocol. Remember how many vulnerabilities have been found in SSL or TLS on the protocol level.
When I was reading about this requirement that bits should be 0 – it reminded me block chain☺ Is Satoshi Nakamoto was behind this 0 version of block chain?

HMAC-like is the big computation burden for any processor. It is really “killing application” for IoT. Literally “killing”.

I was not capable to understand why it has been done for SeND. Why it was not acceptable to generate Interface ID in typical way?
Why in principle we need “Cryptographically Generated Addresses”?!?

I was really laughing when I have read this justification in SeND: “second signature algorithm is only necessary as a recovery mechanism, in case a flaw is found in RSA”

But what if a flaw would be found in 2nd mechanism – may be 3rd mechanism would be needed? Why 2nd mechanism (CGA) is so miserable from cryptographic point of view (low protection, high computation)?

After this jumping around proprietary HMAC (in IID),

Normal Private key of RSA is used over whole packet – it is real protection. Look to very small section 6 of RFC 3972 (CGA).
Pascal, protection is strong, but real assurance is given from RSA, not from this simplified HMAC that everybody would probably keep on minimal level of complexity (as you said).

IMHO: CGA part of SeND should be just discarded as redundant. It is exactly what Pascal did in his draft that he is promoting here.

I agree that SeND have seen dinosaurs. Zero chances that it would be accepted by the market.

Eduard
From: ipv6 [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 5 августа 2020 г. 8:35
To: Fernando Gont <[email-masked]>
Cc: 6man <[email-masked]>; v6ops list <[email-masked]>
Subject: Re: [v6ops] [EXTERNAL] Re: Improving ND security

Pascal

Le 5 août 2020 à 01:41, Fernando Gont <[email-masked]<mailto:[email-masked]>> a écrit :
Hi, Fred,

Why "cumbersome"?

[...]

So someone with

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

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 5 Aug 2020 09:12:51 +0000

Pascal,
I could guess that your https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd
Has 1 additional advantage that you did not mention in the draft: it does not need PKI.
You did not mention anywhere in the draft that Public/Private key pair is locally generated, and should not be registered anywhere.

I guess it looking to your claim: “first come first serve”.
Then ND record expiration is possible only on timer. It is not suitable for a few cases.
How you would share one IPv6 between N hosts? Use cases: (1) Permanent (anycast) or (2) fast dynamic (VRRP-like redundancy, active/standby)
Where is the procedure to manually extract Private key from 1 host and feed it to other host (in redundant pair).
Redundant hosts probably belongs to something important – they should have protection for IP address hijacking as the 1st priority.
Looks like you have missed it.
Eduard
From: Vasilenko Eduard
Sent: 5 августа 2020 г. 11:32
To: 'Pascal Thubert (pthubert)' <pthubert=[email-masked]>; Fernando Gont <[email-masked]>
Cc: 6man <[email-masked]>; v6ops list <[email-masked]>
Subject: RE: [v6ops] [EXTERNAL] Re: Improving ND security

Hi Pascal,

Eduard
To: Fernando Gont <[email-masked]<mailto:[email-masked]>>

Pascal

Why "cumbersome"?

[...]

So someone with

Thanks,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Aug 2020 11:48:40 +0000

> I believe that you are a little misleading audience on SeND.

How so, Eduard? I could not find an answer in your mail below and that was certainly not an intention.

The reduced security is the due to the size of the CGA that has to fit in 64 bits. It is thus sensitive to brute force attack. The defense in RFC 3972 is the use of the Sec parameter that makes the generation if the CGA compute intensive. The problem with that is that small devices cannot generate hih Sec CGAs so they become a second class device with no privacy.

Quote

“

   For Sec values greater than zero, the above algorithm is not
   guaranteed to terminate after a certain number of iterations.  The
   brute-force search in steps 2 - 3 takes O(2^(16*Sec)) iterations to
   complete.  The algorithm has been intentionally designed so that the
   generation of CGAs with high Sec values is infeasible with current
   technology.

“

Pascal

Hi Pascal,

Eduard

Pascal

Why "cumbersome"?

[...]

So someone with

Thanks,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Aug 2020 12:20:14 +0000

> Has 1 additional advantage that you did not mention in the draft: it does not need PKI.

This is correct, Eduard

> You did not mention anywhere in the draft that Public/Private key pair is locally generated, and should not be registered anywhere.

We make no assumption how the key pair is obtained but it is perfectly fine to generate it locally as you point out. It is also perfectly acceptable to provision it in one or more nodes, if you want to use it for anycast. In that case you also need to provision a modifier.

Anycast operations are globally underspecified. To make them work in the context of RFC 8505, one needs to synchronize the TIDs so the registrations are all accepted.

Note: There’s a lot more state to synchronize than this if you want to implement redundant routers so it does not change the world. The synchronization mechanism and the synchronized data are usually proprietary. This is one of the basic things you have to consider when writing code in a router.

Keep safe;

Pascal

From: Vasilenko Eduard <[email-masked]>
Sent: mercredi 5 août 2020 11:13
To: Pascal Thubert (pthubert) <[email-masked]>; Fernando Gont <[email-masked]>
Cc: 6man <[email-masked]>; v6ops list <[email-masked]>
Subject: RE: [v6ops] [EXTERNAL] Re: Improving ND security

Pascal,

To: 'Pascal Thubert (pthubert)' <pthubert=[email-masked]<mailto:pthubert=[email-masked]>>; Fernando Gont <[email-masked]<mailto:[email-masked]>>

Hi Pascal,

Eduard

Pascal

Why "cumbersome"?

[...]

So someone with

Thanks,

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 5 Aug 2020 13:27:21 +0000

Hi Pascal,
It is exactly the problem. You continue to talk on some proprietary (and low security) algorithm that is invented inside CGA.
I do not believe that it is possible to prove any level of security for it (even if 3 bits would push for huge computation resource).
Hence, you claim low level of security for SeND in general.

But in reality, the level of SeND security is very high, because it is based on additional crypto algorithm (RSA) that is good enough even for very demanding applications now.

Just forget about CGA – it is not the source of SeND security guaranties.

By the way, It is exactly what you did in your draft.

Eduard
From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: 5 августа 2020 г. 14:49
To: Vasilenko Eduard <[email-masked]>; Fernando Gont <[email-masked]>
Cc: 6man <[email-masked]>; v6ops list <[email-masked]>
Subject: RE: [v6ops] [EXTERNAL] Re: Improving ND security

Quote

“

“

Pascal

Hi Pascal,

Eduard

Pascal

Why "cumbersome"?

[...]

So someone with

Thanks,

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 5 Aug 2020 13:35:03 +0000

Therefore, you have decided not to do recommendations.
Smart vendor would do clever things.
Stupid one would miss the point.
And both implementations would be fully compliant to standard. Just result would be very different.
I see.
Ed/
From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: 5 августа 2020 г. 15:20
To: Vasilenko Eduard <[email-masked]>; Fernando Gont <[email-masked]>
Cc: 6man <[email-masked]>; v6ops list <[email-masked]>
Subject: RE: [v6ops] [EXTERNAL] Re: Improving ND security

This is correct, Eduard

Keep safe;

Pascal

From: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Sent: mercredi 5 août 2020 11:13
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Fernando Gont <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>; v6ops list <[email-masked]<mailto:[email-masked]>>
Subject: RE: [v6ops] [EXTERNAL] Re: Improving ND security

Pascal,

Hi Pascal,

Eduard

Pascal

Why "cumbersome"?

[...]

So someone with

Thanks,