RE: IPSEC target and transport mode

["Mukund, Shridhar" <Shridhar_Mukund@adaptec.com>]

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.