[anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt
Nicolas.Williams at sun.com (Nicolas Williams) Mon, 18 June 2007 21:03 UTC
From: "Nicolas.Williams at sun.com"
Date: Mon, 18 Jun 2007 16:03:13 -0500
Subject: [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt
In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D0439AF95@NT-IRVA-0750.brcm.ad.broadcom.com>
References: <E1I0NEg-00087m-4f@stiedprstage1.ietf.org> <1EF1E44200D82B47BD5BA61171E8CE9D0439AF95@NT-IRVA-0750.brcm.ad.broadcom.com>
Message-ID: <20070618210313.GL24098@Sun.COM>
On Mon, Jun 18, 2007 at 01:47:03PM -0700, Caitlin Bestler wrote: > This draft makes many assumptions about the execution environment. > Far too many, in my opinion, for anything beyond an informational RFC. Such as? > In particular the requirements that the objects be "opaque" and > non-copyable are problematic in embedded and/or virtualized > environments. As long as interfaces are provided for copying opaque objects that may need to be copied that should suffice to address the concern. > Not allowing the client to copy the object to another location in the > same process, or to an entirely different process is quite reasonable. > 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? Some RFCs that define APIs never described fork- or thread-safety. For any interface like this one, however, I think that fork- and thread- safety must be addressed, even if to say that it is undefined. > These types of issues are exactly the sort of implementation details > that are best not dealt with by the IETF, but the plain reading of > the draft could seem to apply to all of them. I think discussions about the propriety of the IETF doing API work are outside the scope of this WG. > I see no problem with requiring that the API MUST NOT require > the application to directly manipulate the object. You could > mention that applications SHOULD NOT manipulate the object > by other means, but that belongs in to "application SHOULD > NOT zero-out random portions of physical memory" category. Opaqueness, IMO, can (and in this case should) cover the "size" of the object in memory -- the application need not know; as fas as it's concerned the object has a pointer- or integer-sized handle and that's that. > 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? I think swapping and paging are out of scope here. How many APIs do you know of that are not swap-safe?! Migration should be like suspend/resume: a socket may become disconnected, a connection latch may be broken, etc... > My hunch is that from a security perspective, the host is the host > and it really does not matter to the remote peer how opaque and/or > protected any specific data object is. These concepts merely promote > robust and readable code. Writing robust wonderful code is of course > to be encouraged, but I don't think we can make it a MUST. I agree with the first sentence; most API details are local details, not protocol details. I disagree with the rest. Nico --
- [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt Internet-Drafts@ietf.org
- [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt Caitlin Bestler
- [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt Nicolas Williams
- [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt Caitlin Bestler
- [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt Nicolas Williams
- [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt Michael Richardson
- [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt Caitlin Bestler
- [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt Nicolas Williams
- [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt Michael Richardson
- [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt Michael Richardson