Subject: [Hipsec] New HIP WG charter proposal

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 01 May 2010 10:11:26 +0300

Hi,

as you know, we need to recharter the WG in order to move our specs to
the standards track. I have put together a charter proposal (see
attachment). Please, let me know if you have any comments on it.

I have used a less aggressive time frame than what was presented in in
Anaheim:

http://www.ietf.org/proceedings/10mar/slides/hip-1/hip-1_files/v3_document.htm

Also, I think we have enough on our plate for now. We can add the HIP
proxy and Diet HIP exchange work to our charter when we finish the first
RFCs we will be working on.

Cheers,

Gonzalo
HIP co-chair

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 01 May 2010 10:24:37 +0300

Hi,

I have updated the charter with the RFC number of the NAT traversal spec.

Cheers,

Gonzalo

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 04 May 2010 02:15:35 -0700

> attachment). Please, let me know if you have any comments on it.

What is the current state of handling applications that do referrals 
with HIP? Last time I looked there wasn't any useful support for this.

I think preserving that part of the Internet architecture is important 
in whatever we put on the standards track.

    Erik

---

From: Miika Komu <[email-masked]>
Date: Tue, 04 May 2010 12:42:33 +0300

On 04/05/10 12:15, Erik Nordmark wrote:

Hi,

> in whatever we put on the standards track.

HIP as an experiment has been a success and we want it to proceed to the 
standards track. So, would it make sense to discuss about HIT prefix 
delegation in DNS? There is is already some small-scale experience on this.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 04 May 2010 09:47:44 -0400

> with HIP? Last time I looked there wasn't any useful support for this.

Here is pretty much what we have learned over the past many years...

If the referral is an IP address the following MAY occur:

If the app just issues an http://<addr>/<whatever> the HIP shim MAY 
perform an opportunistic HIP BEX and if successful proceed with the 
connection over HIP. If opportunistic failed or was not configured, then 
the connection will occur "open". That is without HIP.

If the app issues a reverse lookup on <addr> and retrieves a DNS HI 
record, then again, HIP would be used for the connection.

If the referral is a HIT, then the HIP shim would need some mechanism to 
perform the HIT to IP lookup. One would have to ASSuME that since a HIT 
was provided in a referral that a lookup mechanism was provided by the 
server and hopefully the client will use the 'right one'. One possiblity 
is DHT. Another is DNS. DNS reverse lookups of HITs is a problem, as 
they are flat within the ORCHID prefix (well flat within the new concept 
of HIT suites). This is where Hierarchical HITs MAY be of value.

So the short answer is: referrals work if the referral is an IP address. 
referrals MAY work if the referral is a HIT.

> in whatever we put on the standards track.

We all think this and see regular cases where things work only 
sometimes. I feel that in HIP we have found that it makes more things 
work (like IPv4 dumb apps running over IPv6 networks) than it makes 
things hard.

Perhaps the abouve discussion can be captured in one of the HIP 
documents if it is already not there.

---

From: Jan Melen <[email-masked]>
Date: Wed, 5 May 2010 19:28:52 +0300

Hi,

To me the new charter looks good. For referrals I don't see any big problems as mentioned already by Miika and Bob we have gained quite a bit experience on how much of an problem the referrals are and according to that experience there is only very few cases where they cannot be made to work, in all other cases the referrals can be resolved through mechanisms described by Bob.

Of course these are issues that need to be documented in architecture and DNS documents

   Regards,
    Jan

On May 4, 2010, at 4:47 PM, Robert Moskowitz wrote:

>> What is the current state of handling applications that do referrals with HIP? Last time I looked there wasn't any useful support for this.
> 
> If the app just issues an http://<addr>/<whatever> the HIP shim MAY perform an opportunistic HIP BEX and if successful proceed with the connection over HIP. If opportunistic failed or was not configured, then the connection will occur "open". That is without HIP.
> 
> If the app issues a reverse lookup on <addr> and retrieves a DNS HI record, then again, HIP would be used for the connection.
> 
> If the referral is a HIT, then the HIP shim would need some mechanism to perform the HIT to IP lookup. One would have to ASSuME that since a HIT was provided in a referral that a lookup mechanism was provided by the server and hopefully the client will use the 'right one'. One possiblity is DHT. Another is DNS. DNS reverse lookups of HITs is a problem, as they are flat within the ORCHID prefix (well flat within the new concept of HIT suites). This is where Hierarchical HITs MAY be of value.
> 
> So the short answer is: referrals work if the referral is an IP address. referrals MAY work if the referral is a HIT.
> 
>> 
>> I think preserving that part of the Internet architecture is important in whatever we put on the standards track.
> 
> We all think this and see regular cases where things work only sometimes. I feel that in HIP we have found that it makes more things work (like IPv4 dumb apps running over IPv6 networks) than it makes things hard.
> 
> Perhaps the abouve discussion can be captured in one of the HIP documents if it is already not there.
> 
> 
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

---

From: Tobias Heer <[email-masked]>
Date: Fri, 07 May 2010 10:57:06 +0200

Hi,

> To me the new charter looks good. For referrals I don't see any big problems as mentioned already by Miika and Bob we have gained quite a bit experience on how much of an problem the referrals are…

I would like to stress that crypto agility might add some more spice to the referral issue because it may lead to transitivity problems caused by namespace fragmentation. Therefore, it is necessary to keep the number of different HIT types (i.e., signature and hash algorithms) really small and the support for the algorithms broad. Otherwise, referrals will require more sophisticated mechanisms like certificates that bind different HITs together.

BR, 

Tobias

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 18 May 2010 10:17:36 -0700

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Jan Melen
> Sent: Wednesday, May 05, 2010 9:29 AM
> To: Robert Moskowitz
> Cc: HIP
> Subject: Re: [Hipsec] New HIP WG charter proposal
>
> Hi,
>
> To me the new charter looks good. For referrals I don't see
> any big problems as mentioned already by Miika and Bob we
> have gained quite a bit experience on how much of an problem
> the referrals are and according to that experience there is
> only very few cases where they cannot be made to work, in all
> other cases the referrals can be resolved through mechanisms
> described by Bob.
>

I'd also like to support the new charter proposal, and also mention that there is some documentation about referrals in RFC 5338.

Tom