Subject: [Hipsec] draft-keranen-hip-over-hip-00

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 9 Feb 2010 09:08:31 -0800

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Ari Keranen
> Sent: Tuesday, January 26, 2010 6:40 AM
> To: HIP
> Subject: [Hipsec] [Fwd: New Version Notification
> fordraft-keranen-hip-over-hip-00]
>
> Hi all,
>
> In addition to updating the HIP BONE drafts, we wrote a new draft [1]
> about conveying HIP messages over the ESP tunnels. This is something
> that is especially useful in overlay scenarios, and has actually been
> already discussed in multiple places before, but never really
> specified.
> Comments are welcome.
>
>
> Cheers,
> Ari
>
> [1] http://www.ietf.org/id/draft-keranen-hip-over-hip-00.txt

Hi Ari,

I had a few questions on the above draft.

1) I wonder about a dependency in requiring HIP to use ESP (the "MUST" in section 3.2) if HIP is also responsible for setting up or repairing ESP itself.  Should there be a possibility of falling back to HIP outside of the ESP envelope in failure cases?  Another failure case is that the initiator or responder fails to set up the TCP sockets as described.

2) previously in RFC5201, we adopted the convention that the roles of Initiator and Responder are abandoned once the base exchange completes, so this would require implementations to keep that state around (might require some comment here or in 5201bis).

3) (Linux question) regarding HIP over ESP, will XFRM process the packet entering/leaving on a raw socket (both for IPv4 and IPv6)?  Am wondering how easy it will be to implement this option on current systems, using kernel ESP implementations.  Should HIP over UDP over ESP (possibly over UDP again) be an option, for ease of programming?

4) Have you thought about SCTP instead of TCP for this use case?

- Tom

---

From: Ari Keranen <[email-masked]>
Date: Wed, 10 Feb 2010 14:10:48 +0200

Hi Tom,

Thanks for the comments! Responses inline.

>> -----Original Message-----
[...]
> 1) I wonder about a dependency in requiring HIP to use ESP (the
> "MUST" in section 3.2) if HIP is also responsible for setting up or
> repairing ESP itself.  Should there be a possibility of falling back
> to HIP outside of the ESP envelope in failure cases?  Another failure
> case is that the initiator or responder fails to set up the TCP
> sockets as described.

Good point. Failure and mobility scenarios are not yet specified in this 
initial version, but I'll add text about them to the next revision.

AFAIK, unless one of the hosts dies and we need a new BEX anyway, the 
ESP tunnel should break only in case of break-before-make mobility or 
failed re-keying. In these cases one could send the required UPDATE 
outside of the ESP tunnel.

> 2) previously in RFC5201, we adopted the convention that the roles of
> Initiator and Responder are abandoned once the base exchange
> completes, so this would require implementations to keep that state
> around (might require some comment here or in 5201bis).

With the ESP mode you don't need this information, so I assume you are 
referring to the ESP-TCP mode where the Initiator initiates also the TCP 
connection, right? Although even in this case the information is needed 
only right after the BEX.

If you think it would be beneficial to not require keeping this 
information (even for such a short period of time), we could define that 
the host with lower HIT value starts the TCP connection. Actually, if we 
want to support negotiation of the transport mode after the BEX using 
UPDATEs, this would be a good idea.

> 3) (Linux question) regarding HIP over ESP, will XFRM process the
> packet entering/leaving on a raw socket (both for IPv4 and IPv6)?  Am
> wondering how easy it will be to implement this option on current
> systems, using kernel ESP implementations.  Should HIP over UDP over
> ESP (possibly over UDP again) be an option, for ease of programming?

At least on Linux and IPv4 this seems to work if you don't use the 
IP_HDRINCL option and specify some protocol (say, 139) when creating the 
socket and give the same protocol to the IPsec policy. Haven't tested 
this with IPv6 yet.

Does anyone have any experience on other platforms with raw sockets and 
ESP? A UDP mode would make the protocol stack look a bit funny, but 
surely that's not a show stopper if it's needed on some platforms. And I 
guess one could use the TCP mode in these cases too.

> 4) Have you thought about SCTP instead of TCP for this use case?

Not really, but I don't see much benefit of using SCTP instead of TCP in 
this scenario (e.g., we have already framing thanks to HIP header, HOL 
blocking doesn't sound like a probable scenario, DoS protection is 
provided by HIP). And since TCP is still much more widely supported, 
using that for fragmentation handling seems like a good idea. Or am I 
missing something?

That said, having SCTP as one extra mode would fit well into the 
specification.

Cheers,
Ari

---

From: Ari Keranen <[email-masked]>
Date: Wed, 10 Feb 2010 14:43:44 +0200

Hi,

Dacheng Zhang wrote:
> I have a superficial question here. A HIP host needs to use Update a packet
> to inform its partner that its IP address has been changed. However, if the
> update packet is transported using ESP, will it be difficult for the partner
> to find out the proper IPsec AS to decrpt the packet and get the update
> information?

This should not be a problem. The ESP packet with the UPDATE still 
contains the same SPI value which the peer can use for finding the 
correct IPsec SA (only destination address and SPI value are needed for 
making the match).

However, if both hosts move at the same time, one would need to fall 
back to using HIP without ESP. I'll add text about this to the next 
revision of the draft.

Cheers,
Ari

---

From: Miika Komu <[email-masked]>
Date: Wed, 10 Feb 2010 14:50:28 +0200

On 02/10/2010 02:10 PM, Ari Keranen wrote:

Hi,

> outside of the ESP tunnel.

agree.

> UPDATEs, this would be a good idea.

Bigger HIT would align well with the NAT traversal draft.

> guess one could use the TCP mode in these cases too.

No experience. The ESP-over-UDP case has to work for deployment 
scenarios with legacy NATs and somebody should really try this.

> That said, having SCTP as one extra mode would fit well into the

SCTP can be added later if needed. Btw, the multihoming support from 
SCTP inside the ESP tunnel seems unnecessary.

Few other questions that came into my mind:

* One potential use case for HIP inside TCP are the certificates which 
can fragment. Perhaps this could be mentioned in the draft and you could 
cite Samu's cert draft.
* The draft has a dependency to ESP transform. One must be negotiated or 
otherwise the extensions in the draft do not apply. I think Initiator 
MUST not send HIP_TRANSPORT_MODE with mode 1/2 transform when the 
Responder has excluded ESP transform in R1.

---

From: Ari Keranen <[email-masked]>
Date: Wed, 10 Feb 2010 18:34:58 +0200

Hi,

> Bigger HIT would align well with the NAT traversal draft.

True. I changed this so that the one with the larger HIT is the 
"Responder" (i.e., the one waiting for the connection). Also, I added 
the possibility to negotiate new mode after BEX using UPDATEs and a mode 
(called DEFAULT) for changing back to what ever was used during the BEX.

> SCTP inside the ESP tunnel seems unnecessary.

Agree.

> can fragment. Perhaps this could be mentioned in the draft and you could 

True, I'll add this and some text on when to choose each mode. Also the 
HICCUPS DATA messages are a potential candidate for the TCP mode.

> Responder has excluded ESP transform in R1.

Good point; I'll fix this too.

Thanks,
Ari

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 11 Feb 2010 08:51:44 -0800

> UPDATEs, this would be a good idea.

Yes, I was referring to ESP-TCP mode.  Your suggestion about the lower HIT value seems fine to me.

> That said, having SCTP as one extra mode would fit well into the

I was thinking initially that SEQPACKET might offer slightly better semantics than STREAM to this application, but having read the sctp API draft just now, I'm not sure that the work to deconflict the SCTP multihoming from HIP multihoming is worth it (i.e. you would have to provide some explicit guidelines on how to use the SCTP API, where TCP is pretty clear cut to developers).

- Tom

---

From: Ari Keranen <[email-masked]>
Date: Fri, 12 Feb 2010 14:28:57 +0200

Henderson, Thomas R wrote:
>>> completes, so this would require implementations to keep that
>>> state around (might require some comment here or in 5201bis).
>> With the ESP mode you don't need this information, so I assume you
>> are referring to the ESP-TCP mode where the Initiator initiates 
>> also the TCP connection, right? Although even in this case the
>> information is needed only right after the BEX.
>> 
>> information (even for such a short period of time), we could define
>> that the host with lower HIT value starts the TCP connection. 
>> Actually, if we want to support negotiation of the transport mode
>> after the BEX using UPDATEs, this would be a good idea.
> 

OK, great. This will be included in the next revision.

>> Not really, but I don't see much benefit of using SCTP instead of
>> TCP in this scenario (e.g., we have already framing thanks to HIP 
>> header, HOL blocking doesn't sound like a probable scenario, DoS
>> protection is provided by HIP). And since TCP is still much more
>> widely supported, using that for fragmentation handling seems like
>> a good idea. Or am I missing something?
>> 
> I was thinking initially that SEQPACKET might offer slightly better
> semantics than STREAM to this application, but having read the sctp
> API draft just now, I'm not sure that the work to deconflict the SCTP
> multihoming from HIP multihoming is worth it (i.e. you would have to
> provide some explicit guidelines on how to use the SCTP API, where
> TCP is pretty clear cut to developers).

OK. Then I think it makes sense to leave SCTP out of the draft, at least 
for the time being. Thanks for the analysis!

Cheers,
Ari