Subject: RE: AERO/OMNI dropping support for SEND/CGA

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 1 Dec 2020 09:06:57 +0000

Hi Fred,
SeND needs a refresh. CGA looks ridicules now in principle. You should not use it.

I am not sure: does it make sense to develop something else instead (based on ecliptic curves).
As Fernando pointed many times: many things in ND could be resolved only by digital signature (he calls it "untrusted model").
But as we see: market has rejected PKI. Digital signature is not useful without proper key management.
IMHO: it is better to keep digital signature as a separate standard.
Therefore, if you have cycles for separate OMNI addendum, then it is better to have it for completeness. If not - not much to lose now.
But make sure that Open Key Cryptography and PKI (!) would be possible to add later.
What if something would be innovated in PKI and it became popular?
Reminder: PKI is needed not just for ND. Enterprises have the big pressure to protect all applications by TLS.
Your vertical would probable lead on PKI adoption.

As an alternative: you could talk with IT and Security people in your vertical: if they believe in massive deployment of PKIs then you have to have Digital Signature for ND.
It would still not guaranty that it would be used, because hosts would need support for it at ND level, but it is already the good situation to try.
Hence again, better to keep it in separate specification.

Eduard
> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: 1 декабря 2020 г. 1:12
> To: [email-masked]
> Subject: AERO/OMNI dropping support for SEND/CGA
> 
> Folks, this is a big decision point for the AERO/OMNI drafts but I am preparing to
> drop support for SEND/CGA (RFC3971; RFC3972). This means that IPv6 ND
> message authentication on OMNI interfaces will use a simple HMAC the same as
> is done for Teredo (RFC4380; RFC6081). If anyone knows why that might cause
> problems, it would be best to speak up now.
> 
> Fred
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 1 Dec 2020 10:27:47 +0000

Hello Eduard 

I believe your question about a replacement for secure ND deserves its own thread to ensure a better visibility. 

Note: RFC 8928 was designed for a network where all nodes have a virtual P2P link with the router and the prefix shows as not-onlink; this way nodes only need to prove the ownership to the router and that makes things a lot simpler.

Keep safe,

Pascal

> Le 1 déc. 2020 à 10:07, Vasilenko Eduard <[email-masked]> a écrit :
> 
> Hi Fred,

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 1 Dec 2020 11:27:02 +0000

Hi Pascal,
Yes, centralized model (no SLAAC) greatly improve security.
But FCFS (1st come - 1st serve) is still the big security hole.
Server could be in reload (software or hardware refresh), Intruder could claim it's IP address. Then everybody would show credentials to Intruder (fortunately hashed - but it would not help too much, about 50% is possible to revert to plain text).

Digital Certificate does resolve this situation too. It has additional value.
Ed/
> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: 1 декабря 2020 г. 13:28
> To: Vasilenko Eduard <[email-masked]>
> Cc: Templin (US), Fred L <[email-masked]>; [email-masked]
> Subject: Re: AERO/OMNI dropping support for SEND/CGA
> 
> Hello Eduard
> 
> Note: RFC 8928 was designed for a network where all nodes have a virtual P2P
> link with the router and the prefix shows as not-onlink; this way nodes only need
> to prove the ownership to the router and that makes things a lot simpler.
> 
> Keep safe,
> 
> Pascal
> 
> > As Fernando pointed many times: many things in ND could be resolved only by
> digital signature (he calls it "untrusted model").
> > Therefore, if you have cycles for separate OMNI addendum, then it is better to
> have it for completeness. If not - not much to lose now.
> > As an alternative: you could talk with IT and Security people in your vertical: if
> they believe in massive deployment of PKIs then you have to have Digital
> Signature for ND.
> > It would still not guaranty that it would be used, because hosts would need
> support for it at ND level, but it is already the good situation to try.
> >> Folks, this is a big decision point for the AERO/OMNI drafts but I am
> >> preparing to drop support for SEND/CGA (RFC3971; RFC3972). This means
> >> that IPv6 ND message authentication on OMNI interfaces will use a
> >> simple HMAC the same as is done for Teredo (RFC4380; RFC6081). If
> >> anyone knows why that might cause problems, it would be best to speak up
> now.
> >>
> >> Fred
> >>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 1 Dec 2020 14:11:57 +0000

Eduard, thank you for your note. AERO/OMNI will adopt the Teredo method
of securing IPv6 ND messages over the open Internet as specified in RFC4380 .

Thanks - Fred

> From: Vasilenko Eduard [mailto:[email-masked]]
> Sent: Tuesday, December 01, 2020 1:07 AM
> To: Templin (US), Fred L <[email-masked]>; [email-masked]
> Subject: RE: AERO/OMNI dropping support for SEND/CGA
> 
> Hi Fred,

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 1 Dec 2020 12:16:58 -0600

Hi Fred,

In draft-templin-6man-omni-interface-51

I could not see EUN in Figure 2.
Also a figure showing the flow of packets in the network from source to
destination is missing.

Maybe you need an architecture draft to clear these things out.

Behcet

On Mon, Nov 30, 2020 at 4:12 PM Templin (US), Fred L <
[email-masked]> wrote:

> preparing
> to drop support for SEND/CGA (RFC3971; RFC3972). This means that IPv6 ND
> message authentication on OMNI interfaces will use a simple HMAC the same
> as is done for Teredo (RFC4380; RFC6081). If anyone knows why that might
> cause problems, it would be best to speak up now.
>
> Fred
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 1 Dec 2020 18:44:28 +0000

Behcet,

To be clear, there is now a -52 version of the draft that bows to the pressures
of those who still insist on the /64 boundary. Earlier draft versions can still be
referenced for those who like /65+, but there is strong resistance to using the
54 “zero” bits of fe80::/10 which is where the extra prefix bits would end up
going. I was told that trying to define a use for those bits would be pushing a
“large rock up a hill”, and I have experienced that struggle firsthand.

To your comments, yes an EUN should certainly be added to figure 2 and
adding a packet flow diagram is something that can be done as well. I can’t
give a timeframe for a next draft version but will put this in a TODO note
to myself.

Thanks - Fred

From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Tuesday, December 01, 2020 10:17 AM
To: Templin (US), Fred L <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: AERO/OMNI dropping support for SEND/CGA

Hi Fred,

I could not see EUN in Figure 2.
Also a figure showing the flow of packets in the network from source to destination is missing.

Behcet

On Mon, Nov 30, 2020 at 4:12 PM Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Folks, this is a big decision point for the AERO/OMNI drafts but I am preparing
to drop support for SEND/CGA (RFC3971; RFC3972). This means that IPv6 ND
message authentication on OMNI interfaces will use a simple HMAC the same
as is done for Teredo (RFC4380; RFC6081). If anyone knows why that might
cause problems, it would be best to speak up now.

Fred

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 2 Dec 2020 10:09:58 -0600

> give a timeframe for a next draft version but will put this in a TODO note

Sure. As I mentioned you could consider separating some parts of this quite
large document into an architecture document and protocol document.

Behcet

Behcet

> Thanks - Fred
>
>
>
> *From:* Behcet Sarikaya [mailto:[email-masked]]
> *Sent:* Tuesday, December 01, 2020 10:17 AM
> *To:* Templin (US), Fred L <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* [EXTERNAL] Re: AERO/OMNI dropping support for SEND/CGA
>
>
>
> Hi Fred,
>
>
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 2 Dec 2020 16:40:25 +0000

Thanks for the suggestion, Behcet. In terms of architecture, at its most fundamental
level it is simply just the marriage of ISATAP and Teredo. (Well, there is a lot more to
it than just that, but everything builds on top of those principles.)

Fred

From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Wednesday, December 02, 2020 8:10 AM
To: Templin (US), Fred L <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [EXTERNAL] Re: AERO/OMNI dropping support for SEND/CGA

On Tue, Dec 1, 2020 at 12:44 PM Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Behcet,

Sure. As I mentioned you could consider separating some parts of this quite large document into an architecture document and protocol document.

Behcet

Behcet
Thanks - Fred

From: Behcet Sarikaya [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, December 01, 2020 10:17 AM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: AERO/OMNI dropping support for SEND/CGA

Hi Fred,

Behcet

Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 2 Dec 2020 19:13:54 +0100

> SeND needs a refresh. CGA looks ridicules now in principle. You should not use it.

I am not sure what in CGA might need ridiculuous?

Probably the old crypto algorithms involved?

> I am not sure: does it make sense to develop something else instead (based on ecliptic curves).

If there is something new to be developped it would need to take into 
account the 'post-quantum' crypto, i.e. algorithms whose output would 
resist brute force attacks performed by forthcoming quantum computers.

These stronger algorithms would run on classical computer still.

> As Fernando pointed many times: many things in ND could be resolved only by digital signature (he calls it "untrusted model").

YEs yes.

Alex

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 2 Dec 2020 18:58:08 +0000

It is funny how CGA purpose is justified: "for the case if RSA would fail". (in SeND RFC)
It is the redundant algorithm to the normal RSA open key cryptography in SeND.
I have the temptation to ask: what if CGA would fail too? May be 3rd redundant cryptography is needed? (Sarcasm).

The essence of CGA algorithm:
It is based on the fact that original owner does not care about IID – it could be hash, but intruder would need exact IID.
If one would ask Sec of leading Zero in the hash, then legal host would need initially 2^(16*Sec) time to generate IID.
But Intruder would need 2^(59+16*Sec).

It is like block-chain - much more time and resources needed than any open key cryptography:
1. a lot of hashes to generate IID -> very expensive
2. in the case of collision (DAD?) - change "modifier" (parameter) and calculate again -> time consuming

I am not so optimistic about quantum. I believe that this hype is ground-less.
Analog computer is something very powerful for special tasks - was popular in 1970x.
It could be revived on the next level of performance. That’s it.
Ed/
> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: 2 декабря 2020 г. 21:14
> To: [email-masked]
> If there is something new to be developped it would need to take into account
> the 'post-quantum' crypto, i.e. algorithms whose output would resist brute force
> attacks performed by forthcoming quantum computers.
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 2 Dec 2020 19:07:54 +0000

> > As Fernando pointed many times: many things in ND could be resolved only by digital signature (he calls it "untrusted model").

Our plan and intention is to inherit the digital signature methods in Teredo.
If there is anything wrong with that short of quantum-robustness, please
speak up.

We could have called what we are doing "TereTAP", or "ISAdo" but it is
more than just that. So, we called it OMNI.

Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 2 Dec 2020 23:20:57 +0100

Le 02/12/2020 à 20:07, Templin (US), Fred L a écrit :
>>> As Fernando pointed many times: many things in ND could be
>>> resolved only by digital signature (he calls it "untrusted
>>> model").
>> 
>> YEs yes.
> 
> Our plan and intention is to inherit the digital signature methods in
> Teredo. If there is anything wrong with that short of
> quantum-robustness, please speak up.

I am not a specialist of crypto but I heard of a contest at NIST(?)
about quantum resistant algorithms.  If I remember correctly, three
candidates were selected in July.  I am not sure where are they now;
maybe they already stepped further in the selection process.

But some of these candidates do have open source implementations, and
are not specified in RFCs.  If one has a crystal ball, one can decide
which of these algorithms will be the AES of the future and bring that
to OMNI.

(I hope I did not say too naïve things)

A respected crypto oppinion also says that it might be not necessary to
consider these as of now, or that it is too early.  For my part I think
it is never too early for these things.

Alex

> 
> We could have called what we are doing "TereTAP", or "ISAdo" but it
> is more than just that. So, we called it OMNI.
> 
> Fred
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 3 Dec 2020 10:03:58 -0600

Hi Fred,

What I am observing from the ensuing discussion is that you should consider
a reboot of OMNI seriously. I suggest you reorg your drafts, add an
architecture draft and start from scratch with -00 drafts.
This could be good time to start that process.

Behcet

On Wed, Dec 2, 2020 at 10:40 AM Templin (US), Fred L <
[email-masked]> wrote:

> *Sent:* Wednesday, December 02, 2020 8:10 AM
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [EXTERNAL] Re: AERO/OMNI dropping support for SEND/CGA
>
>
>
>
>
> Sure. As I mentioned you could consider separating some parts of this
> quite large document into an architecture document and protocol document.
>
>
>
> Behcet
>
>
>
> Behcet
>
> Thanks - Fred
>
>
>