Subject: [Hipsec-rg] MobiArch 2006 CFP (ONE WEEK REMINDER)
From: fu at cs.uni-goettingen.de (Xiaoming Fu)
Date: Mon, 31 Jul 2006 18:21:14 +0200

Dear colleagues,

A quick reminder that the submission deadline for the MobiArch'06
workshop is due in one week, August 7, 2006.

Sincerely,
Xiaoming (on behalf of the MobiArch'06 organization team)
--------------------------------------------------------------------
               The First IEEE International Workshop on
     Mobility in the Evolving Internet Architecture (MobiArch 2006)
              December 1, 2006,  San Francisco, CA, USA
               (in conjunction with IEEE GLOBECOM 2006)
--------------------------------------------------------------------
For more information, see:
         http://user.informatik.uni-goettingen.de/~mobiarch/

If you have any questions on paper submissions, please contact
mobiarch at cs.uni-goettingen.de

From: fu at cs.uni-goettingen.de (Xiaoming Fu)
Date: Wed, 19 Jul 2006 22:02:43 +0200
Subject: [Hipsec-rg] [Mobopts] Call for Papers: MobiArch 2006: Mobility in the Evolving Internet Architecture
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Henrik, all,

Yes the extension for 2 weeks is okay, please find the updated 
information in  http://user.informatik.uni-goettingen.de/~mobiarch/
Also note the date for MobiArch'06 is now decided - Friday, December 1, 
2006.

We would be looking forward to your contributions. If there are any 
questions or suggestions, please do not hesitate to contact us.

Thanks and best regards,
Xiaoming

Henrik Petander wrote:
> Hello,
> 
> I am considering submitting some results for this workshop. It would
> be good if the DL could be extended by two weeks, since I only heard
> about it in the mobopts meeting.
> 
> Regards,
> Henrik Petander
> 
> On 7/15/06, Xiaoming Fu <fu at cs.uni-goettingen.de> wrote:
> 
>>Dear colleagues,
>>
>>Please find below the CFP (the 1st MobiArch'06 workshop) as discussed in
>>the HIP & MOBOPTS RG sessions. Your contribution and participation are
>>very appreciated.
>>
>>Best regards,
>>Xiaoming Fu
>>
>>--------------------------------------------------------------------
>>            The First IEEE International Workshop on
>>    Mobility in the Evolving Internet Architecture (MobiArch 2006)
>>             held as part of IEEE GLOBECOM 2006,
>>          San Francisco, CA, USA, November 27 - December 1, 2006
>>         http://user.informatik.uni-goettingen.de/~mobiarch/
>>--------------------------------------------------------------------
>>
>>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
>>
>>_______________________________________________
>>Mobopts mailing list
>>Mobopts at irtf.org
>>https://www1.ietf.org/mailman/listinfo/mobopts
>>
> 
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg at listserv.cybertrust.com
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg

From: henrik.petander at gmail.com (Henrik Petander)
Date: Sat, 15 Jul 2006 12:08:24 +1000
Subject: [Hipsec-rg] [Mobopts] Call for Papers: MobiArch 2006: Mobility in the Evolving Internet Architecture
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello,

I am considering submitting some results for this workshop. It would
be good if the DL could be extended by two weeks, since I only heard
about it in the mobopts meeting.

Regards,
Henrik Petander

On 7/15/06, Xiaoming Fu <fu at cs.uni-goettingen.de> wrote:
> Dear colleagues,
>
> Please find below the CFP (the 1st MobiArch'06 workshop) as discussed in
> the HIP & MOBOPTS RG sessions. Your contribution and participation are
> very appreciated.
>
> Best regards,
> Xiaoming Fu
>
> --------------------------------------------------------------------
>             The First IEEE International Workshop on
>     Mobility in the Evolving Internet Architecture (MobiArch 2006)
>              held as part of IEEE GLOBECOM 2006,
>           San Francisco, CA, USA, November 27 - December 1, 2006
>          http://user.informatik.uni-goettingen.de/~mobiarch/
> --------------------------------------------------------------------
>
> 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
>
> _______________________________________________
> Mobopts mailing list
> Mobopts at irtf.org
> https://www1.ietf.org/mailman/listinfo/mobopts
>

From: fu at cs.uni-goettingen.de (Xiaoming Fu)
Date: Fri, 14 Jul 2006 14:43:53 -0400
Subject: [Hipsec-rg] Call for Papers: MobiArch 2006: Mobility in the Evolving Internet Architecture
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Dear colleagues,

Please find below the CFP (the 1st MobiArch'06 workshop) as discussed in 
the HIP & MOBOPTS RG sessions. Your contribution and participation are 
very appreciated.

Best regards,
Xiaoming Fu

--------------------------------------------------------------------
            The First IEEE International Workshop on
    Mobility in the Evolving Internet Architecture (MobiArch 2006)
             held as part of IEEE GLOBECOM 2006,
          San Francisco, CA, USA, November 27 - December 1, 2006
         http://user.informatik.uni-goettingen.de/~mobiarch/
--------------------------------------------------------------------

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

From: jeffrey.m.ahrenholz at boeing.com (Ahrenholz, Jeffrey M)
Date: Wed, 12 Jul 2006 13:45:41 -0700
Subject: [Hipsec-rg] FW: I-D ACTION:draft-lindqvist-hip-tcp-piggybacking-00.txt
References: <[email-masked]>
Message-ID: <[email-masked]>

-----Original Message-----
From: Internet-Drafts at ietf.org [mailto:Internet-Drafts at ietf.org]
Sent: Wed 7/12/2006 12:50 PM
To: i-d-announce at ietf.org
Subject: I-D ACTION:draft-lindqvist-hip-tcp-piggybacking-00.txt 
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Piggybacking TCP to Host Identity Protocol
	Author(s)	: J. Lindqvist
	Filename	: draft-lindqvist-hip-tcp-piggybacking-00.txt
	Pages		: 11
	Date		: 2006-7-12
	
   This document specifies how to concatenate the TCP handshake to Host
   Identity Protocol (HIP) base exchange control messages.  This
   extension gives a performance improvement by reducing one round trip
   for establishing the TCP connection when compared to a normal base
   exchange.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lindqvist-hip-tcp-piggybacking-00.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-lindqvist-hip-tcp-piggybacking-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:
	mailserv at ietf.org.
In the body type:
	"FILE /internet-drafts/draft-lindqvist-hip-tcp-piggybacking-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.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT3565396.txt
Url: https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20060712/3995fb77/attachment.txt 

From: janne.lindqvist at tml.hut.fi (Janne Lindqvist)
Date: Wed, 12 Jul 2006 16:42:32 +0300 (EEST)
Subject: [Hipsec-rg] I-D: Piggybacking TCP to HIP
Message-ID: <[email-masked]>

Hello,

Attached is a draft on "Piggybacking TCP to Host Identity Protocol", which 
I am presenting on Friday in HIP RG.

Abstract:
    This document specifies how to concatenate the TCP handshake to Host
    Identity Protocol (HIP) base exchange control messages.  This
    extension gives a performance improvement by reducing one round trip
    for establishing the TCP connection when compared to a normal base
    exchange.

-- 
Janne Lindqvist
-------------- next part --------------

Network Working Group                                       J. Lindqvist
Internet-Draft                                                       TKK
Expires: January 12, 2007                                  July 11, 2006

               Piggybacking TCP to Host Identity Protocol
              draft-lindqvist-hip-tcp-piggybacking-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 12, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document specifies how to concatenate the TCP handshake to Host
   Identity Protocol (HIP) base exchange control messages.  This
   extension gives a performance improvement by reducing one round trip
   for establishing the TCP connection when compared to a normal base
   exchange.

Lindqvist               Expires January 12, 2007                [Page 1]

Internet-Draft           HIP - TCP Piggybacking                July 2006

1.  Introduction

   Host Identity Protocol (HIP) architecture [HIPARCH] replaces the
   identity function of IP addresses.  When the Host Identity Protocol
   (HIP) is used, Host Identities (HI) are used to identify hosts.  IP
   addresses are used only as locators.  In practice, a Host Identity
   (HI) is a public key of a public/private key pair.  Because the
   public keys can be of different sizes, they are most of the time
   represented in a condensed form; a hash-based digest of a HI is
   called a Host Identity Tag (HIT).  To authenticate peers and create
   the necessary IP-layer state, HIP defines a key negotiation state
   setup protocol called the base exchange.  The base exchange can be
   used to establish IPsec ESP Security Associations [HIPESP], for
   example.

   In this document, we specify how to gain decrease connection set-up
   latency by reducing the amount of control messages when initiating a
   TCP connection with HIP.  The motivation for the presented approach
   is as follows.  We send the TCP SYN segment piggybacked to the I2
   message.  This way, the Responder can check the puzzle from I2 first,
   and only after that create TCP state.  It should be noticed that the
   initiator does not send TCP SYN already in I1 because TCP ACKs can
   already contain application data that needs to be encrypted.

   The approach is designed to work normal and opportunistic base
   exchange and with the TCP Option initiated opportunistic mode
   [OPPHIP].

Lindqvist               Expires January 12, 2007                [Page 2]

Internet-Draft           HIP - TCP Piggybacking                July 2006

2.  Terms and Definitions

   We assume that the readers are familiar with the terms and
   definitions given in [HIPBASE], hereafter referred as the HIP base
   specification.

2.1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.2.  Definitions

   HIP piggybacking: A HIP control message is followed by a segment from
   another protocol (e.g.  TCP).

Lindqvist               Expires January 12, 2007                [Page 3]

Internet-Draft           HIP - TCP Piggybacking                July 2006

3.  Overview of TCP Piggybacking to HIP

   This section presents how to piggyback TCP to HIP base exchange.

3.1.  Piggybacking TCP to Base Exchange

   The base exchange including piggybacked TCP is illustrated below.
   The I1, R1, I2 and R2 defined in the HIP base specification.  The TCP
   segments are defined in [RFC0793].  The packets contain other
   parameters in the HIP messages not shown in this figure.

          Initiator                              Responder

                          I1: trigger exchange
                     -------------------------->
                                                 select pre-computed R1
                           R1
                     <-------------------------
       check sig                                 remain stateless
       solve puzzle
                           I2 | TCP SYN
                     -------------------------->
                                                 check puzzle
                                                 check sig
                           R2 | TCP SYN+ACK
                     <--------------------------
       check sig                                 compute D-H

                           ESP(TCP ACK)
                     -------------------------->

                           ESP(TCP DATA)
                     <------------------------->

   Figure 1

   The Initiator starts the base exchange as defined in the base
   specification or as in the Internet-Draft [OPPHIP], either sending a
   normal I1 or an opportunistic I1.  The responder processes the I1 as
   usual and sends the R1.

   The Next Header field in I2 has the value protocol number 6 (TCP).
   Otherwise, the I2 format is the same as defined in the HIP base
   specification.  The I2 is followed by TCP SYN segment.  Thus, the
   packet format is IP((I2), (TCP SYN)).

Lindqvist               Expires January 12, 2007                [Page 4]

Internet-Draft           HIP - TCP Piggybacking                July 2006

   The I2 is processed by the Responder similarly as in the HIP base
   specification.  The exception is the Next Header field.  Value 6
   indicates that a TCP segment follows and needs to be processed.

   If the base exchange is initiated by the approach defined in
   [OPPHIP], the peer just retransmits the TCP SYN segment with I2.

   The Next Header field in R2 has the value protocol number 6 (TCP).
   Otherwise, the R2 format is the same as defined in the HIP base
   specification.  The R2 is followed by TCP SYN+ACK segment.  Thus, the
   packet format is IP((I2), (TCP SYN+ACK)).

   The R2 is processed by the Initiator similarly as in the HIP base
   specification.  The exception is the Next Header field.  Value 6
   indicates that a TCP segment follows and needs to be processed.

   After the base exchange, the hosts send data using the ESP transport
   format.  The TCP ACK needed for the TCP handshake is sent with ESP,
   and thus, the possible data in the TCP is encrypted and integrity
   protected.

Lindqvist               Expires January 12, 2007                [Page 5]

Internet-Draft           HIP - TCP Piggybacking                July 2006

4.  Open Issues

4.1.  Flags

   Should we have a flag in I1 and R1 to indicate the support for TCP
   piggybacking?  This could simplify the processing of the packets and
   remove the need for unnecessary retransmits?

4.2.  Integrity Protection for TCP segments

   The current approach does not allow a simple way to add integrity
   protection for the TCP segments.  Is this a real problem?

Lindqvist               Expires January 12, 2007                [Page 6]

Internet-Draft           HIP - TCP Piggybacking                July 2006

5.  Acknowledgments

   Miika Komu, Teemu Koponen, Pekka Nikander and HIP RG.

Lindqvist               Expires January 12, 2007                [Page 7]

Internet-Draft           HIP - TCP Piggybacking                July 2006

6.  Security Considerations

   The piggybacking reveals to third parties TCP control data, e.g. what
   are the used TCP port numbers.  This is at least a privacy issue.

Lindqvist               Expires January 12, 2007                [Page 8]

Internet-Draft           HIP - TCP Piggybacking                July 2006

7.  References

7.1.  Normative References

   [HIPBASE]  Moskowitz, R., Nikander, P., Jokela (editor), P., and P.
              Jokela (editor), "Host Identity Protocol",
              draft-ietf-hip-base-06 (work in progress), June 2006.

   [OPPHIP]   Lindqvist, J., "Host Identity Protocol",
              draft-lindqvist-hip-opportunistic-01 (work in progress),
              March 2006.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2.  Informative References

   [HIPARCH]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              Architecture", RFC 4423, May 2006.

   [HIPESP]   Jokela, P., Moskowitz, R., and P. Nikander, "Using ESP
              transport format with HIP", draft-ietf-hip-esp-03 (work in
              progress), June 2006.

Lindqvist               Expires January 12, 2007                [Page 9]

Internet-Draft           HIP - TCP Piggybacking                July 2006

Author's Address

   Janne Lindqvist
   Helsinki University of Technology (TKK)
   P.O. Box 5400
   Espoo  FIN-02015 TKK
   Finland

   Phone: +358 9 451 5851
   Email: janne.lindqvist at tkk.fi
   URI:   http://www.tml.tkk.fi/

Lindqvist               Expires January 12, 2007               [Page 10]

Internet-Draft           HIP - TCP Piggybacking                July 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr at ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Lindqvist               Expires January 12, 2007               [Page 11]


From: sebastien.pierrel at nomadiclab.com (=?ISO-8859-1?Q?S=E9bastien_Pierrel?=)
Date: Wed, 12 Jul 2006 01:45:01 +0300
Subject: [Hipsec-rg] Two HIP drafts
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Andrei Gurtov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Petri-
> 
> Thanks for the drafts. A couple of questions after reading them
> 
> For SIMA, is the message to the other end point really necessary? Can't
> the peer basically remember which protocols/ports arrive from which
> interface and then send reply packets to the same interface.

Well, I agree it may look more like a more natural way to go, but this 
  would require standardization for every transporting protocol (e.g. 
ESP/IPSec). Moreover, every single received packet would have to be 
checked against current rules sets, which in the end would be costly for 
the peer.

> DCCP&SCTP protocols could be added I suppose in the next version. 

OK.

> How about SIMA within a single transport connection, like sending
> segments from the same TCP connection over several interfaces
> simultaneously? I guess this is out of scope for the draft - this
> could be mentioned explicitly in the introduction.

OK.

Thanks for your comments,
/Seb.

From: petri.jokela at nomadiclab.com (Petri Jokela)
Date: Wed, 12 Jul 2006 01:43:47 +0300 (EEST)
Subject: [Hipsec-rg] Two HIP drafts
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Thu, 6 Jul 2006, Henderson, Thomas R wrote:
>> "Simultaneous Multi-Access extension to the Host Identity Protocol"
>> http://www.ietf.org/internet-drafts/draft-pierrel-hip-sima-00.txt
>>
>
> shim6 has already initiated some work along these lines in the form of
> the "Locator Preferences" option, leveraging the DNS SRV record format.
> It might make sense to align with shim6 in this area.

Yes, this is something that should be done.

/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: petri.jokela at nomadiclab.com (Petri Jokela)
Date: Wed, 12 Jul 2006 01:29:28 +0300 (EEST)
Subject: [Hipsec-rg] Two HIP drafts
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 12 Jul 2006, Andrei Gurtov wrote:

> Thanks for the drafts. A couple of questions after reading them
>
> For HIP SD, how does that relate to BOS packets for finding HIP hosts in
> a LAN? That's kind of one-hop SD. Perhaps it would be useful to compare
> the two approaches in the draft. How about using of higher-level
> protocols such as SDP for this purpose?

The BOS contained the HI, which is not included in the SD packet. 
Otherwise, the SD is quite similar in operation when sent to the local 
link (destination HIT = NULL, destination IP = broadcast).

BOS could be used also from the server towards clients so that clients 
learn the server HI from the packet. In SD, it would be similar situation 
if the server broadcasted the SA packet to the local network without 
requiring triggering from any client node in the network. I haven't 
thought this more, it just came to my mind while discussing this with 
Miika.

Related to other service discovery methods (like Tom also asked earlier): 
we need to look them more carefully. The current SD is built so that the 
service registration with the responding server is optimized. The required 
HIP packet information is included already in the SA message. I don't know 
how much the existing service discovery protocols would need modifications 
to support similar functionality.

/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: gurtov at cs.helsinki.fi (Andrei Gurtov)
Date: Wed, 12 Jul 2006 00:08:05 +0300
Subject: [Hipsec-rg] Two HIP drafts
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Petri-

Thanks for the drafts. A couple of questions after reading them

For SIMA, is the message to the other end point really necessary? Can't
the peer basically remember which protocols/ports arrive from which
interface and then send reply packets to the same interface.  DCCP&SCTP
protocols could be added I suppose in the next version. How about SIMA
within a single transport connection, like sending segments from the
same TCP connection over several interfaces simultaneously? I guess this
is out of scope for the draft - this could be mentioned explicitly in
the introduction.

For HIP SD, how does that relate to BOS packets for finding HIP hosts in
a LAN? That's kind of one-hop SD. Perhaps it would be useful to compare
the two approaches in the draft. How about using of higher-level
protocols such as SDP for this purpose?

BR
Andrei

Petri Jokela wrote:
> 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
> 

- --
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

From: gurtov at cs.helsinki.fi (Andrei Gurtov)
Date: Sun, 09 Jul 2006 15:43:00 +0300
Subject: [Hipsec-rg] HIPRG draft agenda at Montreal
Message-ID: <[email-masked]>

HIPRG agenda (draft)
Friday, Afternoon Session I 1230-1500
Room Name: Room 513B
- ------

1.  Agenda discussion and status update

- - draft-irtf-hiprg-nat-03.txt
http://www.ietf.org/internet-drafts/draft-irtf-hiprg-nat-03.txt
- - draft-irtf-hip-experiment-02.txt
http://www.ietf.org/internet-drafts/draft-irtf-hip-experiment-02.txt

2.  Drafts

draft-pierrel-hip-sima-00: HIP Simultaneous Multiaccess (Petri Jokela)
http://www.ietf.org/internet-drafts/draft-jokela-hip-service-discovery-00.txt

draft-jokela-hip-service-discovery-00: IP service discovery (Petri Jokela)
http://www.ietf.org/internet-drafts/draft-pierrel-hip-sima-00.txt

draft-lindqvist-hip-tcp-piggybacking-00.txt: TCP piggybacking (Janne
Lindqvist)

draft-lindqvist-hip-opportunistic-01.txt: Opportunistic mode with TCP
option (Janne Lindqvist)
http://www.ietf.org/internet-drafts/draft-lindqvist-hip-opportunistic-01.txt

3.  Software

Status update of experimental implementations, and demos (if any)

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Thu, 6 Jul 2006 10:09:56 -0700
Subject: [Hipsec-rg] Two HIP drafts
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Petri, I had a few initial questions/comments:

> -----Original Message-----
> From: Petri Jokela [mailto:petri.jokela at nomadiclab.com] 
> Sent: Friday, June 30, 2006 12:16 AM
> To: hipsec-rg at honor.trusecure.com
> Cc: jukka.ylitalo at nomadiclab.com; jan.melen at nomadiclab.com
> Subject: [Hipsec-rg] Two HIP drafts
> 
> Hi,
> 
> We have submitted two HIP related drafts:
> 
> "HIP Service Discovery"
> http://www.ietf.org/internet-drafts/draft-jokela-hip-service-d
> iscovery-00.txt
> 
> Abstract:
> This memo specifies a service discovery mechanism to be used 
> with the Host 
> Identity Protocol (HIP).

Why not use or extend existing service discovery mechanisms such as
multicast DNS, DNS service discovery, Apple Bonjour, DHCP, etc.?  Why
does HIP need its own service discovery mechanism?

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

shim6 has already initiated some work along these lines in the form of
the "Locator Preferences" option, leveraging the DNS SRV record format.
It might make sense to align with shim6 in this area.

Tom