Subject: [Hipsec-rg] IPV6 Base exch+ESP
From: quanli83 at yahoo.com.cn (quanli wang)
Date: Wed, 1 Nov 2006 10:13:24 +0800 (CST)

we have done almost all  the  experiments on ipv4  successfully,we have two questions :
       1.how to test IPV6 Base exch+ESP?please give some guide!
       2.can we use the IPV6 address as the DNS server IP address?   Because we want to deploy HIP experiments on true IPV6   environment,do we need modify the code of "hip_dns.c"?
  thanks for help!

---------------------------------
????????-3.5G???20M??? 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20061101/f7b51486/attachment.html 

From: quanli83 at yahoo.com.cn (quanli wang)
Date: Wed, 1 Nov 2006 09:51:51 +0800 (CST)
Subject: [Hipsec-rg] IPV6 Base exch+ESP
Message-ID: <[email-masked]>

 we have done almost all  the  experiments on ipv4  successfully,we have two questions :
       1.how to test IPV6 Base exch+ESP?please give some guide!
       2.can we use the IPV6 address as the DNS server IP address?   Because we want to deploy HIP experiments on true IPV6   environment,do we need modify the code of "hip_dns.c"?
  thanks for help!

---------------------------------
 Mp3???-???????   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20061101/363ce137/attachment.html 

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Sun, 29 Oct 2006 19:49:57 +0200
Subject: [Hipsec-rg] Automatic spam filter applied to the HIPSEC-RG list
Message-ID: <[email-masked]>

Hi all,

I've applied an automatic spam filter on this list.  It's based on  
spam assasin, and currently it discards all messages that get a spam  
score higher than 9.0.  Anything send by non-members that gets a  
lower rating will still get hand inspected by me.  This is only to  
reduce my work and to reduce my mistakes.  After the change I need to  
review only maybe 10 spam messages per day instead of the former 50 
+.  With the 50-100 messages to review per time it was fairly  
probable that I might have mistakenly discarded genuine messages  
posted by non-members.

This should not change the way list-members can send messages.   
AFAIK, only messages sent by non-members are filtered.

--Pekka

From: miika at iki.fi (Miika Komu)
Date: Fri, 27 Oct 2006 12:53:40 +0300 (EEST)
Subject: [Hipsec-rg] HIP experiments
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Thu, 19 Oct 2006, Henderson, Thomas R wrote:

>> i) experimental requirements.  What are we trying to accomplish with
>> experiments?  Can we sketch out the experiments that need to be
>> conducted and the data that need to be gathered?  There should be more
>> than one experiment, and it might be productive to define
>> them in small
>> chunks so that the task is more approachable by the
>> community.  We ought
>> to establish some milestones and have some discussion to refine the
>> approaches.
>
> Let me start by describing some broad categories of experiments that I
> envision.  I'd like to hear feedback on whether people already have
> conducted or plan to soon conduct experiments on these topics, and what
> other topics should be included.  Please provide pointers to published
> experimental results.

Some miscellaneous pointers and comments below.

> I will divide the below into "benefits" and "costs".
>
> -> Benefits:  What specific benefits accrue to particular applications
> when HIP is in the stack?  What generic benefits apply to having HIP
> generally available for all upper-layer protocols?
>
> 1) Host mobility and multihoming.  HIP allows for transport sessions to
> survive address locator changes.  There is a possibility that end-to-end
> HIP mobility and multihoming can occur as fast or faster than other
> end-to-end approaches including MIPv6 with route optimization and SIP
> mobility.  Are there specific experiments that quantify the possible
> handover benefits in typical operational settings?  Are any particular
> end-to-end mobility benefits from HIP offset by various (non-HIP) fast
> handoff approaches deployed for mobile networks, in practice?  Can
> anyone demonstrate that application performance is demonstrably improved
> by HIP mechanisms?

http://www.jokela.org/publications/iswcs04.pdf
http://www.ietf.org/internet-drafts/draft-sugimoto-multihome-shim-api-00.txt

> Related to this, it has been suggested that HIP offers the potential for
> much better nomadic connectivity, such as the potential for a user to
> close his or her laptop at work, move to a coffee shop or home network,
> and keep all of the transport and application sessions alive.

http://www.ambient-networks.org/publications/Protocol_Enhancements_for_Intermittently_Connected_Hosts_0507.pdf
http://www.ietf.org/internet-drafts/draft-sarolahti-tsvwg-crosslayer-00.txt

> 2) Security.  I have heard at least one HIP proponent suggest that the 
> main benefit of locating HIP at the network layer was to protect the 
> network layer against attacks on the bindings for mobility and 
> multihoming.  Is there evidence of stronger security than, for instance, 
> other techniques for mobility and multihoming such as mobile IP and 
> various multihoming techniques previously categorized by the multi6 
> working group?  Do we have any experimental or operational evidence that 
> HIP (e.g. SIGMA handshake) provides better security for public servers 
> than do other approaches that have been deployed, such as SYN cookies? 
> How about for clients?  Return routability checks also exist for mobile IP, 
> for instance.

I would add TLS to the comparison list. Also, there is a very initial 
draft in BTNS wg:

http://www.ietf.org/internet-drafts/draft-komu-btns-api-00.txt

> 3) IPv6 transition.  Because HIP allows for roaming across address
> families, it has been suggested as a mechanism to improve transition to
> IPv6.  This technique has been demonstrated at previous HIP meetings;
> has this been experimentally validated or has there been any more work
> along these lines?

InfraHIP has one post-grad student working on this topic. In general, the 
application and network layer address family independence eases transition 
towards IPv6, but first one should transition to HIP :) I believe that the 
identity/locator split can slow down transition towards IPv6 because the 
new namespace of HIP can extend the lifetime of NATted architectures:

http://www.ietf.org/internet-drafts/draft-schmitt-hip-nat-traversal-02.txt

(I am in no way advocating the use of NATs; they add complexity to all 
protocols but IPv6 is not here yet to wash away all of the NATs)

> 4) New architectures.  There have been a number of architectural and
> protocol proposals that accomplish some of the basic goals of HIP yet
> without requiring any use of HIP in the network stack.  For example, the
> NUTSS architecture
> ...

Regarding to SIP-HIP integration:

http://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-host-identities-04.txt

> -> Costs:  What are the operational costs of deploying HIP on a wide
> scale, including costs on implementation complexity, new or modified
> infrastructure, and operations, administration, and management (OA&M)?

Two publications in progress related to this.

> 7) NAT traversal.  How well does HIP NAT traversal work?  Researchers
> working on NAT traversal have explicitly tested their techniques on a
> large sample of commercially-available NATs, and published the results.
> Has anyone done this for HIP?  What are the costs in terms of
> implementation complexity or server infrastructure needed for hole
> punching?

Work in progress. Lauri Silvennoinen has almost completed the NAT 
implementation that covers base exchange (initiator and responder can be 
behind NAT). Better NAT mobility and multihoming specification work is 
also work in progress.

> 8) Non-routable addresses in applications.  Some existing HIP
> implementations (and many other overlay implementations outside of HIP)
> use modified resolvers to return quantities in DNS responses that are
> not IP addresses.  For instance, it is possible to return HITs instead
> of IPv6 addresses, to allow for non-HIP-aware applications to use HIP.
> Many people have objected in principle to this practice, claiming that
> it will break certain applications (such as ones that do referrals).
> Yet, the anecdotal claims by people who have adopted this implementation
> style are generally that everything works reliably.  Can we start to
> more systematically track what types of applications are prone to
> problems with this implementation approach?  Or is this concern really a
> non-issue in practice?

http://www.ietf.org/internet-drafts/draft-henderson-hip-applications-03.txt
http://www.ietf.org/internet-drafts/draft-komu-shim-native-api-00.txt
http://www.iki.fi/miika/docs/f17-komu.pdf

There is some on going work regarding to these issues in InfraHIP.

> 9) Implementation costs.  Implementors have discovered that there are
> various costs of providing HIP in host operating systems.  First, it
> complicates the per-packet processing and has the potential to make
> certain operations (e.g., source address selection) more complicated.
> Second, there are performance hits due to both the cryptographic
> operations and due to implementation tricks that avoid kernel
> modifications but instead lead to additional memory copies.  Third,
> there is a policy management issue (how do I keep track of and protect
> my host identities?  How do I express that I want to browse using an
> anonymous host identity but use published host identity for my VoIP
> calls?  What about multi-user machines?)  It has been observed that HIP
> and other overlay techniques bring to the surface a lot of policy and
> management issues that heretofore could have been ignored or implicitly
> handled.  Can we better document these costs?

http://infrahip.hiit.fi/papers/niklas_dippa.pdf

> 10) HIP-aware middleboxes.  Researchers have suggested that future
> middleboxes could become HIP-aware and offer better control of network
> policy based on endpoint identification.  Do we have experience on the
> costs to the middleboxes and other policy management infrastructure to
> support these extensions?  Do we have any deployment experiences here?

Some work related to this is in progress in InfraHIP.

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

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Thu, 19 Oct 2006 09:38:05 -0700
Subject: [Hipsec-rg] HIP experiments
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> 
> i) experimental requirements.  What are we trying to accomplish with
> experiments?  Can we sketch out the experiments that need to be
> conducted and the data that need to be gathered?  There should be more
> than one experiment, and it might be productive to define 
> them in small
> chunks so that the task is more approachable by the 
> community.  We ought
> to establish some milestones and have some discussion to refine the
> approaches.

Let me start by describing some broad categories of experiments that I
envision.  I'd like to hear feedback on whether people already have
conducted or plan to soon conduct experiments on these topics, and what
other topics should be included.  Please provide pointers to published
experimental results.

I will divide the below into "benefits" and "costs".

-> Benefits:  What specific benefits accrue to particular applications
when HIP is in the stack?  What generic benefits apply to having HIP
generally available for all upper-layer protocols? 

1) Host mobility and multihoming.  HIP allows for transport sessions to
survive address locator changes.  There is a possibility that end-to-end
HIP mobility and multihoming can occur as fast or faster than other
end-to-end approaches including MIPv6 with route optimization and SIP
mobility.  Are there specific experiments that quantify the possible
handover benefits in typical operational settings?  Are any particular
end-to-end mobility benefits from HIP offset by various (non-HIP) fast
handoff approaches deployed for mobile networks, in practice?  Can
anyone demonstrate that application performance is demonstrably improved
by HIP mechanisms? 

Related to this, it has been suggested that HIP offers the potential for
much better nomadic connectivity, such as the potential for a user to
close his or her laptop at work, move to a coffee shop or home network,
and keep all of the transport and application sessions alive.  Yet in
practice, many of these networks have NATs or firewalls that change the
nature of connectivity from one place to another, web-capture
authentication pages that make mobility less transparent, and ssh or
application layer inactivity timeouts that might render such mobility
capability much less helpful in practice.  Can we construct experiments
to test whether such nomadic mobility does deliver improved user
experiences, or how hard it is to really make HIP robust to the jungle
of network connectivity out there?

2) Security.  I have heard at least one HIP proponent suggest that the
main benefit of locating HIP at the network layer was to protect the
network layer against attacks on the bindings for mobility and
multihoming.  Is there evidence of stronger security than, for instance,
other techniques for mobility and multihoming such as mobile IP and
various multihoming techniques previously categorized by the multi6
working group?  Do we have any experimental or operational evidence that
HIP (e.g. SIGMA handshake) provides better security for public servers
than do other approaches that have been deployed, such as SYN cookies?
How about for clients?  Return routability checks also exist for mobile
IP, for instance.

3) IPv6 transition.  Because HIP allows for roaming across address
families, it has been suggested as a mechanism to improve transition to
IPv6.  This technique has been demonstrated at previous HIP meetings;
has this been experimentally validated or has there been any more work
along these lines?

4) New architectures.  There have been a number of architectural and
protocol proposals that accomplish some of the basic goals of HIP yet
without requiring any use of HIP in the network stack.  For example, the
NUTSS architecture
(http://nutss.gforge.cis.cornell.edu/pub/cucs06-nutss.pdf) suggests
using SIP as a control plane protocol for the Internet, and talks about
using endpoint identities and a policy framework to coordinate
middleboxes, as do some of the HIP-enabled architectural proposals.
NUTSS handles mobility using SIP mechanisms, and handles TCP session
survivability through the interposition of a new session layer, similar
to the TCP Rocks/Racks proposal ("Reliable Network Connections, Mobicom
2002).  NUTSS seems compatible with HIP (HIP could handle the TCP
mobility, for instance) but does not depend on it.  But does HIP offer
NUTSS anything tangible?  Can someone show that application performance
would benefit from HIP mobility instead of SIP mobility in such an
architecture?   

There are other proposals that build on HIP concepts.  For instance, the
Unmanaged Internet Architecture
(http://www.brynosaurus.com/pub/net/uia-osdi.pdf) uses cryptographic
EIDs in a manner similar to HIP, but works at an overlay layer and binds
these EIDs to personal names that users create.  In general, one can
deploy HIP-like concepts at an overlay layer, which would solve a
deployment issue.  Should that be the preferred means to experiment with
HIP techniques (in an overlay and not in the stack), and only move it
into the stack when there is a demonstrable performance or security
benefit shown?

-> Costs:  What are the operational costs of deploying HIP on a wide
scale, including costs on implementation complexity, new or modified
infrastructure, and operations, administration, and management (OA&M)?

5) Endpoint identity resolution.  Can we quantify the additional load on
DNS or new infrastructure (such as DHTs) needed to handle this new
namespace in the public Internet?

6) Mobility infrastructure.  HIP rendezvous servers have been proposed
to solve the double-jump mobility problem.  Is there any experience with
this approach in practice?  What types of costs and benefits of
rendezvous servers should be experimentally validated?

7) NAT traversal.  How well does HIP NAT traversal work?  Researchers
working on NAT traversal have explicitly tested their techniques on a
large sample of commercially-available NATs, and published the results.
Has anyone done this for HIP?  What are the costs in terms of
implementation complexity or server infrastructure needed for hole
punching?

8) Non-routable addresses in applications.  Some existing HIP
implementations (and many other overlay implementations outside of HIP)
use modified resolvers to return quantities in DNS responses that are
not IP addresses.  For instance, it is possible to return HITs instead
of IPv6 addresses, to allow for non-HIP-aware applications to use HIP.
Many people have objected in principle to this practice, claiming that
it will break certain applications (such as ones that do referrals).
Yet, the anecdotal claims by people who have adopted this implementation
style are generally that everything works reliably.  Can we start to
more systematically track what types of applications are prone to
problems with this implementation approach?  Or is this concern really a
non-issue in practice?  

9) Implementation costs.  Implementors have discovered that there are
various costs of providing HIP in host operating systems.  First, it
complicates the per-packet processing and has the potential to make
certain operations (e.g., source address selection) more complicated.
Second, there are performance hits due to both the cryptographic
operations and due to implementation tricks that avoid kernel
modifications but instead lead to additional memory copies.  Third,
there is a policy management issue (how do I keep track of and protect
my host identities?  How do I express that I want to browse using an
anonymous host identity but use published host identity for my VoIP
calls?  What about multi-user machines?)  It has been observed that HIP
and other overlay techniques bring to the surface a lot of policy and
management issues that heretofore could have been ignored or implicitly
handled.  Can we better document these costs?

10) HIP-aware middleboxes.  Researchers have suggested that future
middleboxes could become HIP-aware and offer better control of network
policy based on endpoint identification.  Do we have experience on the
costs to the middleboxes and other policy management infrastructure to
support these extensions?  Do we have any deployment experiences here?

- Tom

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Thu, 19 Oct 2006 07:32:38 -0700
Subject: [Hipsec-rg] HIPRG meeting cancelled for IETF-67 (San Diego)
Message-ID: <[email-masked]>

All,
We didn't receive any response to the call for agenda items, so will
therefore cancel the HIPRG meeting that had been scheduled for IETF-67.

I would like to ask that we have a discussion on the list as a follow-up
to my message last week on planning some HIP experimental efforts.  I'll
initiate a separate thread.

We will tentatively plan for a Friday afternoon meeting of the HIPRG in
Prague.

Tom 

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Fri, 13 Oct 2006 07:04:47 -0700
Subject: [Hipsec-rg] reprioritizing our experimental thrust
Message-ID: <[email-masked]>

Dear HIP RG members,

I have had some offline discussions with members of the implementation
community regarding where the HIP work is at right now and where it is
going.  I have also discussed the below with Andrei.  In brief, we would
like to organize our community to better respond to our RG charter.

If you look at our RG charter, you will find that we are chartered to
study the HIP architecture, and the impact that the broader Internet
would feel if the standardized IP architecture were to include the HIP
extension.  To date we have had a passive approach towards experiments,
asking people to bring in the results for discussion.  My impression is
that such an approach is not working, and that we should more actively
discuss and agree on an experimental plan, and then collectively work on
producing the experiments and discussing the results.

It was observed early on that we need high-quality host software to
perform the experiments.  A number of groups formed their own
implementations and conducted interoperability testing and progressed
the core HIP drafts; this was an essential step.  Lately, however, I
feel that we are getting bogged down in "featuritis" and trying to cover
too many implementation scenarios so that HIP is available ubiquitously
in the stack on many platforms, and that we are not collaborating enough
and hence are duplicating some efforts, and this is sapping our energy
that should be directed towards validating the HIP architecture.

I discussed with Andrei and we would like to have a discussion on this
list as follows:

i) experimental requirements.  What are we trying to accomplish with
experiments?  Can we sketch out the experiments that need to be
conducted and the data that need to be gathered?  There should be more
than one experiment, and it might be productive to define them in small
chunks so that the task is more approachable by the community.  We ought
to establish some milestones and have some discussion to refine the
approaches.

ii) implementation requirements.  What is needed in the implementations
to allow these experiments to be conducted?  This will help us to set
priorities on the software development.

Once we have a better feel for the above, we think we have support in
the implementation community to more collaboratively develop the
software and conduct the experiments.  We would also like this to be a
process open to others with the interest and energy to conduct these
experiments and progress the software.

If there is support for this approach, we'd next like to start a thread
to talk about the experimental requirements.

Sincerely,
Tom and Andrei

From: miika at iki.fi (Miika Komu)
Date: Mon, 9 Oct 2006 14:01:16 +0300 (EEST)
Subject: [Hipsec-rg] few questions
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 9 Oct 2006, ???? wrote:

> hello i am a probie in hip stuty.i have started a test of hip connection 
> which is guided by your manual in HIPL website, but i can't establish 
> the connection. the problems is: 1 I had run "ifconfig dummy0",but i 
> can't get both hits of "crash" and "oops", what's led to this? I have 
> followed every step of the manual. how could this happen? 2 where do the 
> hits of hosts come from? should we configure the HIT of every hosts or 
> it just be generated randomly?
>
> thank you very much! have a good day!
> Jacqueline
>
>
> PS:do you have any tools just for performance measures of hip? like 
> ttcp,iperf or netperf.

Please ask the implementation related questions on the mailing list:

http://www.freelists.org/list/hipl-users

(Going to respond on the mailing list to you)

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

From: oasisjj at 163.com (=?gb2312?B?0Oy9ow==?=)
Date: Mon, 9 Oct 2006 17:34:19 +0800 (CST)
Subject: [Hipsec-rg] few questions
Message-ID: <[email-masked]>

hello 
i am a probie in hip stuty.i have started a test of hip connection which is guided by your manual in HIPL website, but i can't establish the connection. the problems is:
1 I had run "ifconfig dummy0",but i can't get both hits of "crash" and "oops", what's led to this? I have followed every step of the manual. how could this happen?
2 where do the hits of hosts come from? should we configure the HIT of every hosts or it just be generated randomly?
 
thank you very much! have a good day!
Jacqueline

PS:do you have any tools just for performance measures of hip? like ttcp,iperf or netperf.

 

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

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Mon, 2 Oct 2006 16:31:14 -0700
Subject: [Hipsec-rg] HIP RG meeting at IETF 67
Message-ID: <[email-masked]>

We have scheduled a regular meeting slot for Friday November 10
(1230-1500) in San Diego, but we have not determined yet whether there
is sufficient interest to have the RG meet.  We would like to ask
whether anyone has agenda items for this meeting; please reply to the
list or the chairs.

Thanks,
Tom