Hi Paul, all. Answers for section 6 in line.
> El 18 nov 2018, a las 7:52, Paul Wouters <[email protected]> escribió: > > > > Section 6.1: > > Note that the use of start and end addresses, means that this can never work > with IKEv1, that can only negotiate CIDR networks. Perhaps this should be > explicitely stated somewhere just in case some developer thinks they can > use IKEv1 for this? [Authors] ok, note that the yang element is explicitely named "IKEv2", anyway, we can clarify this point in the document. In fact, we believe that we should proceed with only IKEv2. BTW, we propose to change the model moving from the current "list of TSs including a list of IP addresses and port ranges" for each policy to a list of TSs per policy with one local and remote subnets per TS (instead of "ranges"). What do you think? > > I dont understand the names in: > > next-layer-protocol* ipsec-next-layer-proto > > It talks about ip-address and not ipsec-next-layer-ip-address? Simiarly it > talks about local-ports. So why not just call this proto or protocol ? [Authors] The label "protocol" is widely used in the model. It is just a way to identify the context. > > Is selector-priority needed? Can the ts-number not be specified to be "lower > numer is higher priority” ? [Authors] It could (in fact, it is ordered by user, which means the controller in our case) In fact, RFC4301 only specifies that "An SPD is an ordered list of entries" > > > Why do we have security-protocol? If you are considered about small > footprints, > clearly you would implement only ESP and use ESP-NULL if encryption is not > needed. And simply not implement AH (which is already optional not mandatory > to implement for IPsec). Also, this assumes IPCOMP, which has its own > complexity, > would also not be used. I think a case for AH would be very weak, while a case > for IPCOMP could be made. I'd recommend only supporting ESP, at which point > you would not need this parameter, or you could keep it for completeness > sake even though it could only have one value "esp". This would also allow > an updated ESP or some ESPlite to be used in the future if such a thing would > be developed. [Authors] We agree with only make use of ESP and ESP-NULL. > If we only go with AEAD algorithms, then the whole ah-algorithms part can be > removed too. And esp-algorithms could be changed to only contain > esp-encryption > (or could be renamed aead-algorithm) [Authors] Same as before > > I see spd-mark but not spd-security-context (see my Labeled IPsec draft) [Authors] Regarding the XFRM mark element and the security context described in the draft, if there is a clear use case for these elements we can keep them in the model. > > I found the names in lifetimes confusing. "added" really means maxlife and > "current" really means maxidle I think? So I think the names would be > clearer as "time", "idle", "packets", "bytes". I think the time and idle > units of uint64 could be narrowed down if the yang language allows some > kind of timestamp type. [Authors] We have made use of the terminology in RFC2367, Section 2.3.2. Indeed the yang model has a timestamp (RFC 6991). We can add "time", "idle", "packets" and "bytes”. > > I am missing an entry for TFC (confidentiality, padding) ok, It could be included in the model (for IKE and IKE-less cases. > I also see no entry for IPCOMP algorithm. But I am fine with not allowing > IPCOMP at all :) [Authors] Agree > > I am missing replay window parameters ? Currently, the replay-window parameter is defined only in the SAD configuration for IKE-less case. It should be also included in the SPD configuration for IKE case. Do you think we should include the additional replay-seq, replay-oseq, replay-seq-hi, replay-oseq-hi parameters for IKE-less case? > > I don't know what statefulfragCheck is ? Whether or not to allow IKE fragmentation. (Libreswan/Strongwan support that, valid values are are yes, (the default), no or force). Probably a better name for this? > > Section 6.2 > > See Section 6.1 comments. > > Why are the encap entries in 6.2 and not 6.1 ? [Authors] For case 2 (IKE-less) espencap is configured like part of the SA, not the policy. For IKE case encap is part of the IKEv2 configuration (section 6.4) > > What is the "state?" entry ? [Authors] state is of type sa-state (Larval, Mature, Dying, Dead). These states can be useful when the model is used by the SC to recover SA's state data from the node or when modelling the sadb_expire message > > Why is rpcs: only here? [Authors] You are right, rpcs should be in a 6.5 section. Note that notifications are defined for SAD and SPD in IKE-less case and that there are not notifications for IKE and PAD models > > I would not use minbits, maxbits. All modern ciphers, especially AEAD, are > fixed key sizes. Make it a list of key sizes [Authors] Agree > > I seem to miss the AEAD IV values ? [Authors] This container represents information about the algorithm supported, we assume that AEAD algorithms can be also represented here (AES_GCM, AES_CCM, CHACHA20-POLY1305, ....). IV values are not represented here. > Possibly the truncation values ? [Authors] For auth-trunc values, we will include that in container ah-sa unless AH is finally removed. > > Section 6.3: > > I only see PSK and RSA algorithms? No ECDSA via RFC 7427 Digital Signatures? > (no PAKE, we have two IKE PAKE's although it looks like we want an CFRG new > one) [Authors] See answer in Appendix section. > > Should PSK be of type "string". Some people want to hex entry? Although those > are often written > as strings with a 0x prefix. [Authors] Agree > > I see some CRL entries, but no OCSP entries. Is it expected those URI's are > stored within the certificates, > and the received OCSP responses will never be communicated through this > interface? [Authors] Agree. We can add CRL and OCSP URLs > > I see no local and remote part, meaning that only symmetric authentication > methods can be used. IKEv2 supports > asymmetric authentication methods as well. Especially when using EAP and > sometimes with AUTHHNULL, this method > is very asymmetric. So I believe this entry needs to be split in a > local/remote auth method. [Authors] Agree > > Section 6.4: > > type-autostartup issues... > > typedef type-autostartup { > type enumeration { > enum ALWAYSON { description " ";} > enum INITIATE-ON-DEMAND {description " ";} > enum RESPOND-ONLY {description " ";} > } > description "Different types of how IKEv2 starts the IPsec SAs"; > > With libreswan we have similar keywords, and run into some interesting > issues. We found what is really needed is to > know the current state and the connection desired state. for example, when > using ondemand and the connection is up, > it is important to know it is up because of ondemand. So that when you > receive a Delete request, you can go back > to ondemand state. If you dont keep this state then you cannot tell the > difference between alwayson/ondemand if > the connection is "up". Similarly, we had issues where connections has a > definition like above, but the administrator > performs an action. It is unclear if such an action is considered a temporary > override or basically a runtime update > of the configuration. So lets say we are in respondonly, and the > administrator brings the connection up. Now the other > end sends a delete. Do you assume you are in alwayson state or in ondemand > state? And if you believe alwayson, be > prepared for a war with the remote endpoint that keeps sending deletes > because it wants to be down. [Authors] Do you think this is something the model should consider? We mean that, after all, behing the model we will have an implementation (could be libreswan, strongswan etc.. that it will deal with these aspects) It is true that we should define clearly what ALWAYSON, INITIATE-ON-DEMAND, RESPOND-ONLY, etc… > > > Why is there nat-traversal and espencap. Why not just have espencap allow to > have a value of 'none’ ? [Authors] Agree > IKEv2 allows more then one oaddr (eg multiple SOURCE NAT IPs) but the value > is not a list? [Authors] Agree for the IKE case. For pfkey_v2 (setkey), it does not allow to specify oaddr. For xfrm, it does allow to specify only one oaddr. Does make it sense to allow more than one oaddr for IKE-less case? > > The terms phase1-* should be called ike-* or ike-sa-* as phase1/phase2 is > IKEv1 terminalogy not used for IKEv2. [Authors] Agree. We can replace phase1-* by ike-sa-* and phase2-* by ike-child-sa-*. > > Why is combined-enc-intr needed? These are stored with the encalg entries > anyway. [Authors] Agree. > > I see: > > +--rw local > | +--rw (my-identifier-type)? > > +--rw remote > | +--rw (my-identifier-type)? > > I think "my-identifier-type" should be "identifier-type". Talking about "my" > for the remote peer is very confusing. [Authors] Agree. > > my-identifier-type does not support the value ID_NONE from RFC 7619 [Authors] Agree. We will include that in the model. > > Why is there no secion for ike-lifetime-{soft|hard} ? We also have FIPS > requirements that IKE SA's cannot do more > then X bytes for Y algorithm. And also bringing down idle IKE SA's etc. [Authors] We can include a soft/hard lifetime (seconds) for IKE SA. What does it means a soft/hard lifetime (bytes) for IKE SA. It is implemented in current distributions? > > I think "added", "used", "bytes" "packets" should be called lifetime, > idletime, maxbytes and maxpackets [Authors] See comment above. > > The timestamp values "added" and "used" could have a better type than uint64, > eg unix epoch of unixtime or something? [Authors] Current implementations make use of __u64 or even uint32_t. Anyway, we can modify the type. What do you propose? > > the term ike-stats was confusing me. I thought at first these were the global > IKE statistics, like how many tunnels > are up, how many errors received, but it turned out to be the state of a > singe IKE SA. So perhaps ike-sa-state is a > better term? [Authors] Agree. > IKE state I expect things like SPIi and SPIr as listed here. [Authors] global IKE statictics could be obtained by the SC through the ike-sa-state info for each IKE SA. > > I am not sure why there are three nat-* bools instead of one value > representing the nat-state? Possibly because we > use a number of bits to indicate which of the NAT properties are set, and you > don't do this kind of bit mapping in > yang? > [Authors] That could be represented with uint8 and using three bits , is that what you mean? We thought was clearer to have three booleans. > I dont see an entry for "latest IKE SA". We have that in libreswan. You can > have multiple IKE SA's when rekeying, > and the older one is just lingering to die. Any operations such as > informational requests, dpd/liveness probes > should only be done with the "latest IKE SA". However, this is kind of a > state on the IKE node, so I am not > sure if this belongs in the yang model or not. [Authors] Is there any scenario where the SC is able to deal with this information for the IKE case? If so, we can try to model that like state data. > > I see a total SA's and halfopen SA's but I don't see anything related to > anti-DDOS cookies. Eg the number of half > open SA's before enabling cookies. Perhaps add half-open-cookies-treshhold ? > [Authors] Several parameters can be configured here: - half-open-threshold: number of half open IKE SAs - half-open-cookies-threshold: number of half open IKE SAs with cookie activated - half-open-timer: timeout in seconds for connecting IKE SAs. Best regards, Gabi. > ----------------------------------------------------------- Gabriel López Millán Departamento de Ingeniería de la Información y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: [email protected]
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
