Le 21/10/2022 à 16:24, Joel Halpern a écrit :
I am unable to parse the statement below as written. I presume I am
missing something that is clear to the writer.
I can understand asking that IKE(v3?) and IPSEC ESP be upgraded to
support quantum resistant algorithms.
How about IPsec AH ICV? Is it quantum resistant when not using
quantum-resistant algorithms? I mean, there is no spec to tell how to
calculate that ICV by using one of these Dilithium(?) or other recent
quantum-resistant algorithm.
Similarly, how about Mobile IPv6 HMAC_SHA1 in the Binding Update part of
RR test?
As I understand it, the security community is doing that. if there
are upgrades to those protocols themselves that would help make the
system quantum resistant, that would be a reasonable thing to
disucss with the security community.
But I have no idea what it would mean for IPv6 to be quantum
resistant. Without knowing what that means, I can't even guess
whether there is anything to do there.
Well, maybe it is a stretch.
The security of IPv6 is IPsec. IPsec might not be quantum-resistant,
and as such maybe IPv6 neither.
One would not like an IPvx to come out claiming to be quantum-resistant
and replace IPv6. This is what already happened with IPv6: it was said
that IPv4 lacked certain features like mobility, multicast, QoS and...
security, whereas IPv6 offered all of them.
Alex
Yours,
Joel
On 10/21/2022 4:36 AM, Alexandre Petrescu wrote:
In this addressing discussion, I was thinking, thanks to a private
conversation with experts from a manufacturer, that it might make
sense to try to make IPv6 to be quantum resistant.
One might think IPv6 has nothing to do with it, but one should
consider the security aspects of IPv6 (IPsec, some security in
Mobile IPv6, CGAs, etc). They should be migrated to the use of
quantum-resistant protocol implementations.
One would not like IPv6 to be discarded simply because its security
might be deemed by some to not be quantum-resistant.
Alex
Le 30/09/2022 à 10:36, Luigi Iannone a écrit :
Hi All,
During the last INTArea meeting the discussion on the two drafts
related to Internet addressing had three the clear outcomes: 1.
The issue seems to go beyond what the INTArea has been chartered
for. 2. The pain points (aka the problem) have to be
scoped in a better way. In the current form, the scope is so
broad that we risk ending up trying to boil the ocean without
achieving any relevant result. 3. Incremental deployability
remains a MUST. No revolution. Evolution is the only option.
Concerning point 1. The documents have been taken out from
INTArea (new naming). We still continue the discussion on the
INTArea mailing list, at least temporarily with the option to
have a dedicated mailing list in the future.
I would like to restart discuss on point 2: the scope.
The considerations draft
(https://datatracker.ietf.org/doc/draft-iannone-internet-addressing-considerations/
<https://datatracker.ietf.org/doc/draft-iannone-internet-addressing-considerations/>)
highlighted three properties, namely: Property 1: Fixed Address
Length Property 2: Ambiguous Address Semantic Property 3: Limited
Address Semantic Support
But before going to the discussion of which property we
should/want change the first question the comes up is: what does
an address identify exactly?
A simple answer would be: an Interface.
But we all know that reality is far more complex, as pointed out
with the many existing examples in the considerations draft.
What is even more complex is how to provide a wealth of answers
to the above question within a framework for evolved addressing
that does not rely on the continued point-wise approach we see in
the Internet today.
In order to start specifying what this evolved addressing
framework could be, the first steps are: - paraphrasing
Lixia Zhang’s question from the recent RTG WG interim meeting as
“What should we identify through an address?” - scope
the work around those answers we believe are most desirable to
avoid the boiling the ocean issue
Do you believe this is a reasonable approach to move forward?
Luigi
_______________________________________________ Int-area mailing
list [email protected]
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing
list [email protected]
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
