Subject: RE: [Hipsec] Rechartering items?

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 3 Nov 2005 22:08:36 -0800

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]] 
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 4 Nov 2005 10:22:27 +0100

>>>> similar to SHIM6 ULIDs
>> 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 was merely thinking about error diagnostics.  It may be good to  
know what what kind of upper layer identifiers your peer is using in  
its legacy API, even if you can't adopt your own behaviour any more  
at that place.  I realise I used the term "negotiate" improperly.

To clarify:  it may be a good idea for hosts to tell their peers what  
kind of upper layer identifiers they are using in their legacy API,  
in order to better diagnose potential conditions where using  
different kind of formats lead to upper-layer error conditions.

--Pekka