Subject: [Hipsec] I-D Action:draft-ietf-hip-over-hip-02.txt

From: [email-masked]
Date: Mon, 18 Oct 2010 05:15:05 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Host Identity Protocol Working Group of the IETF.

	Title           : Host Identity Protocol Signaling Message Transport Modes
	Author(s)       : A. Keranen
	Filename        : draft-ietf-hip-over-hip-02.txt
	Pages           : 9
	Date            : 2010-10-18

This document specifies two transport modes for Host Identity
Protocol (HIP) signaling messages that allow conveying them over
encrypted connections initiated with the Host Identity Protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hip-over-hip-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Ari Keranen <[email-masked]>
Date: Mon, 18 Oct 2010 15:29:32 +0300

Hi all,

This updated version addresses all the comments given during the WGLC, 
changes the proposed NOTIFY packet type to avoid clash with taken 
values, updates the IANA section regarding the NOTIFY type, updates the 
security section with short note about security of different ESP 
transforms, and has some editorial fixes. For details, see the diff:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-hip-over-hip-02

Cheers,
Ari

---

From: Tobias Heer <[email-masked]>
Date: Tue, 19 Oct 2010 16:07:36 +0200

Hello Ari,

I read the draft and I have some comments/questions below:

a) In my opinion, there is a good reason why HIP control messages are not encrypted by default. I think this design was chosen to support on-path elements so that they can understand what's going on. Sending HIP control messages over encrypted channel obviously changes this property. I think this should be stated somewhere.

b) Sending HIP control messages over an encrypted channel makes some of the security measures that HIP uses unnecessary. The HMAC might still be needed (because ESP without authentication is deemed insecure). However, the public-key signature of the update seems quite superfluous to me now because it is intended to help on-path verification of packets - which the encryption prevents. Maybe the draft should comment on this? The update signatures is mandatory (according to RFC5201) so it might be an option not to touch it and accept the wasted overhead (although I don't fancy that option).

c) You discuss host mobility but do not mention multihoming is this intended?

d) To me it is not entirely clear how mobility or multihoming would work with the encrypted channels in place. You describe that it can work if it is done before the connection breaks. Would both hosts set up new SA pairs / TCP connections for all of their possible address pairs in order to do the address verification? If yes, the address verification during the update is rather useless for TCP because TCP does its own handshake already. If no, how does it work? Am I missing the point here?

BR, Tobias

Am 18.10.2010 um 14:29 schrieb Ari Keranen:

> Hi all,
> 
> This updated version addresses all the comments given during the WGLC, changes the proposed NOTIFY packet type to avoid clash with taken values, updates the IANA section regarding the NOTIFY type, updates the security section with short note about security of different ESP transforms, and has some editorial fixes. For details, see the diff:
> 
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi

---

From: Ari Keranen <[email-masked]>
Date: Thu, 21 Oct 2010 14:48:53 +0300

Hi Tobi,

Thanks for the review! Comments inline.

On 10/19/2010 05:07 PM, Tobias Heer wrote:
> a) In my opinion, there is a good reason why HIP control messages are
> not encrypted by default. I think this design was chosen to support
> on-path elements so that they can understand what's going on. Sending
> HIP control messages over encrypted channel obviously changes this
> property. I think this should be stated somewhere.

OK, I can add a comment about that.

> b) Sending HIP control messages over an encrypted channel makes some
> of the security measures that HIP uses unnecessary. The HMAC might
> still be needed (because ESP without authentication is deemed
> insecure). However, the public-key signature of the update seems
> quite superfluous to me now because it is intended to help on-path
> verification of packets - which the encryption prevents. Maybe the
> draft should comment on this? The update signatures is mandatory
> (according to RFC5201) so it might be an option not to touch it and
> accept the wasted overhead (although I don't fancy that option).

I would prefer not to modify the HIP protocol itself even if some of the 
features would become redundant. The idea of the ESP transport mode(s) 
was to work as a drop-in replacement for the regular (no encryption) 
mode. Regarding the signature, hosts that are on the encrypted path as 
one of the relaying elements (e.g., in a HIP BONE scenario) could still 
use it for verification since they terminate the ESP tunnels and thus 
see the decrypted HIP packets, right?

> c) You discuss host mobility but do not mention multihoming is this

I did not see any special behavior that would be needed for the 
multihoming case (beyond what is needed for the mobility cases), but 
you're right that making this more explicit makes sense. I changed the 
"Mobility" section's name into "Mobility and Multihoming" and we can add 
more details there if needed (see next question).

> d) To me it is not entirely clear how mobility or multihoming would
> work with the encrypted channels in place. You describe that it can
> work if it is done before the connection breaks. Would both hosts set
> up new SA pairs / TCP connections for all of their possible address
> pairs in order to do the address verification? If yes, the address
> verification during the update is rather useless for TCP because TCP
> does its own handshake already. If no, how does it work? Am I missing
> the point here?

It seems there could be more details on this. The basic idea was "do as 
you used to do but once you're done (with mobility and/or multihoming 
actions) send HIP messages over the new SA". That is, in the TCP mode 
the TCP connection used for the HIP messages should survive just like 
any other TCP connection and in the ESP mode, once there is a new SA, it 
is used for the messages. So new SA pairs would be set for all pairs (as 
before) and there would be no new TCP connections or handshakes but the 
address verification works as it used to.

Cheers,
Ari