BTNS draft Agenda for IETF69

Folks,

Below is a draft agenda for IETF 69 based on our 
current working items.

Please sends us changes/addons.

-- julien / btns co-chair

--------------------------------------------------------- 
Better-Than-Nothing Security (btns)

Agenda at IETF-69
====================================

Chairs:
Love Hornquist Astrand <lha <at> it.su.se>
Julien Laganier <julien.ietf <at> laposte.net>

AGENDA:

Preliminaries - Chairs

Connection Latching - Nico Williams

draft-ietf-btns-connection-latching-01.txt

IPsec APIs - Michael Richardson & Miika Komu

draft-ietf-btns-ipsec-abstract-api

I-D ACTION:draft-ietf-btns-c-api-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Better-Than-Nothing Security Working Group of the IETF.

	Title		: IPsec Application Programming Interfaces
	Author(s)	: M. Komu, et al.
	Filename	: draft-ietf-btns-c-api-01.txt
	Pages		: 15
	Date		: 2007-7-9
	
IPsec based security is usually transparent for applications and and
   they have no standard APIs for gathering information about protected
   network connections and for detecting the underlying security
   mechanisms.  This document specifies an API that increases the
   visibility of IPsec to applications.  The API allows applications to
   allow BTNS extensions, control the channel bindigs, and control also
   other security properties related to IPsec.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-btns-c-api-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 

BTNS draft agenda for IETF69 posted

Folks,

The draft agenda has been posted:

<http://www3.ietf.org/proceedings/07jul/agenda/btns.txt>

Please sends us changes/addons before July 16th.

-- julien / btns co-chair
_______________________________________________

Re: I-D ACTION:draft-ietf-btns-c-api-00.txt

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.

Re: I-D ACTION:draft-ietf-btns-c-api-00.txt

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

Re: I-D ACTION:draft-ietf-btns-c-api-00.txt

On Thu, Jul 19, 2007 at 03:21:10PM -0700, Caitlin Bestler wrote:
> >    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.

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

> >    However, in a Posix environment, I can not assume that
> > 
> 
> 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?

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

Re: I-D ACTION:draft-ietf-btns-c-api-00.txt

Caitlin Bestler wrote:
> 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?

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)

> 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

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

_______________________________________________

Re: I-D ACTION:draft-ietf-btns-c-api-00.txt

Nicolas Williams wrote:
>>>    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.
> 
> 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 our problem, it's an implementation concern.
Some systems do not have ABIs. It's all one source tree.

_______________________________________________

comments on the BTNS core I-D

Sorry I didn't get these out sooner.

Steve

_______________________________________________

Re: comments on the BTNS core I-D

This document has already been submitted for AD review.  Chairs, if
you want me to return to the WG then please instruct me to do so.

_______________________________________________