Subject: [[email-masked]: Re: security text in LINK]

From: Phil Karn <[email-masked]>
Date: Fri, 20 Jul 2001 11:57:21 -0700

Dan meant to send this to the list. --Phil

------- Start of forwarded message -------
To: Phil Karn <[email-masked]>
Subject: Re: security text in LINK 
Date: Fri, 20 Jul 2001 11:03:48 -0400
From: Dan Grossman <[email-masked]>

> Okay, in the spirit of compromise, I have ripped out much of the text
> in the security section of LINK and replaced it with the following
> (with unchanged lines for context). Please comment ASAP; we're coming
> down to the wire here.
I'm still kind of wondering whether we don't have consensus with one dissenter 
(who also happens to be editor), or whether there's a genuine division of 
views.  Nonetheless, responding to the editor's current proposal, there 
remains considerable bias and much useful text has been lost.  Proposed 
corrections.

Nonetheless, end-to-end security mechanisms are not used as widely as might be 
desired. There are a variety of reasons for this, most of which are out of the 
scope of this Memo.  One relevant reason is that end users and application 
designers often make an implicit assumption concerning the security of all 
subnet hops along all possible paths.  They assume that all subnetworks 
are designed so as to require an outside attacker to surreptitiously obtain 
access to a facility which is nominally physically secured.  For example, to 
attack point-to-point fibers, a DSL or the PSTN, an attacker would probably 
require physical access to a cross connect.  To attack an Ethernet contained 
entirely in a single premises, an attacker would need to obtain access to that 
premises.  The assumption is that such attacks would require sufficient skill, 
 determination and assumption of risk as to render the threat of attack to be 
acceptable.  This property is sometimes called "wired-equivalent security".

Dependence solely upon wired equivalent security is risky.  Many of the 
subnets contemplated by this Memo are not inherently physically secure. The 
Internet architecture does not allow applications to know the security 
properties of the subnets along a path. Nor do subnetworks have any way to 
encourage the use of end-to-end security.  This is consistent with the 
end-to-end principle. The implementation and operation of the Internet and its 
subnetworks has been greatly simplified by leaving to the hosts responsibility 
for host access control, application data confidentiality and integrity.

The PILC working group could not reach consensus on whether subnetwork 
designers should be actively encouraged to implement mechanisms to protect 
user data. One point of view holds that as a pragmatic matter, the IETF cannot 
enforce the use of end-to-end mechanisms.  Indeed, the value of assets to be 
protected and the assumed threats sometimes do not justify the use of 
end-to-end mechanisms, so long as wired equivalent security exists for all 
subnets.  In any event, the marketplace would regard any subnet that did not 
provide a degree of security to be gravely deficient.  Those who hold this 
viewpoint would recommend that subnets implement mechanisms that achieve a  
degree of security roughly commensurate with that of a point-to-point links.  
They further recommend that subnet designers exercise great care in designing 
these mechanisms, in the knowledge that applications will improperly and 
excessively rely upon them.

Another view holds that subnetwork security mechanisms, especially
when weak or incorrectly implemented [BGW], may actually be
counterproductive.  Such mechanisms can lull end users into a false
sense of security, diminish the incentive to deploy effective
end-to-end mechanisms, and encourage "risky" uses of the Internet that
would not be made if users understood the inherent limits of
subnetwork security mechanisms.  Those who hold this viewpoint would recommend
that subnets make no attempt to provide security for end-to-end communications.

We can recommend that subnetwork designers be as candid as possible with 1) 
the details of any security mechanisms they implement to protect user data; 
and 2) the inherent limits of even the most secure mechanism when it is 
implemented in a subnetwork rather than on an end-to-end basis.
 
A much stronger case exists for another role for subnetwork security: the 
protection of the subnetwork itself in keeping with the "placement
------- End of forwarded message -------

---

From: Dan Grossman <[email-masked]>
Date: Mon, 23 Jul 2001 14:02:56 -0400

Phil, thanks for re-forwarding.  It would have been a pain to reconstruct.

Group,
Phil expressed some concern (off the list) about the term "wired equivalent 
security".  In response to that, I'd propose a minor change:

>  The assumption is that such attacks would require sufficient skill, 
                                                                            ^
(a somewhat misleading term, which is used here only because it is already in 
common use).