Re: [IPsec] Comments on draft-ietf-lwig-minimal-esp-00
Thanks Scott for the comment. I will address them tomorrow, I am just sharing the review to the lwig list. Yours, Daniel On Sun, Jul 21, 2019 at 8:17 PM Scott Fluhrer (sfluhrer) wrote: > Comments: > > > >- I have issues with the draft’s emphasis on fixed SPI values. One >reason for the SPI value is to handle key updates cleanly; during the >transition, the SPI can be used to indicate whether the packet was >encrypted with the previous set of key or the new ones. As we really don’t >want to discourage rekeying I would suggest that, instead of talking so >much about fixed SPIs, you instead address how to do nonrandom SPIs (for >example, by having the top 3 bytes of the inbound SPI being the SAD entry, >and the lower byte being the rekey index). >- “Values 0-255 SHOULD NOT be used.”; shouldn’t that be MUST NOT? Can >you think of an advantage a device might have for using a SPI in that >region? > > The use of fix SPI MUST NOT be considered as a way to avoid strong random > generators. Such generator will be required in order to provide strong > cryptographic protection”; actually, if the IPsec implementation doesn’t > actually generate its own keys (that is, it relies on an external service > to provide them), and the transform itself doesn’t require random data (CBC > can be implemented securely without one), then the IPsec implementation > doesn’t actually need an CSPRNG. > >- SN based on clocks; one issue that is not addressed is that standard >receivers are tuned for an increment of one-per-packet; if the sender uses >increments significantly larger than that, and packets are reordered, the >receiver is more likely to reject valid packets because they fell outside >the window. >- One issue you do not address (but I believe you should) is the fact >that some cryptographical transforms are more resilient for key reuse (e.g. >because you use a fixed key, and don’t change it after a reboot) than >others. In particular, both GCM and ChaCha20-Poly1305 have real problems >when that happens, and should be avoided. > > > > Typos: > >- a random SPI may consume to much -> too much >- fix SPI -> fixed SPI >- can be alleviate -> can be alleviated >- algorythm -> algorithm >- > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Comments on draft-ietf-lwig-minimal-esp-00
Comments: * I have issues with the draft's emphasis on fixed SPI values. One reason for the SPI value is to handle key updates cleanly; during the transition, the SPI can be used to indicate whether the packet was encrypted with the previous set of key or the new ones. As we really don't want to discourage rekeying I would suggest that, instead of talking so much about fixed SPIs, you instead address how to do nonrandom SPIs (for example, by having the top 3 bytes of the inbound SPI being the SAD entry, and the lower byte being the rekey index). * "Values 0-255 SHOULD NOT be used."; shouldn't that be MUST NOT? Can you think of an advantage a device might have for using a SPI in that region? The use of fix SPI MUST NOT be considered as a way to avoid strong random generators. Such generator will be required in order to provide strong cryptographic protection"; actually, if the IPsec implementation doesn't actually generate its own keys (that is, it relies on an external service to provide them), and the transform itself doesn't require random data (CBC can be implemented securely without one), then the IPsec implementation doesn't actually need an CSPRNG. * SN based on clocks; one issue that is not addressed is that standard receivers are tuned for an increment of one-per-packet; if the sender uses increments significantly larger than that, and packets are reordered, the receiver is more likely to reject valid packets because they fell outside the window. * One issue you do not address (but I believe you should) is the fact that some cryptographical transforms are more resilient for key reuse (e.g. because you use a fixed key, and don't change it after a reboot) than others. In particular, both GCM and ChaCha20-Poly1305 have real problems when that happens, and should be avoided. Typos: * a random SPI may consume to much -> too much * fix SPI -> fixed SPI * can be alleviate -> can be alleviated * algorythm -> algorithm * ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Milestones changed for ipsecme WG
Changed milestone "IETF Last Call on Split-DNS Configuration for IKEv2", added draft-ietf-ipsecme-split-dns to milestone. Changed milestone "IETF Last Call on Implicit IV in IPsec", resolved as "Done", added draft-ietf-ipsecme-implicit-iv to milestone. Changed milestone "IETF Last Call on partially quantum resistant IKEv2", resolved as "Done", added draft-ietf-ipsecme-qr-ikev2 to milestone. URL: https://datatracker.ietf.org/wg/ipsecme/about/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Hi Yoav,
Hi, Valery
[no hats]
Thanks for that.
I think this demonstrates that the current document is not enough and we will
need some follow-up documents explaining when to use either case.
I don’t think it’s very useful for the controller to distribute a policy (SPD
entries) but no SAs (SAD entries) in the IKE-less case. It makes sense in the
IKE case because the NSFs can then use IKE to generate the SAs, but in the
IKE-less case that would mean that one NSF gets a packet that should be
protected, sends a message to the controller, which generates an SA and sends
it to both the requester and the other NSF. This seems high latency.
I think the case for IKE-less is where the controller sends SPD entries and SAD
entries at the same time (perhaps later updating the SAD entries to rekey). In
that case the action of the controller is to bring up a tunnel. For example,
if the user (or application) decides that communications between node A and
node B should be encrypted, the controller will send both policy and keys at
the same time to make that tunnel.
Sure that will make things more static and the concerns expressed in
my message will gone.
However, other concerns appear in this case. First, you'll lose some
of ipsec functionality -
an ability to have per-connection IPsec SA, when each TCP connection
is protected with
its own SA (don't ask me when I last time saw this in real life,
please :-)). Then, in this
case a situation is possible when (some of) installed SAs are never
used. You preinstall
them regardless of the traffic, and traffic can never happen. Not
that it is a big deal,
but still...
Regards,
Valery.
Yoav
On 20 Jul 2019, at 10:38, Valery Smyslov mailto:smyslov.i...@gmail.com> > wrote:
Hi,
thank you for updating the document. I still think that some aspect
of IKE-less use case are not discussed yet (well, probably they are not
"serious", depending on one's definition of "serious").
Unlike IKE case. which we can consider as mostly static configuration,
the IKE-less case is a dynamic one. If IPsec SA are being created
on demand (via kernel-acquire) and the traffic volume is high,
then depending on the IPsec policy IKE-less case can become
a highly dynamic, which implies additional requirement on both
the network connecting SC and NSF and the performance of the protocol used to
secure their communications. In other words, in IKE case the communication
between IKE daemon and kernel is seamless, while in IKE-less
case the communication between NSF ("kernel") and SC adds
noticeable delay (and can potentially add quite a long delay),
which can influence total performance of the system.
Generally IKE-less case requires more communications between
different nodes to establish or rekey IPsec SA, than IKE case
(I assume that IKE SA is already established), that may have
an impact on high-speed networks with short-lived IPsec SAs,
especially if they are created per transport connection
(say one IPsec SA for one TCP session).
I believe, that SC's task of managing IPsec SAs in IKE-less case
may become quite complex, especially because due to the
additional delay, introduced by the network, the picture of the
state of the SAs the SC has can become inaccurate (well,
it will always be inaccurate, but with short delays it doesn't matter).
Just an example. Consider an SC receives a signal from NSF that an SA
is soft expired and starts rekeying process by first installing a new
pair of inbound SAs. It successfully installs them on the NSF
it receives notification from, but then it receives a notification
that the other NSF has rebooted, so it must clear all the SAs on
its peers, including the just installed new one (which is only
half-done). There seems to be a lot of nuances, and the document
completely ignores them. Not that I think that the task
is impossible, but the algorithm of managing the SAs can become
quite complex and possibly unreliable.
I didn't find this discussion in the draft (sorry if I missed it).
Regards,
Valery.
Thanks for getting this done and published.
We will wait with requesting publication until the I2NSF session next week.
Between now and then, please re-read the draft and send a message to the list
is something is seriously wrong.
Barring any such shouting, we will request publication right after the meeting.
Thanks again,
Linda and Yoav
On 16 Jul 2019, at 15:42, Rafa Marin-Lopez < r...@um.es>
wrote:
Dear all:
We submitted a new version of the I-D (v05) where we have applied several
changes. In the following you have a summary of the main changes, which we will
expand/explain during our presentation:
- We have dealt with YANG doctors’ review (Martin's)
- We have dealt with Paul Wouters’
