Subject: [Hipsec-rg] Two HIP drafts
From: petri.jokela at nomadiclab.com (Petri Jokela)
Date: Fri, 30 Jun 2006 10:16:20 +0300 (EEST)

Hi,

We have submitted two HIP related drafts:

"HIP Service Discovery"
http://www.ietf.org/internet-drafts/draft-jokela-hip-service-discovery-00.txt

Abstract:
This memo specifies a service discovery mechanism to be used with the Host 
Identity Protocol (HIP).

"Simultaneous Multi-Access extension to the Host Identity Protocol"
http://www.ietf.org/internet-drafts/draft-pierrel-hip-sima-00.txt

Abstract:
A Host Identity Protocol supporting host is able to use multiple 
interfaces simultaneously when it implements the Mobility and Multihoming 
HIP extensions. The protocol defines currently simultaneous usage via 
multiple interfaces only towards different peer hosts. Simultaneously 
using multiple interfaces towards one peer node was not defined due to 
e.g. potential problems with upper layer congestion control algorithms. 
The limitation of that protocol is that it allows only one interface to be 
used at a time between the multi-homed host and the peer host. There is no 
mechanism to separate the flows between two hosts and to allow them to use 
different interfaces independent from each other. This memo presents a 
method where two HIP hosts, of which at least one is multi-homed, can 
separate different upper layer data flows such as TCP and UDP between the 
hosts and allow them to use different interfaces at the multi-homed host.

BR, Petri

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: petri.jokela at ericsson.com

From: fu at cs.uni-goettingen.de (Xiaoming Fu)
Date: Mon, 19 Jun 2006 16:28:32 +0200
Subject: [Hipsec-rg] Preliminary Call for Papers: MobiArch 2006
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Dear colleagues,

Please find below the preliminary call for papers for MobiArch'06
workshop. Our appologizes if you receive multiple copies.

Best regards,
Xiaoming Fu

--------------------------------------------------------------------
           The First IEEE/ACM* International Workshop on
    Mobility in the Evolving Internet Architecture (MobiArch 2006)
            held in conjunction with IEEE GLOBECOM 2006,
           San Francisco, CA, USA, November/December 2006
        http://user.informatik.uni-goettingen.de/~mobiarch/
             (* - IEEE/ACM sponsorship pending approval)
--------------------------------------------------------------------

E-mail contact : mobiarch at cs.uni-goettingen.de

CFP in printable pdf format can be downloaded in
http://user.informatik.uni-goettingen.de/~mobiarch/Cfp_MobiArch06.pdf

Scope:
=====
With the recent development of technologies in wireless access and
mobile devices, terminal and network mobility have become an
indispensable component of today's Internet vision, and this is likely
to continue in the near future, while affecting the way of the whole
Internet architecture design. Yet, issues like efficient mobility
management and optimizations, locator-identifier split, multi-homing,
security and related operational/deployment concerns are still in their
early stages of development. Moreover, the Internet architecture, its
end-to-end principles and business models will require rethinking due to
the massive penetration of mobility into the Internet.

The MobiArch'06 workshop solicits papers, both from researchers and
practitioners, dealing with architectures, protocols, and experiences
with emerging technologies on mobility support in the Internet, with an
emphasis on new mobility protocols, mobility and location management,
mobile network performance, multi-homing, security, architectural
impacts and deployment considerations.

The workshop will include presentations and discussions of accepted
technical papers, as well as invited talks and panel sessions.

Topics of Interest:
==================
Original contributions are solicited in all aspects of architectural
issues and system support for mobility in the Internet, including but
not limited to:
- Mobility impact on the Internet architecture
- Architectures and protocols for mobility support in the Internet,
ranging from approaches in link layer, network, transport to
session/application layers and cross-layer design
- Locator/identifier split, multihoming and load sharing issues
- Security and privacy issues in mobility networks and impacts to
Internet architecture
- QoS and middlebox issues in mobility networks and impacts to Internet
architecture
- Economic and deployment issues of mobility infrastructure designs

Submissions:
===========
Submissions should be made to MobiArch'06 EDAS entry:
http://edas.info/4920, following the guidelines in MobiArch'06 webpage:
http://user.informatik.uni-goettingen.de/~mobiarch/

Important Dates:
===============
Submission Deadline: Monday, July 24, 2006
Acceptance Notification: August 31, 2006
Camera-ready version due: September 27, 2006
Workshop: One-day in GLOBECOM 2006 (to be announced)
GLOBECOM Main Conference: November 27-December 1, 2006

GENERAL CHAIR
=============
Jon Crowcroft, U. Cambridge (UK)

PROGRAM CO-CHAIRS
=================
Xiaoming Fu, U. Goettingen (DE)
Katherine Guo, Bell Labs (US)

PROGRAM COMMITTEE
=================
Jari Arkko, Ericsson (FI)
Raouf Boutaba, U. Waterloo (CA)
Jon Crowcroft, U. Cambridge (UK)
Wesley Eddy, NASA/Verizon (US)
Xiaoming Fu, U. Goettingen (DE)
Ivano Guardini, Telecom Italia Lab (IT)
Katherine Guo, Bell Labs (US)
Dieter Hogrefe, U. Goettingen (DE)
Yuming Jiang, NTNU (NO)
Cornelia Kappler, Siemens (DE)
Ben Liang, U. Toronto (CA)
Meng How Lim, Intel Research Cambridge (UK)
John Loughney, Nokia Research Center (FI)
Joerg Ott, Helsinki U of Techology (FI)
Charles Perkins, Nokia Research Center (US)
Christian Prehofer, Nokia Research Center (FI)
Henning Schulzrinne, Columbia U. (US)
Hannes Tschofenig, Siemens (DE)
Zhi-Li Zhang, U. Minnesoda (US)
Taieb Znati, U. Pittsburg/NSF (US)

--------------------------------------------------------------------
For more information: http://user.informatik.uni-goettingen.de/~mobiarch/

From: shep at alum.mit.edu (Tim Shepard)
Date: Wed, 14 Jun 2006 22:28:15 -0400
Subject: [Hipsec-rg] HIT and ACLs (moved from int-area)
In-Reply-To: Your message of Mon, 12 Jun 2006 10:36:25 +0300. <[email-masked]> 
Message-ID: <[email-masked]>

> >>> But in practice today, there is a similar lack of aggregation in ssh
> >>> key-based access controls.  I think it depends on what you are
> >>> trying to accomplish with the ACL.  If you really want to write ACL
> >>> policies based on address prefixes, then continue to do so, but if
> >>> you want to do it based on host identifiers, then I agree that
> >>> either they would need to be enumerated or there would need to be
> >>> some structure added for aggregation (as well as some means to
> >>> authenticate that the host is authorized to use those structured id
> >>> bits).
> >>>       
> IMO, access control based on IP address aggregation is a bad idea since 
> it severely limits access to services for mobile
> users and discourages the use of open proxies or other redirection 
> services in the network such as i3/OCALA. ACL based on prefixed HITs are 
> better though.

I cannot think of how that would be useful (so I cannot find a useful
meaning for "better" in this context).

I don't think schemes where you use the prefix of a HIT to determine
who's responsible for providing an inverse mapping are useful.  But if
we assume doing that is useful, then the presence of a prefix on a HIT
says nothing about whether or not the creater of that HIT was
authorized to have a HIT in that space.  If you find some way to tie
that into the HIT somehow, then I believe you will have just
reinvented certificates.  If you cannot tie the authorization into the
HIT securely (and I cannot imagine how you could) then you have to
either have the list of authorized HITs locally, or query someone who
has the list.  Either way, you have to check against a flat list.

So the hierarchically prefixed HITs (whether two or more levels of
hierarchy) don't seem to help solve any problems.

			-Tim Shepard
			 shep at alum.mit.edu

From: miika at iki.fi (Miika Komu)
Date: Wed, 14 Jun 2006 09:03:23 +0300 (EEST)
Subject: [Hipsec-rg] HIP NAT traversal
Message-ID: <[email-masked]>

Message: 5
Date: Tue, 13 Jun 2006 18:50:01 -0400
From: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-schmitt-hip-nat-traversal-01.txt
To: i-d-announce at ietf.org
Message-ID: <E1FqHhx-0006cT-CL at stiedprstage1.ietf.org>
Content-Type: text/plain; charset="us-ascii"

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-01.txt
         Pages           : 33
         Date            : 2006-6-13

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 which MAY be behind NATs to contact HIP
responders which MAY be behind another NAT.

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

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request at ietf.org 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.

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

From: gurtov at cs.helsinki.fi (Andrei Gurtov)
Date: Mon, 12 Jun 2006 10:39:38 +0300
Subject: [Hipsec-rg] Meeting on IETF66 at Montreal
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Scheduling was confirmed to

HIPRG Session 1 (2.5 hours)
Friday, Afternoon Session I 1230-1500
Room Name: Room 513B

Andrei

Andrei Gurtov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> This is tentative information, we'll have a HIP RG meeting in Montreal
> on Friday afternoon. I'm attending and Tom probably not. If you have
> suggestions for agenda items please send them to me.
>
> Andrei
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFEcX24P7jp0uceFkQRAt1+AKCV+Y3VrmkSpJXI9wLi9wbnrSVG0wCbBUAm
> Hz+DOuo7JjVMdRPQ6Dfkfz8=
> =P4YA
> -----END PGP SIGNATURE-----
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg at listserv.cybertrust.com
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg
>   

-- 
Andrei Gurtov  gurtov at hiit.fi  http://www.hiit.fi/andrei.gurtov
Adjunct Professor, TKK
PhD, Senior Research Scientist
Helsinki Institute for Information Technology (HIIT)
High Tech Center, Helsinki, Finland

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3397 bytes
Desc: S/MIME Cryptographic Signature
Url : https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20060612/c9641f72/attachment.bin 

From: gurtov at cs.helsinki.fi (Andrei Gurtov)
Date: Mon, 12 Jun 2006 10:36:25 +0300
Subject: [Hipsec-rg] HIT and ACLs (moved from int-area)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

>>     
>>> There is a section in the IRTF NSRG report that describes 
>>>       
>> this issue:
>>     
>>>    "Additionally, HIP raises an issue regarding other uses for
>>>    aggregation of IP addresses.  Today, they are not only 
>>>       
>> aggregated for
>>     
>>>    purposes of reduced routing, but also for reduced 
>>>       
>> administration.  A
>>     
>>>    typical access list used on the Internet will have some sort of a
>>>    mask, indicating that a group of hosts from the same subnet may
>>>    access some resource.  Because the value of a HIT is a 
>>>       
>> hash in part,
>>     
>>>    only the administratively assigned value can be aggregated,
>>>    introducing an allocation limitation and authorization concerns."
>>>
>>> But in practice today, there is a similar lack of aggregation in ssh
>>> key-based access controls.  I think it depends on what you are
>>> trying to accomplish with the ACL.  If you really want to write ACL
>>> policies based on address prefixes, then continue to do so, but if
>>> you want to do it based on host identifiers, then I agree that
>>> either they would need to be enumerated or there would need to be
>>> some structure added for aggregation (as well as some means to
>>> authenticate that the host is authorized to use those structured id
>>> bits).
>>>       
IMO, access control based on IP address aggregation is a bad idea since 
it severely limits access to services for mobile
users and discourages the use of open proxies or other redirection 
services in the network such as i3/OCALA. ACL based on prefixed HITs are 
better though.

Andrei

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3397 bytes
Desc: S/MIME Cryptographic Signature
Url : https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20060612/04054ee2/attachment.bin 

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Sat, 10 Jun 2006 13:58:08 -0700
Subject: [Hipsec-rg] RG draft accepted into RFC Editor's queue
Message-ID: <[email-masked]>

We received notice that the HIP RG document "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication" (draft-irtf-hiprg-nat-03.txt) has been accepted into the RFC Editor's queue as an IRSG submission.  Thanks to everyone who reviewed it over the past two years.

Tom

From: stiemerling at netlab.nec.de (Martin Stiemerling)
Date: Fri, 9 Jun 2006 08:57:16 +0200
Subject: [Hipsec-rg] Fwd: I-D ACTION:draft-irtf-hiprg-nat-03.txt
References: <[email-masked]>
Message-ID: <[email-masked]>

Dear all,

FYI: The new version of draft-irtf-hiprg-nat-03.txt is just fixing  
some typos, nothing else.

   Martin

Anfang der weitergeleiteten E-Mail:

> Von: Internet-Drafts at ietf.org
> Datum: 8. Juni 2006 21:50:01 MESZ
> An: i-d-announce at ietf.org
> Betreff: I-D ACTION:draft-irtf-hiprg-nat-03.txt
> Antwort an: internet-drafts at ietf.org
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
>
> 	Title		: NAT and Firewall Traversal Issues of Host Identity  
> Protocol (HIP) Communication
> 	Author(s)	: M. Stiemerling, et al.
> 	Filename	: draft-irtf-hiprg-nat-03.txt
> 	Pages		: 13
> 	Date		: 2006-6-8
> 	
> The Host Identity Protocol (HIP) changes the way in which two
> Internet hosts communicate.  One key advantage over other schemes is
> that HIP does not require modifications to the traditional network-
> layer functionality of the Internet, i.e., its routers.  In the
> current Internet, however, many devices other than routers modify the
> traditional network-layer behavior of the Internet.  These
> "middleboxes" are intermediary devices that perform functions other
> than the standard functions of an IP router on the datagram path
> between source and destination hosts.  Whereas some types of
> middleboxes may not interfere with HIP at all, others can affect some
> aspects of HIP communication and others can render HIP communication
> impossible.  This document discusses the problems associated with HIP
> communication across network paths that include specific types of
> middleboxes, namely, network address translators and firewalls.  It
> identifies and discusses issues in the current HIP specifications
> that affect communication across these types of middleboxes.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-irtf-hiprg-nat-03.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request at ietf.org 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-irtf-hiprg-nat-03.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:
> 	mailserv at ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-irtf-hiprg-nat-03.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.
> Content-Type: text/plain
> Content-ID: <2006-6-8125123.I-D at ietf.org>
>
> ENCODING mime
> FILE /internet-drafts/draft-irtf-hiprg-nat-03.txt
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce at ietf.org
> https://www1.ietf.org/mailman/listinfo/i-d-announce

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20060609/8f8705cf/attachment.html 

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Mon, 5 Jun 2006 14:00:14 -0700
Subject: [Hipsec-rg] HIT and ACLs
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

(cc-ing hipsec-rg list)

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:marcelo at it.uc3m.es] 
> Sent: Monday, June 05, 2006 11:30 AM
> To: Henderson, Thomas R
> Cc: Tim Shepard
> Subject: Re: HIT and ACLs (was Re: [Int-area] Progress on 
> draft-laganier-ipv6-khi-01.txt 
> 
> [removed the int area cc]
> 
> El 05/06/2006, a las 20:54, Henderson, Thomas R escribi?:
> 
> >
> > There is a section in the IRTF NSRG report that describes 
> this issue:
> >
> >    "Additionally, HIP raises an issue regarding other uses for
> >    aggregation of IP addresses.  Today, they are not only 
> aggregated 
> > for
> >    purposes of reduced routing, but also for reduced 
> administration.  A
> >    typical access list used on the Internet will have some sort of a
> >    mask, indicating that a group of hosts from the same subnet may
> >    access some resource.  Because the value of a HIT is a 
> hash in part,
> >    only the administratively assigned value can be aggregated,
> >    introducing an allocation limitation and authorization concerns."
> >
> > But in practice today, there is a similar lack of 
> aggregation in ssh 
> > key-based access controls.  I think it depends on what you 
> are trying 
> > to accomplish with the ACL.  If you really want to write 
> ACL policies 
> > based on address prefixes, then continue to do so, but if 
> you want to 
> > do it based on host identifiers, then I agree that either 
> they would 
> > need to be enumerated or there would need to be some 
> structure added 
> > for aggregation (as well as some means to authenticate that 
> the host 
> > is authorized to use those structured id bits).
> >
> 
> actually my bottom line question is how useful would be this type of 
> approach in order to simplify renumbering...
> 
> have you considered this?
> 

I assume that you are referring to the impact of renumbering on having to redo ACLs in an enterprise network.  Yes, I think that a potential for HIP is not to have to care about (possibly dynamic) IP addresses for security purposes, whether it is in the mobility/multihoming context or network-level access control context.    But I don't have a specific blueprint for using structured HITs to do that.

Am I answering your question?

Tom

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Mon, 5 Jun 2006 13:42:08 -0700
Subject: [Hipsec-rg] HIT and ACLs (moved from int-area)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

(removing int-area cc, adding hipsec-rg cc)

This was a subthread that started on the int-area list regarding HIP and
ACLs:
http://www1.ietf.org/mail-archive/web/int-area/current/msg00285.html

> -----Original Message-----
> From: Tim Shepard [mailto:shep at alum.mit.edu] 
> Sent: Monday, June 05, 2006 11:04 AM
> To: Henderson, Thomas R
> Cc: marcelo bagnulo braun; Internet Area
> Subject: Re: HIT and ACLs (was Re: [Int-area] Progress on 
> draft-laganier-ipv6-khi-01.txt 
> 
> 
> 
> > There is a section in the IRTF NSRG report that describes 
> this issue:
> > 
> >    "Additionally, HIP raises an issue regarding other uses for
> >    aggregation of IP addresses.  Today, they are not only 
> aggregated for
> >    purposes of reduced routing, but also for reduced 
> administration.  A
> >    typical access list used on the Internet will have some sort of a
> >    mask, indicating that a group of hosts from the same subnet may
> >    access some resource.  Because the value of a HIT is a 
> hash in part,
> >    only the administratively assigned value can be aggregated,
> >    introducing an allocation limitation and authorization concerns."
> > 
> > But in practice today, there is a similar lack of aggregation in ssh
> > key-based access controls.  I think it depends on what you are
> > trying to accomplish with the ACL.  If you really want to write ACL
> > policies based on address prefixes, then continue to do so, but if
> > you want to do it based on host identifiers, then I agree that
> > either they would need to be enumerated or there would need to be
> > some structure added for aggregation (as well as some means to
> > authenticate that the host is authorized to use those structured id
> > bits).
> 
> But a bare HIT which happens to have some prefix does not imply that
> it was created with the permission of the authority that controls the
> reverse mapping for that prefix.  Seems like you need to do an on-line
> lookup or have a full blown certificate anyway.  In that case, there's
> no value (that I can see) in having a prefix.
> 
> (Should this be on the hip-rg mailing list instead of int-area?)
> 

I see your point that the ACL based on Type 2 HIT may not offer as much
value since additional checking is required.  But even if the additional
checking is required via CERT or lookup, it may still be a concise way
of expressing the access control rule (maybe this is not important).  

It seems like the following cannot be simultaneously achieved:
- less than or equal to 128 bits in length
- enough bits in the host identity hash to withstand second-preimage
attacks
- enough bits for structure plus some means to authenticate the use of
the structure bits

But IMO it is important to consider host identities that have a useful
structure but perhaps lose one of the other two features listed above.  

Tom