RE: IPSEC target and transport mode

["Bernard Aboba" <bernard_aboba@hotmail.com>]

>Implications : 1) Anything less than end-to-end is outside the scope >of 
>IPS security, hence should not be specified by this WG. In fact,
>it is orthogonal.

Correct. In fact, in -12 we are going to include explicit language making it 
very clear that the specification applies *solely* to end-to-end usage of 
IPS protocols, not to use of IPsec security gateways. There are already 
specifications describing usage of VPN gateways, there is no need to 
duplicate (and contradict) this in IPS WG.

>There is no need to claim compliance with "IPS security" in
>that case. The WG should not encourage this usage, if it still
>believes in the above "prime directive".

Indeed, such usage is irrelevant to IPS security and cannot be used to 
demonstrate "two interoperable implementations" where the endpoints won't be 
implementing IPS protocols.

>I hope we have all the TUNNEL qualifiers to enforce end-to-end.

What is most interesting about this is that the folks providing software 
iSCSI support operating systems, as well as HBAs and Targets seem to be 
lining up for Transport mode, but so far we haven't heard much from vendors 
with an interest in producing a tunnel mode endpoint product. It seems that 
the interest in tunnel mode is primarily in interoperating with separate 
IPsec security gateways, which is out of scope.

>Without getting into implementation details, as an implementer of
>multi-Gig silicon, I can assure you that implementing security gateway >is 
>a very expensive problem compared to end-point security which can >be 
>implemented as part of a highly  integrated silicon. Cost is after >all one 
>of the big reasons why we are here talking about iSCSI.

And one of the primary reasons why security is being required so that 
implementations can build it in for low cost.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.