Subject: RE: [rddp] rddp security and nfsv4

From: "Mukund, Shridhar" <[email-masked]>
Date: Tue, 26 Nov 2002 15:56:10 -0800

John,

I share your concern ...

> Now Caitlin brings up the point that DDP
> <Snip>
> "is supposed to run over IP transports: especially SCTP and TCP.
> ...
> 
> So whether IPsec is present or not is just not relevant to 
> DDP, anymore
> than whether Ethernet or ATM is the L2 protocol. DDP rides 
> just above L4.
> DDP and IPsec should both be blissfully ignorant of each other."
> <Snip>
> 
> I am not sure that view removes the rddp workgroup from ...

DDP has as much to do with IPSec as iSCSI and other IP 
storage protocols. It should provide continuity of the security 
envelope and protocols such as RDMAP should define the usage 
rigorously. We may want to reuse some of the good work done in 
the context of IP storage security.

IPSec is like a pair of socks. For instance one could choose to:
  - be content with just IP flow security.
  - pull up their socks and secure TCP connection.
  - pull it up a tad bit further and secure iSCSI session.
... or is it like a pair of stockings with garter belt? Hmmn :-)

I believe we need to go beyond the elegance of orthogonality:-), 
and consider how the vital parts of DDP and RDMAP will be secured,
when using IPSec.

-Shridhar Mukund

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 27 Nov 2002 11:17:24 -0600

The problem with addressing the interoperabilty of RDDP and
fulll security is that there are simply too many viable
scenarios. I will list several in this memo. The point is
not to attempt to address them all, but rather to point out
the futility of attempting to do so. I firmly believe that
the goal of the group should be to ensure that the local
interface is adequately defined so that *it* does not create
new security holes. However providing true security will
always remain a ULP issue.

What level of security is appropriate is ULP specific: wire
transfers and oil-lease bidding plans require one level,
delivery of unsecure public documents another.

The granularity of security also varies: securing site to
site, securing host to host, securing application to
application or securing a specific transfer.

Scenario 1: Private network

A corporate network is within a secure room. All hosts
within the room are under a sigle system administrator.
There are no unlabeled or open ports within the room where
an eavesdropping device could be attached.

In such an environment, NIC enhanced security is a waste.

Scenario 2: heavily secured data center.

The data center is physically secure, with guards, backup
power, multiple external data lines etc.

Internally, every Ethernet link is to a controlled switch
that enforces VLAN security. No Ethernet frame not
authorized for the destination is allowed on the link into
any client cage. No IP packet is accepted from any client
cage with a forged header.

Traffic between a client's machines within the data center
are never seen by any other client. Only client machines
designated to accept outside connections will receive any
packets from outside the client's local VLan.

In such an environment adding security to a local host's
RNIC is a waste of time and resources. It is essentially a
private network, even if the facilities are shared.

Scenario 3: Road Warrior

Laptop must transfer data back to home network, over a
variety of different networks. Uniform security must apply
whether the connection is established via the wireless port,
the Ethernet port or the dial-up modem.

Scenario 4: Public Server

Server deals with many connections received over the public
network from a wide variety of clients. All connections
arrive via a single high speed RNIC or its backup.

Such a server would truly benefit from RNIC encryption,
espeically if standardized such that all of its clients
would adopt the same solution.

Scenario 5: Unsecure Corporate Network

Corporate network is externally secured by a firewall. VPNs
are used to safely connect remote sites.

User authentication is handled on a per department basis,
and at least a few departmentsare known to be lax in
deleting accounts of terminated employees. Additionally,
very office/cube has at least 2 Ethernet Jacks which feed to
uncontrolled Ethernet switches.

Such an environment would benefit from automatic session
encryption that ensured privacy of existing connections. But
the environment lacks the administrative infrastructure to
support authenticating the identies of both ends prior to
connections establishment.

Scenario 6: Better Corporate Network

Add proper user/host authentication to Scenario #5, but
keepthe uncontrolled Ethernet switches. Pre-connection
authentication of both ends is now viable.

Scenario 7: Sealed Storage

Host wishes to have the RNIC encrypt data writeen to remote
storage device on write, and to decrypt it on read. The
remote storage device never needs access to the true data,
and is never given the keys.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp