Subject: [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt

From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 19 Jul 2007 14:24:24 -0400

Caitlin Bestler wrote:
> This draft makes many assumptions about the execution environment.
> Far too many, in my opinion, for anything beyond an informational RFC.
> 
> In particular the requirements that the objects be "opaque" and
> non-copyable are problematic in embedded and/or virtualized
> environments.

   You are mis-understanding the requirements.
   The requirements are there in order to free the API developer to be able 
to  do what make sense in a multitude of environments.  An object is said to 
be opaque to make sure that the *APPLICATION* does not depend upon the 
ability to look into the object in order to function.
   An object is said to be non-copyable, in order that you do not assume that
you can copy it trivially by doing a structure copy.

   In both cases, if your choose to implement the accessor functions as 
#define macros, and the copy function as *foostruct=*barstruct, that's just fine.

   However, in a Posix environment, I can not assume that

> Not allowing the client to copy the object to another location in the
> same process, or to an entirely different process is quite reasonable.

   I don't think it says that.
   What it says is that if you have a handle in one process, that it will not 
be transparently valid in another process.   If you want to move the object 
to another process, then you have to have cooperation of the object. It's 
just like a file handle or a socket.

> But can the process itself be migrated? Are these objects expected
> to work after a Unix style fork? What if the entire IP host is
> migrated to another physical machine?

   Do sockets work after you do these things?

> What needs to be stated is what expectations there are about
> this memory. Are normal operations on the entire memory space,
> such as swap-out/swap-in and virtualization migration, compatible
> with these objects or not?

   We were also very specific in the requirements document (I think you 
didn't read it), that we never let the application processes see keying 
material. They have no business knowing about that.

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Thu, 19 Jul 2007 15:21:10 -0700

> -----Original Message-----
> From: anonsec-bounces at postel.org 
> [mailto:anonsec-bounces at postel.org] On Behalf Of Michael Richardson
> Sent: Thursday, July 19, 2007 11:24 AM
> To: anonsec at postel.org
> Subject: Re: [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt
> 
> Caitlin Bestler wrote:
>    The requirements are there in order to free the API 
> developer to be able to  do what make sense in a multitude of 
> environments.  An object is said to be opaque to make sure 
> that the *APPLICATION* does not depend upon the ability to 
> look into the object in order to function.
>    An object is said to be non-copyable, in order that you do 
> not assume that you can copy it trivially by doing a structure copy.
> 
>    In both cases, if your choose to implement the accessor 
> functions as #define macros, and the copy function as 
> *foostruct=*barstruct, that's just fine.
> 

Would you be ok with explicitly clarifying that the requirements
described are only intended for the application layer code, and are
not intended to constrain implementaion of the operating environment?

Or if there are constraints on the operating environment, to list those
separately? For example, it is concievable that there is a requirement
that the key material not be place in swap eligible memory. If so, that
should be separate and explicit. (Personally, I think that falls under
"quality of implementation" and is not something that should be
standardized,
but I could see valid arguments to the contrary).

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 19 Jul 2007 17:54:20 -0500

> > *foostruct=*barstruct, that's just fine.

Well, I would hope not -- implementing accessor functions as macros
makes the structure of the object part of the ABI, even though not part
of the API.  :)

> not intended to constrain implementaion of the operating environment?

I think it should be quite clear already that "opaque" here means "with
respect to the application" since we're defining an API.  (And
certainly when the language is compared with that of other Internet RFCs
that describe APIs.)

But adding a simple qualifier like "with respect to the application"
should be no problem.  Michael?

> but I could see valid arguments to the contrary).

Nothing in this API deals directly with cryptographic key material.

Nico
--

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 23 Jul 2007 09:40:46 -0500

> not intended to constrain implementaion of the operating environment?

I would be happy to clarify anything. In the IETF tradition, you can send 
text.  If you send patches, I will apply them.

I just want to be clear that you want me to clarify that the Application 
Programming Interface is a set of requirements on an interface that 
Applications use.

They aren't constraints on the application, or on the operating environment. 
They are constraints are the interface only.  And we aren't creating an ABI 
either, or promising that a change in the implementation of the API won't 
require a recompilation of the applications.  (It is certainly is a nice 
feature if you have, but it certainly isn't required)

> that the key material not be place in swap eligible memory. If so, that

Keys never traverse this API. That is a requirement.
Where the IPsec "kernel" puts keys is it's own business.

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 23 Jul 2007 09:42:06 -0500

> makes the structure of the object part of the ABI, even though not part

Not our problem, it's an implementation concern.
Some systems do not have ABIs. It's all one source tree.