Re: IPSEC target and transport mode

[Bill Strahm <bill@strahm.net>]

Ok, I have been railling against this for quite a long time in this WG, 
obviously unsuccessfully... 

Why is the IPS WG getting into the process of specifying security POLICIES
at all.  I am very concerned that we are trying to specify usage policies
rather than protocol definitions that users can use to create the 
unique security requirements for each solution...

Why does this WG even CARE how a network administrator sets up his security
policy, why do I require tunnels to have outter=inner, why do I care if
SAs are carrying just IPS traffic...  These are all network policy descisions
NOT protocol design issues.

I have been a firm believer in saying that all our security section should
contain is that products MUST implement IPsec, and here are some hints
at what a security policy might be that have the correct properties to cover
IPS traffic...  If this is all that we did, we can be done with all of these
silly arguements and just get on to approving the standards and let the 
security area handle the protocols that they have created.

Bill
On Fri, Apr 05, 2002 at 12:07:44PM -0800, Mukund, Shridhar wrote:
> 
> Dear IPS Chair,
> 
> It does not seem like you yourself are happy about the outcome of the Tunnel
> vs. Transport
> debate, but are compelled to reach that decision due to time(?) pressure :-)
> I request that we
> seek advise from Jeffery Schillers, Steve Bellovin and possibly saag just
> one ... more time. 
> I would like to hear their wisdom.
> 
> I believe the IPS security effort started with the following:
> 
>   A. Prime Directive: IPS Security MUST be implemented. It should be
> "end-to-end".
> 
>       Why? Jeffery Schillers
> http://www.ietf.org/internet-drafts/draft-ietf-saag-whyenc-00.txt
> 
>   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.
>                           Ideally, one ought to implement "additional"
> nested tunnel for VPN, 
>                           firewall etc. over and above end-to-end.
>                       2) It is fair game to implement less than end-to-end (
> firewall, gateway etc.) 
>                           in lieu of end-to-end, if their customers are
> happy with it. 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".
> 
>   B. RFC2401 says "MUST implement" TRANSPORT to enable end-to-end and "MUST
>        implement" TUNNEL for security gateway. Obviously, a host(IP end
> point) has 
>        to "MUST implement" both TUNNEL and TRANSPORT since it has to do
> both.
> 
>   Implication of A + B : Applying the "prime directive" along with RFC2401,
> the subset of
>   requirements we can rationally come up with is the following:
> 
>          Right Option : "MUST implement" TRANSPORT, "SHOULD use" TRANSPORT
> 
>          OK Option    : "MUST implement" TRANSPORT, "SHOULD use" TRANSPORT
>                               "MAY implement" TUNNEL with additional
> qualifier that the SA's
>                               have to be end-to-end, outer=inner, ... etc
> 
>          Tolerable Option : "MUST implement" TUNNEL and TRANSPORT with the
> above 
>                                     qualifier for TUNNEL.
> 
>    The security enthusiasts graciously and unanimously accepted the
> "tolerable option" at 
>    Huntington Beach. Yet we are now in this last hour muddle with:
> 
>           Wrong Option : "MUST implement" TUNNEL and "MAY implement"
> TRANSPORT.
>                                  I hope we have all the TUNNEL qualifiers to
> enforce end-to-end.
> 
>    ... and the clock is ticking ...
> 
>    From your minutes ..., I am wishfully interpreting (pardon me for this
> :-) Steve Bellovin 
>    as saying:
>    "IPsec Encapsulation:  Tunnel MUST, Transport MAY" is "OK" 
>   ... if we have a _strong_ and _compelling_ technical reason 
>   to violate RFC2401. Otherwise, complying with RFC2401 is the
>   right thing to do.
> 
>   I am not saying that tunnel can not be used for end-to-end. I do sometimes
> drive my
>   cement truck to work :-)
> 
>   My worry is that this "Wrong Option" is actually a Trojan horse that will
> undermine and
>   kill the spirit behind the "prime directive". If flexibility of allowing
> non-end-to-end is what 
>   we really desire, we might as well disband the IPS Security WG and require
> "should 
>   implement security in any which way that suits the application"( pardon me
> for the 
>   sarcasm :-). If you read some of the recent emails from yourself, John
> Huffurd, Paul Koning
>   where you are describing how one may want to use "IPS security" for
> not-end-to-end, you 
>   are inadvertently falling prey to that Trojan horse and alluding to the
> degeneration of the 
>   "prime directive" :-)
> 
>   From my understanding, all the technical arguments "for" TUNNEL have been
> addressed
>   and all shot down, including the original concern about FCIP being thought
> of as gateway
>   while it actually is an IP-end-point.
> 
>   What remains then is "how do I grow the market for existing VPN, firewall
> like devices ?" :-)
>   As per the prime directive, we do not prescribe it for securing iSCSI
> connection. Period. We 
>   could however, secure flows as usual (outside the scope of IPS security),
> as may be required 
>   by customers. Existing devices that address end-point-security per RFC2401
> are already 
>   OK. I believe that IP Storage security need is going to boost the need for
> VPN and  firewall 
>   devices anyway and allow the security players to address this yet another
> market segment 
>   with low cost solutions :-) :-)
>   
>   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.
> Granted, most
>   implementation/security complexities are around stuff like yIKEs!
> 
>   Regarding consensus ..., is it possible that most of the "tunnel"
> enthusiasts 
>   a) do not want to see security as part of IPS anyway, and/or
>   b) want security, but not end-to-end.
>   That can explain how we went from "unanimous" to 8-to-20_that_just_flipped
> :-)
>   It seems reasonable to filter out their votes when it comes to vote on
> this issue  :-)
>   On the list, I do not see any strong argument for straying away from
> RFC2401.
> 
>   I am not an idealist... But I do not see any strong and compelling reason
> to mutate
>   a working RFC2401 at this late hour, esp. when it hurts performance,
> frustrates
>   OS partners and dilutes the spirit behind the very purpose of IPS
> security.
> 
> -Shridhar Mukund
> 
> David: I did not want to post this on saag without your permission
> considering the time
> pressure we are under. You, Jeffery or Steve may choose to do so, if
> required.
>   
> 
>                        
>