Subject: [Hipsec] Draft status

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 13 Mar 2006 08:38:24 +0200

Folks,

FYI: you can find the current status of our WG items at the following site:
http://hip.piuha.net/drafts/

As you can see, as soon as the Security area directors propose somebody 
to perform the Belovin-Resorla analysis on the main spec, we will be 
able to request the publication of all our current WG items.

Cheers,

Gonzalo

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

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 13 Mar 2006 15:15:44 -0800

Gonzalo, could you please clarify a procedural question?  A number of
our drafts have dependencies (both "normative" and "informative") on
I-Ds, some of which may or may not live on as RFCs.  What happens when
we request publication of our I-Ds as experimental; will they be held up
in RFC Editor's queue pending publication of normative references,
informative references, etc.?  Should experimental drafts even
distinguish between normative and informative references?

If there is an RFC where this is defined for experimental drafts, can
you please point me to it?

Thanks,
Tom 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Sunday, March 12, 2006 10:38 PM
> To: HIP
> Subject: [Hipsec] Draft status
> 
> Folks,
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 14 Mar 2006 09:42:48 +0200

Hi,

RFCs-to-be are never held up due to their informative references. Only 
normative references matter for the RFC editor when it comes to 
publishing the RFC.

I am not sure whether this is also the case for experimental RFCs. I 
will try and figure it out.

In any case, distinguishing between informative and normative references 
is always useful, even in Informational RFCs. Normative references are 
the ones you need to understand in order to understand the 
specification. Informative references are nice to read, but not essential.

Cheers,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 15 Mar 2006 08:44:43 +0200

Hi,

FYI: a discussion in the IESG about this issue has started. It is not 
clear yet what the conclusion will be. I will keep you updated.

Cheers,

Gonzalo

Gonzalo Camarillo wrote:
>>> From: Gonzalo Camarillo [mailto:[email-masked]] Sent: 
>>> Sunday, March 12, 2006 10:38 PM
>>> To: HIP
>>> As you can see, as soon as the Security area directors propose 
>>> somebody to perform the Belovin-Resorla analysis on the main spec, we 
>>> will be able to request the publication of all our current WG items.
>>>
>>> Cheers,
>>>
>>> Gonzalo
>>>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 16 Mar 2006 08:26:19 +0200

>>> A number of
>>> I-Ds, some of which may or may not live on as RFCs.  
>>
Gonzalo and I looked at this yesterday in some detail.
Out of all WG drafts in HIP WG, the normative references
sections contain items of four types:

1. Already stable references such as RFCs.

2. References to drafts that have actually already been published
    as RFCs (e.g. NAI spec, some of the IPsec documents)

3. References to HIP WG's own RFCs. I would expect most
    of these to come in the natural order, e.g., arch comes first,
    base then, and then extensions building on top of base.
    No problem here, I think.

4. The one remaining exception that we were able to find
    was the KHI draft. The nature of the reference made me
    think that the WG probably wants KHI to be an RFC before
    your RFC becomes out. That is, you do no want to depend
    on a HIT format unless you are sure it doesn't collide with
    a real IPv6 address range. But its your call.

    If you do this then there is no procedural question, I think.
    For convenience of the reader I would in any case
    recommend normative/informative reference sections to
    be kept separate.

    But if KHI does not go forward and you still want to use it
    in the base RFC, then the procedural question is very relevant.
    As Gonzalo noted, the IESG is discussing what the actual
    requirement from Experimental RFCs is.

Did we miss any problematic reference? What is your take
on the KHI reference?

--Jari

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 16 Mar 2006 11:20:57 +0200

>
> What is your take on the KHI reference?

Technically, KHI (or ORCHID which is the new name) is IMHO in pretty  
good shape.

Procedurally, a problem is that I've run out of almost all IETF steam  
and can't motivate myself to care much about it.  In other words,  
from my side KHI is a half-orphan looking for a step parent.  I don't  
know about Julien's or Francis'es plans.

http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-01.txt

--Pekka

---

From: Miika Komu <[email-masked]>
Date: Thu, 16 Mar 2006 11:50:02 +0200 (EET)

> http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-01.txt

FYI: this is already known by the draft authors, but the latest published
base draft references still 00 version.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

---

From: Julien Laganier <[email-masked]>
Date: Thu, 16 Mar 2006 16:20:09 +0100

On Thursday 16 March 2006 10:20, Pekka Nikander wrote:
> Technically, KHI (or ORCHID which is the new name) is IMHO in
> pretty good shape.
>
> Procedurally, a problem is that I've run out of almost all IETF
> steam and can't motivate myself to care much about it.  In other
> words, from my side KHI is a half-orphan looking for a step parent.
>  I don't know about Julien's or Francis'es plans.

I just sent an email to int-area (cross-posted on ipv6 and hipsec) 
asking how to move forward with this draft.

Wait and see.

--julien

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 16 Mar 2006 07:45:15 -0800

> Did we miss any problematic reference? What is your take

The KHI is the main one that concerns me, because although I agree with
Pekka that it is in good shape technically, it doesn't seem to be on a
path to WG sponsorship AFAIK.  

Is KHI (ORCHID) on the agenda for discussion anywhere in Dallas meeting?

Tom

---

From: Julien Laganier <[email-masked]>
Date: Thu, 16 Mar 2006 16:20:09 +0100

Wait and see.

--julien

---

From: Tim Shepard <[email-masked]>
Date: Thu, 16 Mar 2006 23:42:28 -0500

> http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-01.txt

I just took a quick look at that draft, and unless I missed it, it
lacks a field of bits to identify the hash function being used.

BTW, I agree with the reasoning in section 4 about folding the context
ID into the hash input.

But we still need tag on the outside showing which crypto algorithm is
being depended upon to secure the binding.

> know about Julien's or Francis'es plans.

I'm thinking that this is perhaps not the best approach to deal with a
legacy application.   

Something similar, that does not necessarily need this sort of
KHI/ORCHID mechanism might be better: run the application in an
environment where its library and/or system calls are intercepted.  In
other words, make a "hipify" program that works much like the
"socksify" program can be used to make non-socks-enabled clients (of
many different protocols) talk to the internet through a socks proxy.

This then allows for a lot more flexibility in figuring out how to
make "hipify" do-the-right-thing for a legacy (non-hip-aware)
application.  For example, the calls to DNS could be noted, along with
the replies, and the context could be kept in the magic libraries that
are wrapping or diverting the system and library calls.  We wouldn't
necessarily need to squeeze HITs accross an interface that was
supposed to carry an IPv6 address (or if we do, then the magic is
entirely confined to the magic library that hipify uses, and doesn't
have to mess with the kernel).

(The socksify program that I've used is part of the dante package
which is open source and can be found at http://www.inet.no/dante/ ).

((Is this the right list for this thought?))

			-Tim Shepard
			 [email-masked]

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 17 Mar 2006 06:54:54 +0200

> being depended upon to secure the binding.

That is discussed in security considerations.  The prefix acts as  
that tag.

(I don't have time right now to consider your other comment, sorry.)

--Pekka

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 16 Mar 2006 21:58:47 -0800

> I'm thinking that this is perhaps not the best approach to deal with a

I think that the library approach you mention is valid also, and offers
different levels of granularity of invoking HIP, and different reliance
on DNS, than does an approach that uses HITs as IP addresses at the API.
Teemu Koponen mentioned that approach to me last month as well.  I would
prefer that both approaches are supportable for experimentation.

> ((Is this the right list for this thought?))

Perhaps moving future responses to HIP RG list would be appropriate
(since legacy application discussions have previously been declared out
of our current WG charter).  Please see also:
http://www.ietf.org/internet-drafts/draft-henderson-hip-applications-02.
txt

Tom

---

From: Tim Shepard <[email-masked]>
Date: Fri, 17 Mar 2006 01:22:07 -0500

> That is discussed in security considerations.  The prefix acts as  

Ah, indeed it does.  I have now read it, and it is good.

			-Tim Shepard
			 [email-masked]

---

From: Julien Laganier <[email-masked]>
Date: Fri, 17 Mar 2006 09:18:10 +0100

Hi Tim,

Thanks for your thoughts on that matter, more below...

On Friday 17 March 2006 05:42, Tim Shepard wrote:
>
> I'm thinking that this is perhaps not the best approach to deal
> with a legacy application.
>
> environment where its library and/or system calls are intercepted. 
> In other words, make a "hipify" program that works much like the
> "socksify" program can be used to make non-socks-enabled clients
> (of many different protocols) talk to the internet through a socks
> proxy.
>
> application.  For example, the calls to DNS could be noted, along
> with the replies, and the context could be kept in the magic
> libraries that are wrapping or diverting the system and library
> calls.  We wouldn't necessarily need to squeeze HITs accross an
> interface that was supposed to carry an IPv6 address (or if we do,
> then the magic is entirely confined to the magic library that
> hipify uses, and doesn't have to mess with the kernel).

I used this approach in the past to implement the client side of RSIP 
(RFC3103). Hence I naturally thought to use it with HIP as well. It 
has however a certain number of issues, amongst which the two mostly 
prominent are:
	- does not work with setuid programs.
	- If per-socket context has to be kept (e.g. based on DNS queries) in
	  libraries, when to delete it? Some sockets are never closed,
	  program just exit after fork and service.

I never completely figured out how to solve these _and_ staying 
entirely in libraries, hence I tend to think that one has to go in 
kernel too. This end up with too much unwanted complexity, IMHO.

The KHI/ORCHID approach has the advantage that it is both simple and 
working. We just want IANA not to allocate that prefix so we could 
use it safely as a tag saying that HIP is to be used.

Cheers,

--julien

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 17 Mar 2006 21:40:13 +0200

> have to mess with the kernel).

I don't think whether you use a library or patch system calls really  
makes any difference.  The problem stems from the potential confusion  
cause by applications "leaking" ORCHIDs, e.g., as they do referrals.   
There is little you can do about that, independent on how you  
implement the stuff locally.

See the second and third paragraph in Section 1.1.

--Pekka