On Wed, 29 May 2019, Rafa Marin Lopez wrote:
Please see some additional comments inline:
[Authors] We understand. In the IKE-less case we do not have this kind of
"configured but not up” state. We assume that once the SC configures the NSF
with the IPsec SA, the NSF will apply the configuration right way without waiting
anything else.
In IKE case it is possible to define this with the type-autostartup (on-demand)
by adding your text to the description. However, I was thinking that, actually,
this is a general security policy that should be applied in both iKE-case and
IKE-less and, even, when the NSF starts in the network and there is no contact
with the NSF.
Perhaps the best place to mention this is in the Security Considerations
section. Then, we can add in the model the text you mention. We could include
this paragraph in Security Considerations (the general part not specific to any
case):
“For security reasons, a NSF MUST NOT allow any traffic unless the Security
Controller mandates so. In other words, since the NSF needs IPsec information coming
from the SC, if that information is not in place yet the safest option is DISCARD
(drop) packets."
I assume there are two types of deployment, "cleartext but encrypt when
possible" and "encryption mandatory". So I feel the MUST NOT is a bit
too strong. Perhaps limit it to say "if encryption is mandatory for
all traffic of an NSF, its default policy MUST be to drop packets to
prevent cleartext packet leaks".
But then you also do not need per-tunnel "drop" policies, so the SC does
not have to instruct the NSF for anything.
This one did not get answered. Do you plan to link to the protocol
registry at IANA ?
[Authors] Our approach so far will be similar to the one we found in RFC 8519.
There they use a type uint8 and give a description and preference. More
specifically:
leaf protocol {
type uint8;
description
"Internet Protocol number. Refers to the protocol of the
payload. In IPv6, this field is known as 'next-header',
and if extension headers are present, the protocol is
present in the 'upper-layer' header.";
reference
"
RFC 791
: Internet Protocol
RFC 8200
: Internet Protocol, Version 6 (IPv6) Specification.";
}
Therefore, we would like to add something a uint8 and referring to IANA
registry. Is this approach acceptable for you?
Sounds good.
We will take also the same approach for crypto-algs so far in order to see if
this is valid for yang-doctors' review
Okay.
[Authors] According to RFC 4301 - 4.4.2.1. Data Items in the SAD:
Sequence Counter Overflow: a flag indicating whether overflow of
the sequence number counter should generate an auditable event and
prevent transmission of additional packets on the SA, or whether
rollover is permitted. The audit log entry for this event SHOULD
include the SPI value, current date/time, Local Address, Remote
Address, and the selectors from the relevant SAD entry.
Hmm, I have never heard of this so I should look into it, but I guess it
means you should have the option for it, but please default it to not
allow rollover, and it would need to forbid rollover for AEAD’s.
[Authors] We have included this in the description:
"The flag indicating whether overflow of the sequence number counter should
prevent
transmission of additional packets on the IPsec SA (FALSE), or whether rollover
is permitted (TRUE). If Authenticated Encryption with Associated Data (AEAD) is
used this flag MUST BE false.”;
Okay, good.
With these, I think you resolved all my outstanding issues I had.
Thanks!
Paul
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
