Subject: RE: [Hipsec] Rechartering items?

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 1 Nov 2005 09:51:44 -0800

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Tuesday, November 01, 2005 2:53 AM
> To: HIP
> Cc: David Ward
> Subject: [Hipsec] Rechartering items?
> 
> Now that we have time for starting HIP WG re-chartering 
> discussion at our agenda next week, I'd like to hear people's 
> ideas of what should be the next items.  As far as I can see, 
> it may take a while before mobility and multi-homing 
> stabilises, so that might need to continue.  But other than that?
> 
> Some things that I would consider important:
> 
>   - making HIP to work with legacy NATs (and firewalls when feasible)

This topic has seen significant interest from the RG side, and in fact
there has been discussion in the RG that this topic might be a candidate
to push into the WG if there were charter interest there.  The RG
decided to make the following draft into a RG document-- it is a problem
statement discussing the problem of traversing legacy NATs and
firewalls:
http://www.ietf.org/internet-drafts/draft-irtf-hiprg-nat-00.txt

An implementation draft was worked on about a year ago, but it has since
expired.  I do not know of any implementation, although I have heard
that InfraHIP is working on it.
https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=129
56

The RG is also considering solutions involving HIP-aware firewalls and
NATs, but IMO that type of work (as well as native HIP API) is not ready
for a WG.

> 
>   - invisible HIP, or using HIP with IP addresses as LSIs, similar to
> SHIM6 ULIDs
> 
A draft that discusses this topic is at:
http://www.ietf.org/internet-drafts/draft-henderson-hip-applications-01.
txt

It has not generated any mailing list or meeting discussion.  I was
thinking of submitting it to RFC Editor as an individual submission.
This topic is not one that necessarily involves interoperability, so I
would like to understand better what is left to do (as a possible WG
item) beyond the present draft.

> What else would be both important and mature enough for WG side work?
> 

The integration of SIP and HIP has received a lot of attention in the
RG, but I don't know whether there are any implementations:
i)
http://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-hip-srtp-01.t
xt
ii)
http://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-host-identiti
es-02.txt
iii)
http://www.ietf.org/internet-drafts/draft-papadoglou-hiprg-hit-presence-
00.txt

Tom

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

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 2 Nov 2005 11:33:50 +0100

Tom,

> The RG is also considering solutions involving HIP-aware firewalls  
> and NATs, but IMO that type of work (as well as native HIP API) is  
> not ready for a WG.

I agree.

>>   - invisible HIP, or using HIP with IP addresses as LSIs, similar  
>> to SHIM6 ULIDs
>>
> A draft that discusses this topic is at: http://www.ietf.org/ 
> internet-drafts/draft-henderson-hip-applications-01.txt
>
> thinking of submitting it to RFC Editor as an individual  
> submission.  This topic is not one that necessarily involves  
> interoperability, so I would like to understand better what is left  
> to do (as a possible WG item) beyond the present draft.

There are severe interoperability issues with upper layer protocols.   
Depending on what you use at the API as LSI, those upper layer  
protocols that send LSIs in their datagrams to third hosts will  
either fail or work.  One could consider this also as an  
architectural issues, as it circles around the semantics of LSIs/ 
ULIDs, specifically whether they are routable or not.

The existing draft is pretty good in outlining the issues, and fine  
as long as we want to use HIP only as experimental.  However, if we  
would like to advance HIP to standards track, then we need to have  
*one* RECOMMENDED way for LSIs...  The other way would remain  
experimental, between consenting hosts, IMHO.

At the protocol level there may be desire to negotiate this.  I.e. an  
extension that defines in I2 which LSI format is used by the  
peer....  That could be informational, as any two-hosts protocols can  
function even if the communicating hosts use different LSI formats.

--Pekka