RE: Security Use Requirements

[Joshua Tseng <jtseng@NishanSystems.com>]

Bernard,
> 
> >TLS affords the capability of securely communicating through
> >proxys.  
> 
> I think you mean NATs, no? Not sure how you'd proxy SSL
> without terminating a TCP connection. 

You would proxy SSL by having the proxy terminate the TCP connection and map
the TCP stream from the old connection to the new one.  The proxy doesn't
have to look inside the TCP stream, which of course is encrypted.

> 
> >On the other hand, IPSec is a real pain to get through
> >firewalls.
> 
> If you're talking strictly about a firewall, not a NAT, I'm
> not sure why there'd be a difference. For IPSEC you need to
> open up protocols 50/51, and UDP 500. For SSL/TLS you need
> to open up a single TCP port for the application. Either way,
> you probably need to restrict communication to iSCSI targets
> with appropriate negotiation policies installed.

The difference between IPSec and TLS/SSL is that IPSec protects at the
datagram level, while TLS/SSL protects at the TCP stream level.  Passing
through a firewall boundary will most likely involve changing the IP
datagram itself (at least in the inbound direction), such as to perform NAT.
Because IPSec protects the datagram, NAT and NAPT involves changing a
portion of the IPSec protected data.  Because TLS only encrypts the TCP
stream and has no knowledge of the IP datagram, it can be safely repackaged
into different datagrams without modifying the TCP stream and affecting TLS.

There are two choices to getting IPSec data through a firewall boundary:  1)
terminate the IPSec SA at the firewall and re-start a new SA on the other
side.  2)  Cut a hole through the firewall.

The first alternative is prohibitive since the firewall is doing a lot of
processing already, and it would be an administrative nightmare to set up
since its a bottleneck supporting many users.  The second choice is also an
administrative nightmare because after
a while, your firewall will look like swiss cheese.  Its also a security
issue because an observant attacker doing a port scan will notice that
protocol 50/51 and UDP 500 can get through for various IP addresses.

Josh

> 
> >If we decide that iSCSI doesn't need to go through
> >firewalls, then we could let go of TLS.  
> 
> BTW, I'd note that the IPSEC WG is currently taking up the
> issue of IPSEC address dependencies and that several proposals
> have been put forward. So I wouldn't rule out being able to
> traverse NATs with IPSEC at some point in the future. 
> Unfortunately however, all of those proposals
> interfere with the ability to do HW acceleration :(
>