Subject: [Hipsec] draft-tschofenig-hip-ice-00.txt

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Jun 2007 13:16:16 -0700

This document explains how we see ICE and HIP could work together.  Comments
welcome.

-d

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: Utilizing Interactive Connectivity 
> Establishment (ICE) for the Host Identity Protocol (HIP)
> 	Author(s)	: H. Tschofenig, D. Wing
> 	Filename	: draft-tschofenig-hip-ice-00.txt
> 	Pages		: 22
> 	Date		: 2007-6-22
> 	
> 
>    This document describes how the Interactive Connectivity
>    Establishment (ICE) methodology can be used for the Host Identity
>    Protocol (HIP) to determine whether end-to-end communication is
>    possible.  ICE makes use of the Session Traversal Utilities for NAT
>    (STUN) protocol in addition to mechanisms for checking connectivity
>    between peers.  After running the ICE the two HIP end 
> points will be
>    able to communicate directly or through a relay via Network Address
>    Translators (NATs), Network Address and Port Translators 
> (NAPTs) and
>    firewalls .
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in 
> the body of 
> the message. 
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-tschofenig-hip-ice-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-tschofenig-hip-ice-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Philip Matthews <[email-masked]>
Date: Fri, 22 Jun 2007 21:09:57 -0400

A few questions/comments on this draft:

1) Can you explain in more detail how you see the ICE attributes  
being encoded?

2) Another way to distinguish STUN messages from HIP is by using bit  
31 of the first 32-bit quadword.
      In HIP, this must always be 1.  In STUN, this must always be 0,  
since STUN messages
      must always be a multiple of 4 bytes.

3) It seems  weird to me to use the ufrag stuff of ICE (= a random  
endpoint identifier)
     when HIP already has HITs.

- Philip

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 23 Jun 2007 17:46:10 +0200

Hi Phillip,

Philip Matthews wrote:
> 1) Can you explain in more detail how you see the ICE attributes being 
> encoded?
>
Currently, we went for a really simple approach: We just take the same 
format as in ICE and dump them into an attribute for exchange in HIP. 
Maximum code reuse was the goal. One can obviously change the encoding 
of the attribute.

BUT the encoding of the candidates is not really important thing.

>      must always be a multiple of 4 bytes.
Thanks. We can add that as well.

>     when HIP already has HITs.
Good observation. I have to think about it if it makes sense to change 
that.

Dan will respond to your other mail.

Ciao
Hannes

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 23 Jun 2007 09:25:58 -0700

> Good observation. I have to think about it if it makes sense 
> to change that.

stick the HIT into the USERNAME, then.

-d

---

From: Philip Matthews <[email-masked]>
Date: Sat, 23 Jun 2007 20:32:19 -0400

On 23-Jun-07, at 11:46 , Hannes Tschofenig wrote:

> Currently, we went for a really simple approach: We just take the  
> same format as in ICE and dump them into an attribute for exchange  
> in HIP. Maximum code reuse was the goal. One can obviously change  
> the encoding of the attribute.

Let me make sure I understand what you mean.
Here is the example SDP from section 4.3 of draft-ietf-mmusic-ice-16.txt

        v=0
        o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
        s=
        c=IN IP4 192.0.2.3
        t=0 0
        a=ice-pwd:asd88fgpdd777uzjYhagZg
        a=ice-ufrag:8hhY
        m=audio 45664 RTP/AVP 0
        b=RS:0
        b=RR:0
        a=rtpmap:0 PCMU/8000
        a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
        a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx  
raddr 10.0.1.1 rport 8998

It sounds like your proposed HIP parameter would contain all the  
characters between the quote marks below:
"c=IN IP4 192.0.2.3
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr  
10.0.1.1 rport 8998"
Here I have removed the "v=", "o=", "s=", "t=", and "b=" lines.  Do  
you also remove the "m=" and "c=" lines?
(these play an important role in ICE).

Is this correct?

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Sat, 23 Jun 2007 20:39:30 -0400

> stick the HIT into the USERNAME, then.

That could be a good choice. Each end puts its HIT in the ufrag
(expressed in hex, say), and then the STUN username
would be
	<remote HIT>:<local HIT>

- Philip

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 24 Jun 2007 10:34:35 +0200

Hi Phillip,

Philip Matthews wrote:
>> same format as in ICE and dump them into an attribute for exchange in 
>> HIP. Maximum code reuse was the goal. One can obviously change the 
>> encoding of the attribute.
>
> 10.0.1.1 rport 8998

ICE needs these attributes:
"candidate",
"remote-candidates",
"ice-lite",
"ice-mismatch",
"ice- ufrag",
"ice-pwd"
"ice-options"

Hence, "c=IN IP4 192.0.2.3" and m=audio 45664 RTP/AVP 0" is not needed.

But roughly speaking you are correct.

Ciao
Hannes

---

From: Philip Matthews <[email-masked]>
Date: Sun, 24 Jun 2007 10:17:50 -0400

On 24-Jun-07, at 04:34 , Hannes Tschofenig wrote:

>> Here I have removed the "v=", "o=", "s=", "t=", and "b=" lines.   
>> Do you also remove the "m=" and "c=" lines?

Thanks!
I understand your proposed attribute encoding now.

Another question.
The ICE spec talks a lot about manipulating the m and c lines in the  
SDP. It talks about putting a default candidate into m and c lines,  
how to choose that default candidate, and the need to re-offer if the  
selected valid pair does not match the values in the m and c lines in  
the original offer.

How do you see all this working in ICE-for-HIP?

- Philip

---

From: Miika Komu <[email-masked]>
Date: Mon, 25 Jun 2007 14:42:26 +0300 (EEST)

On Fri, 22 Jun 2007, Dan Wing wrote:

Hi,

seems like the discussion exploded during weekend. Answering to rest of 
the emails after this, but first few overall comments on the draft:

The draft is missing flow graphs which makes it immensily difficult to 
understand how the protocol actually works. Particularly, I am 
interested in seeing all of the following things in flow diagrams:

   * Registration to RVS
   * Relaying of the base exchange through the RVS
   * Reachability detection
   * Handover with reachability detection

After you have unblurred this information to the draft, we can compare the 
RTT between the drafts, which I think is generally larger in 
draft-tschofenig-hip-ice.

I did not understand the state requirements for the RVS after a quick 
read:

  * Does the RVS forward all HIP control packets?
  * Does the RVS impose state towards the Initiator (aka "L")

For draft-ietf-hip-nat-traversal-02-pre6, the answer to the first question 
is "yes" to provide 100 % reliability over legacy NATs. The answer to the 
second question is "no" to avoid DoSing or overloading the RVS server.

-- 
Miika Komu                                       http://www.iki.fi/miika/

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Jun 2007 13:50:04 +0200

Hi Miika,

as with NAT traversal in SIP the traversal over RVS and the registration 
at the RVS is not subject to the draft. That's a different problem.

Ciao
Hannes

Miika Komu wrote:
> seems like the discussion exploded during weekend. Answering to rest 
> of the emails after this, but first few overall comments on the draft:
>
> After you have unblurred this information to the draft, we can compare 
> the RTT between the drafts, which I think is generally larger in 
> For draft-ietf-hip-nat-traversal-02-pre6, the answer to the first 
> question is "yes" to provide 100 % reliability over legacy NATs. The 
> answer to the second question is "no" to avoid DoSing or overloading 
> the RVS server.
>

---

From: Miika Komu <[email-masked]>
Date: Mon, 25 Jun 2007 15:01:17 +0300 (EEST)

On Mon, 25 Jun 2007, Hannes Tschofenig wrote:

Hannes,

I did not understand your comment. The draft talks about rendezvous 
servers and even illustrates it in the Figure 1. Are you using STUN to 
relay HIP control packets?

There were actually six questions in my email, each one separated into 
a bullet point. Please answer to each of them separately.

> Hi Miika,
>
> as with NAT traversal in SIP the traversal over RVS and the registration at 
> the RVS is not subject to the draft. That's a different problem.
>
> Ciao
> Hannes
>
> Miika Komu wrote:
>> seems like the discussion exploded during weekend. Answering to rest of the 
>> emails after this, but first few overall comments on the draft:
>> 
>> understand how the protocol actually works. Particularly, I am interested 
>> in seeing all of the following things in flow diagrams:
>>
>>   * Registration to RVS
>> I did not understand the state requirements for the RVS after a quick read:
>>