[Gen-art] Re: Gen-ART HIP drafts (base and esp) review

[Petri Jokela <[e-mail]>]

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

[e-mail] 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art