Hello David,
thanks for the review! I have made some editions to the drafts and
include the most important changes below.
Current versions of both drafts (marked with pre191206) are available at
http://hip4inter.net/drafts.php
with diffs to previous versions.
BR, Petri
[EMAIL PROTECTED] wrote:
<draft-ietf-hip-base-06.txt>
Section 5.1.3 indicates a reliance of HIP on IP fragmentation. IP
fragmentation is becoming increasingly troublesome, so this will
be a problem in practice. The corresponding reliance on IP
fragmentation for IKE is a known cause of problems with certificates,
as the size of some certificates is a common cause of IP fragmentation
with UDP/IP. At a minimum, this section should carry a strong
recommendation that the separately-specified HIP support for
certificates support Hash & URL certificate formats in order to
avoid certificate sizes that will cause IP fragmentation. Certificates
are a major cause of IP fragmentation in IKE, particularly when chains
are involved.
I added a paragraph, similar to the one in IKE:
Because certificate chains can cause the packet to be fragmented and
fragmentation can open implementation to denial of service attacks
[37], it is strongly recommended that the separate document
specifying the certificate usage in HIP Base Exchange defines the
usage of "Hash and URL" formats rather than including certificates in
exchanges. With this, most problems related to DoS attacks with
fragmentation can be avoided.
The text in Section 5.3.2 on Diffie-Hellman value reuse could use
some clarification. The underlying issue is that the HIP exchange
does not use the nonces that IKE and IKEv2 use, which makes DH
value reuse significantly more dangerous. The current text says
that DH values SHOULD not be reused unless the system is under attack
(I1 storms), in which case they MAY be reused. This appears to drop
the level of security in response to an attack, which may not be the
best course of action. I don't want to say that HIP ought to use
IKE-like nonces, but this text appears to need some more thought.
Section 5.3.3 doesn't discuss DH value reuse. It should.
We discussed this and decided to add a note about the issue and a strong
recommendation that in the future versions of HIP this is revisited:
Re-using D-H value can open security holes. When future
versions of HIP are specified, it is strongly recommended
that these possible security issues are investigated.
Section 5.3.6 and Section 6.13 need more precision on the sorts of
"state information changes" that SHOULD NOT be made as a consequence
of receiving a NOTIFY packet.
The text is unclear and it should refer to changes in HIP State machine,
not to other state information. The text has been clarified.
Section 6.5 needs to specify how to calculate the Diffie-Hellman
Kij value.
Clarification in the text: the Kij is the value is the shared secret
received as a result of D-H.
<draft-ietf-hip-esp-04.txt>
Nit: Section 3.3.5, change "AES" to "AES-CBC" in two places.
There are AES modes other than CBC defined for use with ESP.
Ok!
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
