[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [saag] RE: IP Storage and IPsec encapsulation
Aha, found the hornet's nest ...
> >The configuration of interest is:
> >
> >|--------------------------| |---------------|
> >| IP Storage without IPsec |----| IPsec gateway |-->
> >|--------------------------| |---------------|
> >
> >Where the link between the two boxes is not attached
> >to anything else. The only IPsec implementation on this
> >end of the connection is in the gateway, and the only
> >link in the above diagram that complies with the protocol
> >requirements is the link on the right hand side of the
> >gateway. The gateway does not implement transport
> >mode, hence the interest in tunnel mode.
>
> IP Storage really really needs end-to-end security IMNVHO.
>
> So I think the above is just a bogus implementer being lazy
> rather than a valid security architecture. The above can't
> provide the kinds of end-to-end security properties that
> one needs for IP Storage applications.
Could you be specific about what can't be provided, and how
requiring transport mode would force/encourage it to be provided?
> The IETF went through a similar discussion in the NFS context,
> concluding in that case that fine-grained end-to-end security
> properties were needed. The above can't even coarsely approximate
> what NFS (which has lots of similarities to IP Storage otherwise)
> was required to provide to be on the IETF standards-track.
NFS is not the best analogy because NFS is an RPC-oriented protocol
for which it makes sense to provide security at the granularity of
individual RPCs, as a (user) identity can be associated with each
RPC. The IP Storage protocols are TCP/IP encapsulations of SCSI
and Fibre Channel -- these are session-oriented protocols for which
it does not make sense to provide security at a granularity finer
than a session as a (machine) identity is associated with each session,
but no other finer-grain identities are associated with individual
commands/messages/operations/etc. within a session.
In the above diagram, a separate phase 2 SA would be required for
every TCP connection (i.e., the typical security gateway behavior
of running all traffic destined for the same remote gateway through
the same tunnel would not be compliant); this is at least session
granularity, and potentially finer grain depending on how sessions
are formed and how phase 2 SAs are associated with phase 1 SAs.
Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA 01748
+1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500
black_david@emc.com Mobile: +1 (978) 394-7754
---------------------------------------------------
> -----Original Message-----
> From: RJ Atkinson [mailto:rja@inet.org]
> Sent: Wednesday, November 28, 2001 7:44 PM
> To: Black_David@emc.com
> Cc: ipsec@lists.tislabs.com; saag@mit.edu
> Subject: Re: [saag] RE: IP Storage and IPsec encapsulation
>
>
> At 17:47 28/11/01, Black_David@emc.com wrote:
> >The configuration of interest is:
> >
> >|--------------------------| |---------------|
> >| IP Storage without IPsec |----| IPsec gateway |-->
> >|--------------------------| |---------------|
> >
> >Where the link between the two boxes is not attached
> >to anything else. The only IPsec implementation on this
> >end of the connection is in the gateway, and the only
> >link in the above diagram that complies with the protocol
> >requirements is the link on the right hand side of the
> >gateway. The gateway does not implement transport
> >mode, hence the interest in tunnel mode.
>
> IP Storage really really needs end-to-end security IMNVHO.
>
> So I think the above is just a bogus implementer being lazy
> rather than a valid security architecture. The above can't
> provide the kinds of end-to-end security properties that
> one needs for IP Storage applications.
>
> The IETF went through a similar discussion in the NFS context,
> concluding in that case that fine-grained end-to-end security
> properties were needed. The above can't even coarsely approximate
> what NFS (which has lots of similarities to IP Storage otherwise)
> was required to provide to be on the IETF standards-track.
>
> Ran
> rja@inet.org
>
>
>