[Hipsec] New version of RFC5201-bis (05)

[Tobias Heer <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello everyone!

Here is a new version of RFC5201-bis (draft-ietf-hip-rfc5201-bis-05).

http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-05



A praise to former and future reviewers
- ---------------------------------------

There are quite many changes thanks to the detailed reviews of Miika Komu, Jeff
Ahrenholz, and Ari Keranen. I have received an enormous amount of good,
detailed, and valid feedback on issues that are new in the bis document and even
more comments on issues that we inherited from RFC5201. I would like to express
my gratitude and respect for these three guys. They have done a great job.
*APPLAUSE*

Again, I'd like to encourage people to review the document. I am especially
interested in the opinion of a) implementers and b) people who defined
extensions for HIP. It would be good to see if your HIP extensions still work
with the new changes or if something fundamentally breaks your extension .  

I've gone over the security considerations section again. Some text in
there seemed to have accumulated over the time while RFC5201 was still in the
making and did not seem fully fitting today. I also changed the proposed
defense mechanism for I2 flooding attacks. I would be happy if someone could go
over it thoroughly with a second pair of eyes.



Changes that are tricky to spot:
- -------------------------------

In this version are some things that are incompatible to RFC5201 but are
difficult to spot. These are mostly redefinitions of already existing
parameters. I'll highlight these changes here:

a) The HOST_ID format has changed to accommodate ECC HIs. This leads to a
different parameter format.

b) The SEQ and ACK descriptions have changed. There was a bug in the figures.
This leads to a different parameter format if the figure was chosen as basis for
the implementation.

c) There may be several NOTIFY parameters per packet. This was not forbidden
before but is explicitly allowed now. This change was made to allow signaling
for multiple problems in a HIP control packet.

d) The document now says the puzzle K SHOULD be 0 if the Responder is not under
high load. Please make sure that HIP implementations set the K to 0 if they
have no good reason to raise the value. Higher values of K will only slow down
HIP, burn CPU cycles and energy, and serve no purpose if there is no overload
condition.

e) The HIP_SIGNATURE Algorithm field is now 16 bits long (it was 8 bits long
before). Now the field is better aligned with the HOST_ID algorithm field.

These changes are also mentioned in the Changelog section.


Full change log:
- ----------------

See the changelog below:

11.1.  Changes from draft-ietf-hip-rfc5201-bis-04

  o  Moved this list farther to the back.

  o  Clarifications of the Security Considerations section.  One DoS
     defense mechanism was changed to be more effective and less prone
     to misuse.

  o  Minor clarifications of the state machine.

  o  Clarified text on HIP puzzle.

  o  Added names and references for figures.

  o  Extended the definitions section.

  o  Added a reference to the HIP Version 1 certificate document.

  o  Added Initiator, Responder, HIP association, and signed data to
     the definitions section.

  o  Changed parameter figure for PUZZLE and SOLUTION to use
     RHASH_len/8 instead of n-byte.

  o  Replaced occurrences of SHOULD not with SHOULD NOT.

  o  Changed text to reflect the fact that several
     ECHO_REQUEST_UNSIGNED parameters may be present in an R1 and
     several ECHO_RESPONSE parameters may be present in an I2.

  o  Added text on verifying the ECHO_RESPONSE_SIGNED parameter in
     CLOSE_ACK.

  o  Changed wording from HMAC to HIP_MAC in Section 5.3.8.

  o  Reflected fact that the UPDATE packet MAY include zero or more
     ACKs.

  o  Added BEX to Definitions section.

  o  Changed HIP_SIGNATURE algorithm field from 8 bit to 16 bit to
     achieve alignment with the HOST_ID parameters.

  o  Fixed the wrong figures of the SEQ and ACK parameters.  SEQ always
     contains ONE update ID.  ACK may acknowledge SEVERAL update IDs.

  o  Added wording that several NOTIFY parameters may be present in a
     HIP packet.

  o  Changed wording for the ECHO_RESPONSE_SIGNED parameter.  Also
     lifted the restriction that only one ECHO_RESPONSE_UNSIGNED
     parameter MUST be present in each HIP control packet.  This did
     contradict the definition of the ECHO_RESPONSE_UNSIGNED parameter.

  o  Changed IETF Consensus to IETF Review in IANA section.

  o  Aligned use of I, J, and K. Now I is #I, J is #J and K is #K
     throughout the document.

  o  Updated references.

  o  Editorial changes.



- -- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: [phone]
web: http://www.comsys.rwth-aachen.de/team/tobias-heer/
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi
pgp id: AEECA5BF 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)

iEYEARECAAYFAk19ywEACgkQf4eSaa7spb86XwCdFuBZICHktgVg6NmijiW8PQoU
fqIAnjNgww7Kt4DCpXCnF5Nk7ByIRgtu
=JR47
-----END PGP SIGNATURE-----