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 AAAA
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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
