Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-10 Thread David Borman

On Sep 8, 2012, at 8:36 PM, Joe Touch  wrote:

> 
> 
> On 9/8/2012 11:59 AM, Melinda Shore wrote:
>> On 9/8/12 10:51 AM, Joe Touch wrote:
>>> Nothing about an ID is inherently obsolete or out of date after 6 months
>>> except its being publicly available on authorized sites (up until now).
>> 
>> I think this is absolutely incorrect.  Internet Drafts are IETF
>> documents, and expiration changes the relationship between the draft
>> and the IETF.  I have to say that I think it's terribly unprofessional
>> not to hang onto archival material
> 
> Draft != archival
> 
> Or do you keep copies of all versions of papers you publish, including the 
> ones submitted for review? In case lawyers might need it, or for the benefit 
> of the public?
> 
>> and frankly it's in the interest
>> of the IETF as an *open* standards organization to keep archival
>> material accessible.
> 
> Agreed.
> 
>> When you're working on a problem that's been around forever and
>> still hasn't been solved (like, oh, I dunno - firewall/NAT traversal?),
>> easy access to expired drafts is an enormous help.
> 
> The needs of the community - including the lawyers - do not outweigh the 
> rights of the author or the agreement they make with the IETF to date.
> 
> The original point of having drafts expire seems to have been forgotten here. 
> That's a pity. It did have a reason, and it was useful.

The original reason for expiring drafts, along with giving them long,
complicated names that includes the word "draft", was to keep them
from being referenced as if they were standards, based on experience
gathered from the short lived IDEA document series.  I don't think
that having an archive of expired drafts weakens that original goal.

-David Borman

> 
>> Would you be more comfortable if there were some sort of visual
>> flag that a draft had expired?
> 
> If you post it, it's not expired. There's no point in claiming otherwise.
> 
> Joe

--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.


Re: Retention of blue sheets

2009-07-31 Thread David Borman
Way back in the early days of the IETF, the email address was used for  
adding people to the mailing list for the WG.  But that was a long  
time ago, when many mailing lists weren't so automated. :-)

-David Borman

On Jul 31, 2009, at 9:06 AM, Pekka Savola wrote:


On Fri, 31 Jul 2009, Brian E Carpenter wrote:

I agree with Alissa that having an explicit privacy policy would be a
good idea, but the fact of participation in an open standards process
certainly cannot be considered a private matter. Exactly the  
opposite,

in fact.


Indeed, but why do the blue sheets ask for an email address?  I'm  
not interested in receiving any mail (e.g. product advertisements  
loosely related to the IETF protocols) based on my writing my email  
on the blue sheets.  I accept it's good for disambiguation though  
asking for affiliation might achieve the same.  If anyone would be  
able to get the blue sheets, they probably shouldn't get the email  
addresses. Having to write a privacy policy would require ironing  
out these small details which might be a goog thing.


--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Secdir Review of draft-stjohns-sipso-05

2008-10-02 Thread David Borman
I totally agree with Mike.  If you've never dealt with a multi-level  
security (MLS) system, let's just say they are non-trivial, and this  
issue with TCP ports is only one part of the overall system.  Just the  
act of labeling the IP packets effectively creates multiple virtual  
networks, and the place where they clash is in the MLS host.  As Mike  
said, those that aren't MLS aware don't have to do anything  
different.  But explicitly calling this out for MLS hosts, as this  
draft does, seems to me to be perfectly reasonable.


        -David Borman

On Oct 2, 2008, at 1:57 PM, Michael StJohns wrote:


Hi Joe -

A quick disclaimer - although I was complicit in allowing this draft  
to be resurrected from 1992, I have had very little to do with it on  
this cycle.



At 02:18 PM 10/2/2008, Joe Touch wrote:

First, I don't agree with this document's recommendation in section  
7.3.1.


TCP's current definition of a connection is:

  local IP address
  remote IP address
  local port
  remote port
  protocol (e.g., TCP)

I don't agree that treating each sensitivity level as a separate  
virtual
network (Sec 3 of this ID) is the appropriate analogy. If that were  
the

case, we'd need to redefine every Internet protocol to understand the
pair [address, sensitivity level] as an identifier, and that is not
realistic. Further, if we did need to do such an extension, there are
other equally (or arguably more) worthy candidates, notably VPN-ID.


The issue isn't so much the network, but how the host views it and  
deals with resources that might otherwise be in multiple sensitivity  
domains.


Consider a multi-level host that runs at both SECRET and TOP  
SECRET.  Consider that it wants to run some protocol to send and  
receive data from other hosts, some multi level, some single level  
SECRET and some single level TOP SECRET.


A single level process at TOP SECRET does a passive open of the port  
(call it 666) and waits for connections.
A second single level process at SECRET also attempts to do a  
passive open to the same port - but gets blocked because the port  
resource is being held by the TOP SECRET process.  The SECRET  
process now has one bit of information about the TOP SECRET part of  
the host.  By grabbing and releasing port resources, the TS process  
can signal data to processes at lower security levels.


In 1987 I used a rough analog of the old 1822 protocol using TCP  
ports to build a fairly fast covert channel between two processes at  
different security levels on the same host.


The fix was to virtualize TCP so that there was a complete set of  
TCP ports per distinct security domain.


You could try doing this by writing the processes as multi-level,  
but that means you can't use off the shelf code for things like a  
mail server that only wants to handle mail of a specific security  
level.


Mostly, this only applies to protocols just above IP which have  
distinguishable host resources. In other words, TCP, UDP and their  
ilk.




I.e., I don't think this needs to update 793 - it needs to redefine  
the
Internet architecture in places like 1122, 1123, and 1812, and flow  
down

through all protocols they impact to make this sort of change, and I
don't see a reason to do so solely for this issue.

Overall, I see no reason why 793's current rules aren't sufficient to
emulate the desirable separation of sensitivity levels without  
extending

this to true virtualization. I.e., the current rule (in 793, sec 3.6,
paraphrased):

  - match the levels proposed by both ends of the connection
  where there is a mismatch, terminate the connection

I.e., I don't see how to extend TCP to support concurrent connections
with matching connection identifiers on different sensitivity levels
without rearchitecting the entire Internet. AFAICT, it's sufficient  
to
allow each TCP connection to have exactly one sensitivity level, as  
is

already currently required.


Not quite the point.  If you have a single level process reserving a  
TCP port, then the port has sensitivity level of the process.  If  
you have a multi-level process reserving a port then the port can  
have one, some or all of the sensitivity levels of the process.   
Each instantiation of a connection does have one and only one  
sensitivity level.


The changes don't have to happen on the entire internet, just those  
hosts and routers that are CIPSO aware AND multi-level.  If the host  
is CIPSO aware (or for that matter IPSO aware), but not multi-level,  
it's just looking for the specific label and doesn't have to deal  
with the multiple virtual network cruft.




Joe

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjlEGkACgkQE5f5cImnZruKoQCfZ9qnOBIRZTCNzsUWzfB39HdL
AicAn1kLwAQdQ087x9H