Subject: [rtcweb] host identity protocol

From: Miika Komu <[email-masked]>
Date: Thu, 08 Mar 2012 10:51:00 +0200

Dear WG,

I heard that you're making progress and have selected a specific 
protocol approach for rtcweb:

http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel

This is good news indeed. However, we noticed that the original 
comparison was missing few approaches like Teredo (RFC4380) or Host 
Identity Protocol (see e.g. RFC5770):

http://tools.ietf.org/html/draft-jesup-rtcweb-data

Despite the original document missed the two protocols, I'm sure that 
they were was discussed at some point, maybe even just in face-to-face 
conversations. Now, my goal is not advocate either of these protocols as 
a replacement for the WG as you have already consensus, but I'd rather 
like to get feedback why some protocols were excluded.

To be more specific, we're working on a research paper on deployment 
analysis on Host Identity Protocol (HIP) in Aalto University and we'd 
like get your expert opinion on especially why HIP was not the adopted 
in the context of rtcweb. Here's few example considerations:

- Never heard about HIP
- The substitute technologies do their work better
- Lack of implementation maturity or usability
- Not standards track yet; we can build rtcweb out of standards track 
components
- The fatal flaw for HIP in this particular context is X
- HIP is in the wrong layer of the stack?

Besides technical incentives, we're also interested business and 
political incentives. Feel free to respond me directly or via the 
mailing list (unless people think it's too off-the-topic). Your feedback 
will be anonymized in the publication.

Thanks!

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 08 Mar 2012 11:16:13 +0100

HIP was discussed at a far earlier stage, when talking about security. 
We chose to go with DTLS, SRTP and ICE instead, since these were 
mechanisms in (relatively) common use in this environment.

As far as I understand HIP, it does not contain congestion control 
mechanisms, so its use was not considered when picking a protocol for 
the data channel.

On 03/08/2012 09:51 AM, Miika Komu wrote:
> conversations. Now, my goal is not advocate either of these protocols 
> as a replacement for the WG as you have already consensus, but I'd 
> rather like to get feedback why some protocols were excluded.
>
> mailing list (unless people think it's too off-the-topic). Your 
> feedback will be anonymized in the publication.
>
> Thanks!
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Miika Komu <[email-masked]>
Date: Thu, 08 Mar 2012 19:08:18 +0200

Hi Harald,

thanks for the quick response. You're absolutely right, HIP does not 
support congestion control. It actually even shouldn't support it 
because it's not a transport-layer protocol. Typically people use 
HIP/IPsec for end-to-end tunneling of TCP or UDP. The tunnel is 
encrusted in an extra UDP header to make HIP/ESP pass NAT boxes which 
actually makes it a nice fit for NAT penetration. The data-plane can be 
negotiated during the key exchange process and e.g. S-RTP has been 
proposed to replace IPsec.

Are you sure about the reasoning - has it been a misunderstanding or 
maybe some other reasoning fits better? Thanks for your feedback!

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 08 Mar 2012 19:07:39 +0100

On 03/08/2012 06:08 PM, Miika Komu wrote:
> actually makes it a nice fit for NAT penetration. The data-plane can 
> be negotiated during the key exchange process and e.g. S-RTP has been 
The last discussion was in september/october 2011. Please review the 
archives.

---

From: Miika Komu <[email-masked]>
Date: Thu, 08 Mar 2012 20:50:47 +0200

Hi Harald,

> The last discussion was in september/october 2011. Please review the

I went through the archives and it appears that there was no technical 
reason for excluding HIP:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg01679.html

So, it just appears that there was only one person suggesting HIP, i.e., 
the reason was the lack of contributors. Technically, it appears that 
the WG decision was based on an incomplete analysis of the solution 
space though (but, that's life).

Nevertheless, I'm sure that you'll find inventive uses for SCTP 
associations in the context web - I wish you the very best luck in your 
endeavors!