> -Original Message-
> From: Valery Smyslov
> Sent: Thursday, July 30, 2020 4:07 AM
> To: Scott Fluhrer (sfluhrer) ; 'Michael Rossberg'
>
> Cc: 'ipsecme mailing list'
> Subject: RE: [IPsec] Teaser for pitch talk at IETF 108
>
> Hi Scott
Hi Scott,
> > > Actually, it does add value from a crypto point of view, at least from a
> > specific attack. In a multitarget attack, that is, an attack where we
> > assume
> > that the attacker has encrypted packets from a large number of SAs, and his
> > goal is to recover the keys for any on
Scott Fluhrer \(sfluhrer\) writes:
> No, RFC4106 (June 2005) predated 800-38D (November 2007) by over two years.
Ah, didn't check the dates, and the NIST document didn't really
explain the reason behind it, it just said you preferrably need to
have 32-bit fixed part.
> Instead, it was inserted to
> -Original Message-
> From: Michael Rossberg
> Sent: Wednesday, July 29, 2020 2:35 PM
> To: Scott Fluhrer (sfluhrer)
> Cc: ipsecme mailing list
> Subject: Re: [IPsec] Teaser for pitch talk at IETF 108
>
> >
> > Actually, it does add value from a cryp
> -Original Message-
> From: IPsec On Behalf Of Tero Kivinen
> Sent: Wednesday, July 29, 2020 2:30 PM
> To: Michael Rossberg
> Cc: Steffen Klassert ; ipsec@ietf.org; Valery
>
> > Like written already: An unpredictable value of 32bit size is of no
> > real value from a crypto point of vie
>
> Actually, it does add value from a crypto point of view, at least from a
> specific attack. In a multitarget attack, that is, an attack where we assume
> that the attacker has encrypted packets from a large number of SAs, and his
> goal is to recover the keys for any one of the encrypted p
Michael Rossberg writes:
> Like pointed out in the answer to Valery’s mail. There are possibly more
> issues, as attackers are able to generate new traffic, they can use for
> cryptanalysis (see
> https://www.aircrack-ng.org/doku.php?id=arp-request_reinjection).
If any of our algorithms are vulner
> -Original Message-
> From: IPsec On Behalf Of Michael Rossberg
> Sent: Wednesday, July 29, 2020 12:10 PM
> To: Tero Kivinen
> Cc: Steffen Klassert ; ipsec@ietf.org; Valery
> Smyslov
> Subject: Re: [IPsec] Teaser for pitch talk at IETF 108
>
>
> >>
>> We have already the option to send the high sequence number bits
>> when a combined mode algorithm is used.
>>
>> RFC 4303, Section 2.2.1. says:
>>
>> If a combined mode algorithm is employed, the algorithm choice determines
>> whether the high-order ESN bits are transmitted or are included i
>>
>> We have been analyzing issues ESP has in current data-center networks and
>> came to
>> the conclusion that changes in the protocol could significantly improve its
>> behavior. Some
>> of results will be presented next Tuesday in a pitch talk at IETF 108. This
>> mail is just a
>> small t
On Wed, Jul 29, 2020 at 04:22:15PM +0300, Tero Kivinen wrote:
> Steffen Klassert writes:
> >
> > A secret salt in the nonce would be a new requirement anyway.
> > I've checked RFC 4106 (ESP for GCM) and RFC 7634 (ESP for
> > ChaCha20-Poly1305), both don't require a secret salt.
>
> It is true tha
Steffen Klassert writes:
> We have already the option to send the high sequence number bits
> when a combined mode algorithm is used.
>
> RFC 4303, Section 2.2.1. says:
>
> If a combined mode algorithm is employed, the algorithm choice determines
> whether the high-order ESN bits are transmitted
Hi Valery,
a few comments inline.
On Tue, Jul 28, 2020 at 11:13:33AM +0300, Valery Smyslov wrote:
> Hi,
>
> a few thoughts about this proposal.
>
> > * 64 bit sequence counters in each header to ease protocol handling and
> > allow for
> > replay protection in multicast groups
Hi Michael,
> > The advantage of multiple SAs is that you don’t really need to change the
> > other side of the IPsec connection
> (especially if the peer already supports 6311). So if you have 30 cluster
> members, or 30 CPUs, or 30 virtual
> LANs, or 30 QoS classes, you can generate 30 SAs ra
>> @William: The 16-bit sender ID is something we already get from protocols
>> like GDOI to do IV space
>> partitioning (details in https://tools.ietf.org/html/rfc6054). So the
>> mistake is already there.
> My memory was 8 bits, ludicrously small. Reading more carefully, they
> illustrated 8 b
>>> RFC 6311 allows multiple members in a cluster of IPsec gateways to have
>>> independent parallel SAs so as to solve the problem of synchronization and
>>> counter re-use among nodes.
>>>
>>> While the focus there is on different nodes, the synchronization problem
>>> also exists between co
Hi,
> @William: The 16-bit sender ID is something we already get from protocols
> like GDOI to do IV space
> partitioning (details in https://tools.ietf.org/html/rfc6054). So the mistake
> is already there.
RFC 6054 doesn't limit the number of SID bits to 16, it only says that 8, 12
and 16 bit
Hi,
a few thoughts about this proposal.
> We have been analyzing issues ESP has in current data-center networks and
> came to
> the conclusion that changes in the protocol could significantly improve its
> behavior. Some
> of results will be presented next Tuesday in a pitch talk at IETF 108. T
On 7/24/20 4:42 PM, Michael Rossberg wrote:
@William: The 16-bit sender ID is something we already get from protocols like
GDOI to do IV space
partitioning (details in https://tools.ietf.org/html/rfc6054). So the mistake
is already there.
My memory was 8 bits, ludicrously small. Reading more
> On 24 Jul 2020, at 23:42, Michael Rossberg
> wrote:
>
> Wiliam, Yoav,
>
> thanks for the comments, I’ll try to elaborate in a single mail as you are
> heading in a similar direction.
>
>> RFC 6311 allows multiple members in a cluster of IPsec gateways to have
>> independent parallel SAs
Wiliam, Yoav,
thanks for the comments, I’ll try to elaborate in a single mail as you are
heading in a similar direction.
> RFC 6311 allows multiple members in a cluster of IPsec gateways to have
> independent parallel SAs so as to solve the problem of synchronization and
> counter re-use among
Hi, Michael.
Thanks for bringing this to the group.
> On 22 Jul 2020, at 13:26, Michael Rossberg
> wrote:
>
>
> We have been analyzing issues ESP has in current data-center networks and
> came to
> the conclusion that changes in the protocol could significantly improve its
> behavior. Some
I was forwarded this message. As a matter of fact, I've never left the list,
but very rarely read it.
Speaking as one of the original designers of ESP, I'm delighted that folks
are finally catching up to our original design of 25+ years ago!
There's no need to rename ESP. The Security Paramete
23 matches
Mail list logo
