Subject: [Hipsec-rg] draft meeting minutes from last week's meeting
From: [email-masked] (Henderson, Thomas R)
Date: Tue Mar 28 12:24:01 2006

Please review and make corrections to the list; I will upload in another
week or so.  Meeting materials are available at the IETF meeting
materials site, and will be converted for the proceedings site.

Thanks,
Tom

HIP-RG meeting minutes, Mar. 24, 2006, Dallas (IETF 65)

Overview
--------
The HIP RG met on Mar. 24, 2006, from 1130 to 1400 (after IETF 65
meeting).  Tom Henderson and Andrei Gurtov chaired the meeting.
33 people signed the pink sheets.

The meeting reviewed a number of updated Internet Drafts on the topics
of HIP privacy extensions, opportunistic HIP and TCP options, SIP and
HIP relationships, advanced NAT traversal, and the RG experiment report.
The meeting also reviewed the status of the three open source HIP
implementations, and observed a few software demonstrations.

The meeting generated a few action items.
i) add "related IETF work" section to the experiment report (Tom H.,
with Pekka N. input)
ii) Tom to discuss with Hannes Tschofenig and Gonzalo Camarillo about
creating a SIP framework draft.
iii) Hannes to consider whether to rework the PATH draft along
the lines of NAT detection techniques, as other aspects of the draft
have moved to WG scope.

Agenda
------

1.  Administrative and agenda discussion
- draft-irtf-hiprg-nat-01.txt status and IRTF review process

2.  Drafts

Experiment report status
- draft-irtf-hip-experiment-02.txt (update)

Opportunistic mode with TCP option
- draft-lindqvist-hip-opportunistic-01.txt (update)

Host Identity Protocol Location Privacy Extensions
- draft-matos-hip-privacy-extensions-01.txt (update)

SIP and HIP
- draft-tschofenig-hiprg-hip-srtp-02.txt (update)
- draft-tschofenig-hiprg-host-identities-03.txt (update)

Advanced NAT/middlebox traversal; problem statement
- draft-tschofenig-hiprg-hip-natfw-traversal-04.txt (update)

Legacy NAT/middlebox traversal
- draft-nikander-hip-path-01.txt (update)

3.  Software

Status update of experimental implementations, and demos
- HIP for inter.net (SPINAT demo)
- InfraHIP (HIP-enabled firewall management interface)
- OpenHIP (multi-platform)

Detailed minutes (compiled by Tom Henderson and Miika Komu)
-----------------
There were no comments on the agenda.

1. Tom reviewed the HIP experiment report, which was revised prior
to the meeting by Andrei and Tom.  Pekka Nikander commented that
it would help to have an additional section on the related work
ongoing in the IETF, such as shim6.  Tom agreed to this.

2.  Janne Lindqvist presented a draft on opportunistic HIP;
specifically,
the inclusion of HIP I1 packet as a TCP option.  This would allow
a non-HIP-aware host to fall back immediately to TCP.  The main
update of this draft was to remove the TCP piggybacking approach
(discussed at last RG meeting).
(Pekka Nikander) thinking of a gross hack; combine this with using
TCP to drill through NATs.  Can use a certain TCP port for HIP traffic.
(Andrew McGregor): similar to Skype (mentioned some specific port
number tracking technique that Skype uses)
(Lars Eggert):  Does not work for UDP connections.  Problems with
the NAT case; the R1 may not make it back.  Security issue: with HIP
you don't see the port numbers, but now you reveal it.
(Hannes Tschofenig): The last concern is not severe but should be
documented.
(Tom Henderson):  This depends on your privacy policies; for some
use cases, it may matter, but for others (such as when application
or user only cares about trying HIP but allows fall back to vanilla
TCP) it may not matter.
(Lars): It should be clear (for the user) that this is running with
lowered security.

3.  Alfredo Matos presented the update to the HIP privacy extensions
draft.
(Lars):  Can use an ethernet flooding algorithm for HIT-based routing
in the access network?  Curious as to what are your problems with HIPL
code?
(Alfredo): implementation troubles, moving to userspace broken the code.
Using HITs in normal interfaces.
(Miika Komu): should work also in the userspace code. We will follow-up
offline.
(Lars): Note, this is different from how RVS currently works.  It does
not relay the complete base exchange.  The first version of the RVS
draft offered complete relaying.
(Hannes): yes, this was supported in the draft to pass symmetric NATs
(Pekka): be aware that there may be some reflection attacks possible
with
your approach (RVS is a reflection attack point). You may have to
balance
the privacy issues with the security issues.
(Tom): Why do you need HIT-based routing?  Could you write your draft
to be agnostic of this choice (access network routing)?  It seems that
this draft might be a specific instance of the advanced NAT/middlebox
traversal, and might be further developed as such in the future
(perhaps combined with SPINAT).
(Tom):  Have you considered relation of your work to Hi3?
(Alfredo): we had a look on the Hi3 but not from the viewpoint of
privacy
(Andrew): IS-IS could be used for your HIT-based routing. It is scalable
and doesn't run on top of IP.
(Tom):  Another issue this draft raises is looking at the
issues when completely relaying the base exchange through RVS.
(Lars): we need to revise the RVS stuff either in WG or RG

4.  Hannes Tschofenig presented updates of two of the SIP drafts.
(Hannes):  The material on the benefits of SIP+HIP have been removed
from the draft that focuses on specification.
(Tom):  That could be moved to the experiment report.  We have
discussed (also with Gonzalo Camarillo) about preparing a SIP framework
document, and then developing the SIP host identities draft and SRTP
drafts as separate specification drafts.
(Andrei Gurtov):  What implementation are you using? Is it public?
(Hannes): using Boeing (openhip). Have to think about publication
due to corporate policies.
(Pekka): when will -02 version of SRTP be available?
(Hannes): shortly after the IETF
(Tom): As summary, we have two specification-oriented drafts (using SIP
to carry host identities, and SRTP).  The other (future) draft is the
planned SIP framework document. Hannes can be used as a contact
point for interested parties.

5.  Hannes next presented a revision of the Advanced NAT/Firewall
traversal problem statement draft.  He commented that most of the
updates
were from very detailed review by Pekka Nikander.
(Tom):  Again, it may be nice to pair this draft (problem statement)
with a future version of Alfredo's draft that is a specific instance
of advanced NAT (SPINAT) techniques.

6.  Hannes presented the PATH NAT traversal draft, and noted the
duplication of work by other authors (draft presented at HIP WG).
(Pekka):  As I said before, the previous version of this draft had a lot
of problems.  Move the draft more to the direction of the WG draft.
The new (schmitt) draft is more practical but limited in the sense of
NAT
detection.
(Lars): tried to implement based on PATH, but was not successful, so
decided
to start fresh document.
(Pekka): this is a RG so we don't need to have rough consensus. So it is
OK to do different work than in WG.
(Tom):  The PATH draft is more advanced in two areas than the schmitt
draft:
i) considers NAT detection techniques, and more advanced scenarios
(server
behind NAT).  Did WG agree to pick up these issues?
(Pekka): WG agreed to look at more advanced scenarios for NAT traversal
than are in the current schmitt draft.
(Tom):  Is there anything that is HIP-specific about NAT detection?  Do
we want to have a HIP document for that, or just reuse other WG products
here?
(Pekka): Not sure for now, but maybe existing ones are very SIP
oriented.
We can make a recommendation at the WG on what to use in practice.
Here we can consider other options.
(Andrew): use STUN, it works.
(Miika): Would like to see RG work on NAT detection.
(Tom): Hannes, are you interrested in carrying such a draft forward (on
NAT detection)?
(Hannes): Will think about it.

7.  Software status review.
(Lars): Will release a patch to openhip soon for the "client behind a
NAT" case, and are interworking with HIPL implementation for NAT
traversal.
(Pekka):  Are you logging the hits to your HIP test server?
(Tom):  No, but agree that would be useful data.

8.  Three demonstrations were next performed and explained:
i) SPI-NAT.  Patrik Salmela and Petri Jokela (HIP4Internet project)
demonstrated traversal of a video client from a public Internet (v6)=20
location to behind a NAT that replaced private addresses with public
v6 address.  The client moved to a (NATted) IPv4 address, and then the
NAT performed IPv4 to IPv6 translation.
ii) Janne Lindqvist and Miika Komu (HIPL project) demonstrated a=20
web-based GUI for configuring an advanced firewall that used HITs in
the ACL lists.
iii) OpenHIP.  Tom demonstrated HIP for Windows installation process
and user GUI, and interoperation between Windows XP and Mac OS X.

From: [email-masked] (Andrei Gurtov)
Date: Thu Mar 23 19:35:00 2006
Subject: [Hipsec-rg] meeting at 11:30 on Friday
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_courier-10009-1143160710-0001-2
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Petri Jokela wrote:

> Andrei Gurtov wrote:
>
>> For preparing demos, Tom has suggested that people involved would 
>> meet on Thu for dinner after the IAB meeting.
>
>
> Ok, sounds good!
>
Let's meet at 19:45 in the hotel lobby.

Andrei

--=_courier-10009-1143160710-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_courier-10009-1143160710-0001-2--

From: [email-masked] (Henderson, Thomas R)
Date: Thu Mar 23 18:22:01 2006
Subject: [Hipsec-rg] reminder:  HIPRG start time is 1130
Message-ID: <[email-masked]>

Agenda is posted at:
http://www3.ietf.org/proceedings/06mar/agenda/HIPRG.txt

From: [email-masked] (Petri Jokela)
Date: Thu Mar 23 09:14:01 2006
Subject: [Hipsec-rg] meeting at 11:30 on Friday
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Andrei Gurtov wrote:

> For preparing demos, Tom has suggested that people involved would meet 
> on Thu for dinner after the IAB meeting.

Ok, sounds good!

> Tom will show slides on the OpenHIP implementation status. Was it so 
> that Miika can present HIPL status and Patrik HIPE?

We don't have (yet) slides about our implementation status, but we'll 
make some.

/petri

From: [email-masked] (Miika Komu)
Date: Tue Mar 21 17:46:01 2006
Subject: [Hipsec-rg] meeting at 11:30 on Friday
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

---559023410-851401618-1142975203=:10181
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 21 Mar 2006, Andrei Gurtov wrote:

> Unfortunately the hotel can give us the room only until 14:00 so we
> suggest to start the meeting earlier at 11:30 on Fri.

You should probly make the information available on the web and notice
board as well.

> For preparing demos, Tom has suggested that people involved would meet
> on Thu for dinner after the IAB meeting.

Ok.

> Tom will show slides on the OpenHIP implementation status. Was it so
> that Miika can present HIPL status and Patrik HIPE?

Fine. My slides attached.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/
---559023410-851401618-1142975203=:10181
Content-Type: APPLICATION/PDF; name="hip-ietf65-rg.pdf"
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: attachment; filename="hip-ietf65-rg.pdf"

---559023410-851401618-1142975203=:10181--

From: [email-masked] (Andrei Gurtov)
Date: Tue Mar 21 14:14:01 2006
Subject: [Hipsec-rg] meeting at 11:30 on Friday
Message-ID: <[email-masked]>

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_courier-10476-1142968606-0001-2
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Unfortunately the hotel can give us the room only until 14:00 so we 
suggest to start the meeting earlier at 11:30 on Fri.

Could the presenters please send slides to Tom and myself now?

For preparing demos, Tom has suggested that people involved would meet 
on Thu for dinner after the IAB meeting.

Tom will show slides on the OpenHIP implementation status. Was it so 
that Miika can present HIPL status and Patrik HIPE?

Andrei

--=_courier-10476-1142968606-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_courier-10476-1142968606-0001-2--

From: [email-masked] (Henderson, Thomas R)
Date: Fri Mar 17 16:49:01 2006
Subject: [Hipsec-rg] draft meeting agenda for HIPRG
Message-ID: <[email-masked]>

All, this is what we have so far for next Friday's meeting-- please let
me know if you request any changes, and I will announce any updates to
the list and make sure it appears on the IETF agenda page as well.

Thanks,
Tom

HIPRG agenda (draft)
Friday, March 24, 2006, 1230-1500, Monet meeting room
------

1.  Administrative and agenda discussion
- draft-irtf-hiprg-nat-01.txt status and IRTF review process

2.  Drafts

Experiment report status
- draft-irtf-hip-experiment-02.txt (update)

Opportunistic mode with TCP option
- draft-lindqvist-hip-opportunistic-01.txt (update)

Host Identity Protocol Location Privacy Extensions
- draft-matos-hip-privacy-extensions-01.txt (update)

SIP and HIP
- draft-tschofenig-hiprg-hip-srtp-02.txt (update)
- draft-tschofenig-hiprg-host-identities-03.txt (update)

Legacy NAT traversal (only if not addressed in WG meeting)
- draft-schmitt-hip-nat-traversal-00 (new)
- draft-nikander-hip-path-01.txt (update)

Advanced NAT/middlebox traversal; problem statement =20
- draft-tschofenig-hiprg-hip-natfw-traversal-04.txt (update)

3.  Software

Status update of experimental implementations, and demos
- HIP for inter.net (SPINAT demo)
- InfraHIP (HIP-enabled firewall management interface)
- OpenHIP (TBD)

From: [email-masked] (Alfredo Matos)
Date: Tue Mar 14 05:02:00 2006
Subject: [Hipsec-rg] I-D ACTION:draft-matos-hip-privacy-extensions-01.txt
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.
--------------080203030808090704020501
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Dear all,

We have submitted a revision of draft-matos-hip-privacy-extensions.
Diffs from version 00 are at:

http://hng.av.it.pt/~alfmatos/files/draft-matos-hip-privacy-extensions-01-htmlwdiff.html

Comments are appreciated.

Best Regards,

Alfredo Matos

-------- Original Message --------
Subject: I-D ACTION:draft-matos-hip-privacy-extensions-01.txt
Date: Thu, 09 Mar 2006 15:50:01 -0500
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Host Identity Protocol Location Privacy Extensions
	Author(s)	: A. Matos, et al.
	Filename	: draft-matos-hip-privacy-extensions-01.txt
	Pages		: 36
	Date		: 2006-3-9
	
This memo describes a framework for the Host Identity Protocol that
provides location privacy and mobility to end hosts.  It discusses
the introduction of a new functional entity that prevents HIP enabled
nodes from revealing their location.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-matos-hip-privacy-extensions-01.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-matos-hip-privacy-extensions-01.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-matos-hip-privacy-extensions-01.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.

--------------080203030808090704020501
Content-Type: Message/External-body;
 name="draft-matos-hip-privacy-extensions-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-matos-hip-privacy-extensions-01.txt"

Content-Type: text/plain
Content-ID: <[email-masked]>

--------------080203030808090704020501
Content-Type: text/plain;
 name="file:///tmp/nsmail.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="file:///tmp/nsmail.asc"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------------080203030808090704020501--

From: [email-masked] (Janne Lindqvist)
Date: Sat Mar 11 11:14:00 2006
Subject: [Hipsec-rg] Opportunistic Mode with TCP Option
Message-ID: <[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

         Title           : Establishing Host Identity Protocol
 			  Opportunistic Mode with TCP Option
         Author(s)       : J. Lindqvist
         Filename        : draft-lindqvist-hip-opportunistic-01.txt
         Pages           : 13
         Date            : 2006-3-6

    This document specifies an alternative opportunistic mode for the
    Host Identity Protocol (HIP).  The opportunistic mode is initialized
    by adding a 128 bit Host Identity Tag (HIT) as a TCP option to a TCP
    SYN packet.  The mode allows a TCP connection to be established
    directly without a timeout delay in the case the peer does not
    support HIP.

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

The draft was simplified by removing the piggybacking alternative. Also,
an open issues section was added. A student has started to implement this 
approach in the InfraHIP project at TKK.

-- 
Janne Lindqvist

From: [email-masked] (raul rodriguez)
Date: Wed Mar  8 12:32:02 2006
Subject: [Hipsec-rg] One question
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

------=_Part_5218_12033173.1141839222625
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

That s perfect. I hadn t seen that drafts.

Cheers Miika.

Raul Rodriguez

2006/3/8, Miika Komu <[email-masked]>:
>
> On Mon, 6 Mar 2006, raul rodriguez wrote:
>
> > I am a computer engineering student from Barcelona, Spain.
> > I am doing my final project(Dissertation) about HIP, I have already rea=
d
> all
> > the drafts and some more information that I have found. I would like to
> ask
> > you if you could tell me where exactly are the best places(scopes,
> > environment) to use HIP??. I know is better in places with mobility or
> > multihoming hosts, but could you tell me some examples??. Or it can be
> > applied wherever??
>
> Have you browsed all of the documents from:
>
> http://www.openhip.org/irtf/wiki/index.php?title=3DDocuments
> http://infrahip.hiit.fi/publications.html
>
> and perhaps especially these ones:
>
> http://infrahip.hiit.fi/papers/hip_applications.pdf
> http://www.ietf.org/internet-drafts/draft-irtf-hip-experiment-02.txt
>
> --
> Miika Komu              [email-masked]          http://www.iki.fi/miika/
>

------=_Part_5218_12033173.1141839222625
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>That s perfect. I hadn t seen that drafts.</div>
<div>&nbsp;</div>
<div>Cheers Miika.</div>
<div>&nbsp;</div>
<div>Raul Rodriguez<br><br>&nbsp;</div>
<div><span class=3D"gmail_quote">2006/3/8, Miika Komu &lt;<a href=3D"mailto=
:[email-masked]">[email-masked]</a>&gt;:</span>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Mon, 6 Mar 2006, raul rodrigu=
ez wrote:<br><br>&gt; I am a computer engineering student from Barcelona, S=
pain.
<br>&gt; I am doing my final project(Dissertation) about HIP, I have alread=
y read all<br>&gt; the drafts and some more information that I have found. =
I would like to ask<br>&gt; you if you could tell me where exactly are the =
best places(scopes,
<br>&gt; environment) to use HIP??. I know is better in places with mobilit=
y or<br>&gt; multihoming hosts, but could you tell me some examples??. Or i=
t can be<br>&gt; applied wherever??<br><br>Have you browsed all of the docu=
ments from:
<br><br><a href=3D"http://www.openhip.org/irtf/wiki/index.php?title=3DDocum=
ents">http://www.openhip.org/irtf/wiki/index.php?title=3DDocuments</a><br><=
a href=3D"http://infrahip.hiit.fi/publications.html">http://infrahip.hiit.f=
i/publications.html
</a><br><br>and perhaps especially these ones:<br><br><a href=3D"http://inf=
rahip.hiit.fi/papers/hip_applications.pdf">http://infrahip.hiit.fi/papers/h=
ip_applications.pdf</a><br><a href=3D"http://www.ietf.org/internet-drafts/d=
raft-irtf-hip-experiment-02.txt">
http://www.ietf.org/internet-drafts/draft-irtf-hip-experiment-02.txt</a><br=
><br>--<br>Miika Komu&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"mailto:[email-masked]">[email-masked]<=
/a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"h=
ttp://www.iki.fi/miika/">http://www.iki.fi/miika/
</a><br></blockquote></div><br>

------=_Part_5218_12033173.1141839222625--

From: [email-masked] (Miika Komu)
Date: Wed Mar  8 05:29:02 2006
Subject: [Hipsec-rg] One question
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 6 Mar 2006, raul rodriguez wrote:

> I am a computer engineering student from Barcelona, Spain.
> I am doing my final project(Dissertation) about HIP, I have already read all
> the drafts and some more information that I have found. I would like to ask
> you if you could tell me where exactly are the best places(scopes,
> environment) to use HIP??. I know is better in places with mobility or
> multihoming hosts, but could you tell me some examples??. Or it can be
> applied wherever??

Have you browsed all of the documents from:

http://www.openhip.org/irtf/wiki/index.php?title=Documents
http://infrahip.hiit.fi/publications.html

and perhaps especially these ones:

http://infrahip.hiit.fi/papers/hip_applications.pdf
http://www.ietf.org/internet-drafts/draft-irtf-hip-experiment-02.txt

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

From: [email-masked] (raul rodriguez)
Date: Mon Mar  6 05:23:01 2006
Subject: [Hipsec-rg] One question
Message-ID: <[email-masked]>

------=_Part_2442_7794860.1141640646556
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

 Hi guys,

I am a computer engineering student from Barcelona, Spain.
I am doing my final project(Dissertation) about HIP, I have already read al=
l
the drafts and some more information that I have found. I would like to ask
you if you could tell me where exactly are the best places(scopes,
environment) to use HIP??. I know is better in places with mobility or
multihoming hosts, but could you tell me some examples??. Or it can be
applied wherever??

Thanks a lot

Raul Rodriguez

------=_Part_2442_7794860.1141640646556
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>
<div>Hi guys,</div>
<div>&nbsp;</div>
<div>I am a computer engineering student from Barcelona, Spain.</div>
<div>I am doing my final project(Dissertation) about HIP, I have already re=
ad all the drafts and some more information that I have found. I would like=
 to ask you if you could tell me where exactly are the best places(scopes, =
environment) to use HIP??. I know is better in places with mobility or mult=
ihoming hosts, but could you tell me some examples??. Or it can be applied =
wherever??
</div>
<div>&nbsp;</div>
<div>Thanks a lot</div>
<div>&nbsp;</div>
<div>Raul Rodriguez</div><font color=3D"#000000"></font></div>

------=_Part_2442_7794860.1141640646556--

From: [email-masked] (Pekka Nikander)
Date: Thu Mar  2 23:38:00 2006
Subject: [Hipsec-rg] RE: feedback from draft-hip-applications-02
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Miika,

Thanks for your thoughtful comments!

>> The term LSI is not described in ESP or BEET drafts, yet we found  
>> few undocumented problems/features related to LSI and the drafts.  
>> I have discussed with Jan and Petri, and agreed on not documenting  
>> the LSI problems on ESP and BEET drafts as they seemed not to  
>> belong there. I think your draft perhaps fits best the problems.
>>
>> The first problem with LSIs is related to IPv4-IPv6  
>> interoperability. Consider a server application (or two server  
>> applications) that binds both to an LSI and HIT at the application  
>> layer.

This double-binding should not be allowed.  If there are two apps,  
the second binding attempt should fail with EISCONN or a similar  
error.  If there is only one app, then the situation is slightly  
trickier since there exist legacy server apps that want to separately  
bind IPv4 and IPv6 socks for the same server port.  In that case I  
would advice for a hack that allows the double binding but directs  
all incoming connections to the IPv6 sock.

>> The LSI and HIT point to the same public key. In this case, the  
>> networking stack of the server host is
>> pretty dumbfounded upon receiving an BEET ESP packet and trying to  
>> determine which socket (LSI or HIT based) to deliver the data to.

I think the rule above should be sufficient to disambiguate the  
situation.

>> There are two choices to overcome the first problem. Either you  
>> prefer some inner family (like IPv6) or you allow only one binding  
>> for the public key in the specific protocol port.

As I argued above, both of these might be OK, depending of the  
situation.

>> Jan convinced me that the latter alternative sounds better, just  
>> in case we want to make a recommendation on which way to go.

See above.

>> The second problem with use LSIs is that the underlying  
>> implementation has to manipulate transport layer checksums to be  
>> calculated based on LSIs. This is vaguely mentioned in either BEET  
>> or ESP drafts, and it is mostly an implementation issue. I don't  
>> know if you would want to describe also this in more detail in the  
>> apps draft as it is not really described anywhere decently.
>
> My understanding is that transport layer checksums are always computed
> using HITs and IPv6 pseudoheader, regardless of whether LSIs are  
> used at
> the socket API.

I agree with Tom.  This is a no-issue.

>> The third problem is about referrals, a topic which you slightly  
>> touch in the draft also. The idea is that for legacy environments,  
>> HITs are bad as referrals because there is no guarantee that they  
>> can be mapped to locators. LSIs are also bad because they are not  
>> valid outside of the host and cannot be used as referrals at all.

As argued in draft-laganier-ipv6-khi-01.txt, the plan is to  
eventually make HITs "routable", or at least universally mappable to  
locators.  This is a topic of active research, as you know.

>> As a consequence, it seems like opportunistic HIP is perhaps the  
>> best way of dealing with legacy environments as it does not  
>> require any infrastructure and it can also support referrels  
>> better. The
>> reason why it can support referrals better is that opportunistic  
>> HIP can be  implemented
>> based on IP addresses at the application layer (for example,  
>> connect(IP)).  IP addresses, in turn, seem to be the best kind of  
>> referrals for legacy systems as they work also with hosts that do  
>> not support HIP.
>
> I am not willing to go so far as to say that legacy apps require
> opportunistic HIP.  It depends on the use case and application  
> (whether
> it makes referrals, whether the user cares if so, etc.).

I agree with Tom.

> Anyway, I think that we discuss this issue sufficiently without  
> making a
> recommendation on whether to use LSI/HITs or not-- do you have a
> specific text change proposal?

I don't think we really can make a recommendation; what is best  
depends on so many aspects.  If you would like to propose qualitative  
or quantitative text on the trade-offs, that would be excellent.

>> Passing an IP address as a referral can be made also mobility  
>> resistant, if you pass
>> a RVS address instead of an address of an end-host.
>
> But we're talking about referrals to non-HIP hosts, right?  (RVS
> forwards only the base exchange).

There seems to be some lurking issues w.r.t. RVSses, legacy,  
opportunistic HIP etc.

Please propose text.

--Pekka

From: [email-masked] (Henderson, Thomas R)
Date: Thu Mar  2 18:33:00 2006
Subject: [Hipsec-rg] RE: feedback from draft-hip-applications-02
Message-ID: <[email-masked]>

=20

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]]=20
> Sent: Thursday, March 02, 2006 7:50 AM
> To: Henderson, Thomas R
> Subject: feedback from draft-hip-applications-02
>=20
> Nice to have the HIP legacy apps draft back alive again. I=20
> was missing it
> already :) May I ask you what has been actually changed in=20
> the draft since
> 01?

Very little has changed-- the reference to the KHI draft has been added.

>=20
> I have also three comments/ideas/problems related to LSIs and=20
> referrals.
> Perhaps you can add the directly to the next version of apps draft or
> invoke discussion on the RG mailing list. The thoughts in=20
> this email are
> based on discussions with a number of people.
>=20
> The term LSI is not described in ESP or BEET drafts, yet we found few
> undocumented problems/features related to LSI and the drafts. I have
> discussed with Jan and Petri, and agreed on not documenting the LSI
> problems on ESP and BEET drafts as they seemed not to belong there. I
> think your draft perhaps fits best the problems.
>=20
> The first problem with LSIs is related to IPv4-IPv6 interoperability.
> Consider a server application (or two server applications)=20
> that binds both
> to an LSI and HIT at the application layer. The LSI and HIT=20
> point to the
> same public key. In this case, the networking stack of the=20
> server host is
> pretty dumbfounded upon receiving an BEET ESP packet and trying to
> determine which socket (LSI or HIT based) to deliver the data=20
> to. The root
> of the problem is that BEET mode packets do not carry any the inner IP
> header and therefore it is impossible to determine the=20
> ultimate recipient
> of the data.
>=20
> There are two choices to overcome the first problem. Either you prefer
> some inner family (like IPv6) or you allow only one binding=20
> for the public
> key in the specific protocol port.  Jan convinced me that the latter
> alternative sounds better, just in case we want to make a=20
> recommendation
> on which way to go.

Another way to possibly handle this is to tag the mbuf with the address
family of the outer header, and use this information if the conflict
arises further up the stack.

>=20
> The second problem with use LSIs is that the underlying=20
> implementation has
> to manipulate transport layer checksums to be calculated=20
> based on LSIs.
> This is vaguely mentioned in either BEET or ESP drafts, and=20
> it is mostly
> an implementation issue. I don't know if you would want to=20
> describe also
> this in more detail in the apps draft as it is not really described
> anywhere decently.

My understanding is that transport layer checksums are always computed
using HITs and IPv6 pseudoheader, regardless of whether LSIs are used at
the socket API.

>=20
> The third problem is about referrals, a topic which you=20
> slightly touch in
> the draft also. The idea is that for legacy environments,=20
> HITs are bad as
> referrals because there is no guarantee that they can be mapped to
> locators. LSIs are also bad because they are not valid=20
> outside of the host
> and cannot be used as referrals at all.
>
> As a consequence, it seems like opportunistic HIP is perhaps=20
> the best way
> of dealing with legacy environments as it does not require any
> infrastructure and it can also support referrels better. The=20
> reason why it
> can support referrals better is that opportunistic HIP can be=20
> implemented
> based on IP addresses at the application layer (for example,=20
> connect(IP)).
> IP addresses, in turn, seem to be the best kind of referrals=20
> for legacy
> systems as they work also with hosts that do not support HIP.=20

I am not willing to go so far as to say that legacy apps require
opportunistic HIP.  It depends on the use case and application (whether
it makes referrals, whether the user cares if so, etc.).

Anyway, I think that we discuss this issue sufficiently without making a
recommendation on whether to use LSI/HITs or not-- do you have a
specific text change proposal?

> Passing an
> IP address as a referral can be made also mobility resistant,=20
> if you pass
> a RVS address instead of an address of an end-host.
>=20

But we're talking about referrals to non-HIP hosts, right?  (RVS
forwards only the base exchange).

Tom

From: [email-masked] (Henderson, Thomas R)
Date: Thu Mar  2 17:15:01 2006
Subject: [Hipsec-rg] RE: [Hipsec] Start re-chartering discussion in Vancouver?
Message-ID: <[email-masked]>

=20

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]]=20
> Sent: Wednesday, February 22, 2006 12:20 AM
> Cc: HIP
> Subject: Re: [Hipsec] Start re-chartering discussion in Vancouver?
>=20
> Hi,
>=20
> so we started the rechartering discussion in Vancouver, but=20
> it didn't =20
> carry over onto the mailing list. Has anyone started to put together =20
> a revised charter proposal?
>=20
> Lars

Pekka and I would like to propose that advancing the following
informational draft be considered as one of the new charter items.

Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]=20
Sent: Wednesday, March 01, 2006 12:50 PM
To: [email-masked]
Subject: I-D ACTION:draft-henderson-hip-applications-02.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Using HIP with Legacy Applications
	Author(s)	: T. Henderson, P. Nikander
	Filename	: draft-henderson-hip-applications-02.txt
	Pages		: 12
	Date		: 2006-3-1
=09
The Host Identity Protocol and architecture (HIP) proposes to add a
cryptographic name space for network stack names.  From an
application viewpoint, HIP-enabled systems support a new address
family (e.g., AF_HOST), but it may be a long time until such HIP-
aware applications are widely deployed even if host systems are
upgraded.  This informational document discusses implementation and
API issues relating to using HIP in situations in which the system is
HIP-aware but the applications are not.

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

From: [email-masked] (Henderson, Thomas R)
Date: Thu Mar  2 17:03:00 2006
Subject: [Hipsec-rg] Revision of draft-henderson-hip-applications-02.txt
Message-ID: <[email-masked]>

FYI, this is a minor update of this document.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]=20
Sent: Wednesday, March 01, 2006 12:50 PM
To: [email-masked]
Subject: I-D ACTION:draft-henderson-hip-applications-02.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Using HIP with Legacy Applications
	Author(s)	: T. Henderson, P. Nikander
	Filename	: draft-henderson-hip-applications-02.txt
	Pages		: 12
	Date		: 2006-3-1
=09
The Host Identity Protocol and architecture (HIP) proposes to add a
cryptographic name space for network stack names.  From an
application viewpoint, HIP-enabled systems support a new address
family (e.g., AF_HOST), but it may be a long time until such HIP-
aware applications are widely deployed even if host systems are
upgraded.  This informational document discusses implementation and
API issues relating to using HIP in situations in which the system is
HIP-aware but the applications are not.

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

From: [email-masked] (Miika Komu)
Date: Wed Mar  1 04:31:00 2006
Subject: [Hipsec-rg] HIP extensions for NAT traversal
Message-ID: <[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : HIP Extensions for the Traversal of Network
                          Address Translators
        Author(s)       : V. Schmitt, et al.
        Filename        : draft-schmitt-hip-nat-traversal-00.txt
        Pages           : 24
        Date            : 2006-2-28

   This document specifies extensions to Host Identity Protocol (HIP) to
   support traversal of Network Address Translator (NAT) middleboxes.
   The traversal mechanism tunnels HIP control and data traffic over UDP
   and enables HIP initiators behind NATs to contact HIP responders in
   the global Internet.  Future revisions of this document will describe
   mechanisms to contact HIP responders behind NATs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-schmitt-hip-nat-traversal-00.txt

On the courtesy of Petri Jokela from Ericsson, I opened up an issue
tracker for the NAT draft:

http://hip4inter.net/cgi-bin/roundup.cgi/hip-nat/index

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/