Re: [Hipsec] Iotdir last call review of draft-ietf-hip-dex-11
I do not see anything in this comment that is directly actionable, but will provide some comments here. On 11/25/19 1:38 AM, Michael Richardson via Datatracker wrote: Reviewer: Michael Richardson Review result: Ready I am the assigned IoT-Directorate reviewer for 1draft-ietf-hip-dex I reviewed the -11 version. I did not identify any technical problems or gaps. The introduction tells that I won't understand this without a good understanding of RFC7401 (HIPv2). I went ahead anyway, given that I did know HIPv1 (RFC5201) and IKEv2. While it is clear that I could not implement without knowing 7401, I did find that I could understand most of the goals, the compromises that were made to reduce the complexity for constrained environments. I did go back and read 7401 in the end to fill in a few gaps. Particularly I really needed to understand RFC7343 HITs of the new type, and I did not manage to understand that part. I observe that a new ECDH type of HIT is defined, but I did understand how these values would be exchanged/stored or looked up. Sec 7 HIP Policies: All HIP DEX implementations SHOULD provide for an Access Control List (ACL), representing for which hosts they accept HIP diet exchanges, and the preferred transport format and local lifetimes. Wildcarding SHOULD be supported for such ACLs. There may be other approaches used, but ACLs is a SHOULD. I would appreciate a use case or two which has been sufficiently built-out so that I can see the whole picture. If ECDH HITs come from DNS (via records) for instance, then I'd appreciate an understanding if/how the constrained device is able to leverage DNSSEC. In particular, I'd like to know what kind of applications are ruled out by lack of PFS, and if a kind of PFS can be restored by rotating HITs in DNS. A new Applicability section should help on this. Would this document play well with draft-ietf-ipsecme-implicit-iv? I am unclear if the diet nature of DEX is more about: (1) constrained/challenged networks (2) constrained/slow CPUs (3) systems with very minimal amounts of flash Mostly 2 (see new Applicability section), then 1, and only slightly 3. (1) networks have often very small packet sizes, and I would appreciate understanding the total frame sise of each I1/R1/I2/R2, and any impact that fragment assembly might have on the statelessness of the I1/R1 exchange. Somewhere there are some notes that Rene and I did on minimal packet size. We were over the 140 bytes of SMS for the smallest R2 packets, but everything COULD be done under 200 bytes. Challenge is that variability in parameters can result in larger packets, so any claim in the document would only be on the smallest possible size, not the maximum let alone the likely size. I know that HIP has be profiled for use in 802.15.9, and I assume that HIP DEX is even better, but the lack of PFS might be a show stopper. See the new Applicability section coming in dex-12.txt (2) slow/sleepy CPUs are not going away, but the amount of available flash on rather cheap, small and sleepy devices is now in the multiple megabytes, so it is unclear if further code simplications are worthwhile. It is possible that no more slow CPUs will be shipped, but I doubt that. My questions should not stop the document from advancing. Thank you, Micheal. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Iotdir last call review of draft-ietf-hip-dex-11
Hi, (Robert, please double check if you agree with my comments) su, 2019-11-24 kello 22:38 -0800, Michael Richardson via Datatracker kirjoitti: > Reviewer: Michael Richardson > Review result: Ready > > I am the assigned IoT-Directorate reviewer for 1draft-ietf-hip-dex > I reviewed the -11 version. > > I did not identify any technical problems or gaps. > The introduction tells that I won't understand this without a good > understanding of RFC7401 (HIPv2). I went ahead anyway, given that I > did know > HIPv1 (RFC5201) and IKEv2. > > While it is clear that I could not implement without knowing 7401, I > did find > that I could understand most of the goals, the compromises that were > made to > reduce the complexity for constrained environments. I did go back > and read > 7401 in the end to fill in a few gaps. > > Particularly I really needed to understand RFC7343 HITs of the new > type, and > I did not manage to understand that part. let us know if we should clarify something particular in the DEX draft. > I observe that a new ECDH type of > HIT is defined, but I did understand how these values would be > exchanged/stored or looked up. > I would appreciate a use case or two which has been sufficiently > built-out so > that I can see the whole picture. If ECDH HITs come from DNS (via > > records) for instance, then I'd appreciate an understanding if/how > the > constrained device is able to leverage DNSSEC. not really records, but rather "HI" records, so actually the public key is stored in the DNS as defined in RFC8005. Nothing prevents using DNSSEC except the capabilities of the device. I don't know the footprint of a minimal DNSSEC implementation at the client side... > In particular, I'd like to know what kind of applications are ruled > out by > lack of PFS, this is a rather generic question and I don't know if some researched and created a taxonomy of applications that fit PFS. So I don't really have a good answer for this but just a couple of easy answers: * If the data is of emphemeral nature (useful only at the very present), then PFS may not be necessary. * If the hardware too is too constrained, then non-PFS security is better than no security. > and if a kind of PFS can be restored by rotating HITs in DNS. really interesting, how would this work in practice? (Usually it's just the server's HITs stored in the DNS so perhaps just extra security measure for the server?) > Would this document play well with draft-ietf-ipsecme-implicit-iv? BEX and DEX can be used with any data plane security, but ESP is commonly used, so I don't really see why not. Saving bits on the wire for the data plane in contrained scenarios is always good. Robert what do you think? > I am unclear if the diet nature of DEX is more about: > (1) constrained/challenged networks > (2) constrained/slow CPUs > (3) systems with very minimal amounts of flash I haven't been involved with this work since the beginning, so perhaps Robert should comment on this more but here's my interpretation. I believe the priority is on slow CPUs and flash comes as the second. Network is the last one in the priority list; if you check the origins of the work, for instance, the "Slimfit" approach compresses HIP messages much better. RFC7228 section 3 lists different classes of IoT devices but it's mostly related to the memory dimension. I am not sure if have classifications for the network/CPU dimensions in IETF... > (1) networks have often very small packet sizes, and I would > appreciate > understanding the total frame sise of each I1/R1/I2/R2, and any > impact that > fragment assembly might have on the statelessness of the I1/R1 > exchange. according to Hummen et al, "Slimfit - A HIP DEX Compression Layer for the IP-based Internet of Things", DEX packets sizes were roughly as follows in an earlier version of the draft (draft-moskowitz-hip-dex- 00): I1: 48 bytes R1: ~184 bytes I2 ~232 bytes R2: ~86 bytes > I know that HIP has be profiled for use in 802.15.9, and I assume > that HIP > DEX is even better, but the lack of PFS might be a show stopper. Quoting Eric Vyncke: "I had a conversation with Ben Kaduk today at the hackathon. While Ben had reviewed the DEX document about 2 years ago, he was clear that PFS is a requirement for IETF standard _EXCEPT_ (and this is important): 1) the text is clear that there is no PFS property in DEX 2) there is a justification why PFS was not implemented (such as defining a specific use case)." Regarding to the use case, Robert sent the following text proposal earlier: HIP DEX, by design does not support Perfect Forward Secrecy (PFS). All current PFS approaches use Ephemeral DH, secured and identified in some manner (e.g. SIGMA or PAKE). There are classes of devices, like those based on the 8051 microprocessor where this is prohibitably expensive. Experience with the ZWAVE ZW0500 found that EC25519 key pair generation exceeded 10 seconds with unacceptable battery
[Hipsec] Iotdir last call review of draft-ietf-hip-dex-11
Reviewer: Michael Richardson Review result: Ready I am the assigned IoT-Directorate reviewer for 1draft-ietf-hip-dex I reviewed the -11 version. I did not identify any technical problems or gaps. The introduction tells that I won't understand this without a good understanding of RFC7401 (HIPv2). I went ahead anyway, given that I did know HIPv1 (RFC5201) and IKEv2. While it is clear that I could not implement without knowing 7401, I did find that I could understand most of the goals, the compromises that were made to reduce the complexity for constrained environments. I did go back and read 7401 in the end to fill in a few gaps. Particularly I really needed to understand RFC7343 HITs of the new type, and I did not manage to understand that part. I observe that a new ECDH type of HIT is defined, but I did understand how these values would be exchanged/stored or looked up. I would appreciate a use case or two which has been sufficiently built-out so that I can see the whole picture. If ECDH HITs come from DNS (via records) for instance, then I'd appreciate an understanding if/how the constrained device is able to leverage DNSSEC. In particular, I'd like to know what kind of applications are ruled out by lack of PFS, and if a kind of PFS can be restored by rotating HITs in DNS. Would this document play well with draft-ietf-ipsecme-implicit-iv? I am unclear if the diet nature of DEX is more about: (1) constrained/challenged networks (2) constrained/slow CPUs (3) systems with very minimal amounts of flash (1) networks have often very small packet sizes, and I would appreciate understanding the total frame sise of each I1/R1/I2/R2, and any impact that fragment assembly might have on the statelessness of the I1/R1 exchange. I know that HIP has be profiled for use in 802.15.9, and I assume that HIP DEX is even better, but the lack of PFS might be a show stopper. (2) slow/sleepy CPUs are not going away, but the amount of available flash on rather cheap, small and sleepy devices is now in the multiple megabytes, so it is unclear if further code simplications are worthwhile. My questions should not stop the document from advancing. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
