RE: [Hipsec] Rechartering items?

> -----Original Message-----
> From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] 
> Sent: Wednesday, November 02, 2005 2:34 AM
> To: Henderson, Thomas R
> Cc: HIP; David Ward
> Subject: Re: [Hipsec] Rechartering items?
> 
> 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
> >
> > 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.
> 
> 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.
> 

I was referring to HIP interoperability, but you are correct that more
general interoperability conditions are a problem.  I agree that there
are upper-layer interoperability issues with RFC 1958-non-compliant
applications if an HIP implementation decides to implement LSIs that
spoof IP addresses to those apps.

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

I would like to reserve judgement on whether only one way is needed
until we get some more experience.  

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

I don't see how this would work since it is too late to be deciding on
LSI once I2 is happening.

Tom

_______________________________________________
Hipsec mailing list
Hipsec@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hipsec