Subject: RE: Should IP Security be Optional?

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 4 Mar 2002 18:33:07 +0100

Mike, 

Good points. So are you saying we should 
mandate ESP and AH but it's ok not to mandate
IKE? and perhaps use something else for 
key distribution? 

I'm just trying to understand how to address
these comments in the draft. 

Hesham

  > -----Original Message-----
  > From: Michael Thomas [mailto:[email-masked]]
  > Sent: Monday, March 04, 2002 6:08 PM
  > To: OKABE Nobuo
  > Cc: [email-masked]; [email-masked];
  > [email-masked]; [email-masked];
  > [email-masked]
  > Subject: Re: Should IP Security be Optional?
  > 
  > 
  > 
  > So, talking about making exceptions to the MUST
  > IMPLEMENT aspect of ipsec on v6 strikes me as a
  > really poor idea. First of all, a minimum
  > implementation of IPsec to fulfill the mandatory
  > requirements is quite small -- we're not talking
  > about IKE here. Far more problematic, however, is
  > the lack of a common security substrate on the
  > net. We know what that means in practice: no
  > security at all in the vast majority of cases.
  > Requiring IPsec at least gets us to the point
  > where two nodes can have a secure conversation
  > with any mix of traffic instead of the current
  > mishmash of incomplete and often insecure other
  > mechanisms (read: nothing in many important
  > cases).
  > 
  > I think I also disagree with Jari's
  > characterization of fixed-purpose devices. The net
  > is not the PSTN with exactly one application.
  > Once you've enabled IP, you have instant access to
  > zillions of applications, and a zillion more to
  > come. While small boxen certainly will only
  > implement a small fraction of those applications,
  > we have not one clue *which* ones they'll be! Some
  > may very well be UDP based, and thus TLS won't be
  > of any use. So we'll be back to the same state of
  > trying to shoe-horn protocols to meet security
  > requirements via unnatural acts with TLS, often
  > ill-conceived application layer security, or just
  > plain ignoring the problem and hoping for the
  > best.
  > 
  > *Please* let's not go there. For the scant amount
  > of flash and ram that IPsec requires we get a
  > common baseline. This is desparately needed so
  > that we at least have something to proceed from
  > rather than the current chaos. IPsec is the
  > security analog to TCP's reliable transport.
  > Without TCP, protocol and application development
  > would have been severely hampered. TCP's utility
  > amongst other things was to simplify networking so
  > that people other than net weenies could write
  > applications. The same, I'm afraid, is true of
  > crypto -- maybe even worse, because a cursory
  > understanding of transport wasn't all that hard to
  > come by even 20 years ago, whereas there's not a
  > surer way of getting people's eyes to glaze over
  > faster than talking about crypto in my experience.
  > 
  > We really, really need some commonality. Let's
  > not backtrack. 
  > 
  > 		Mike
  > 
  > 
  > OKABE Nobuo writes:
  >  > Thank you for your many feedbacks.
  >  > 
  >  > From: Jari Arkko <[email-masked]>
  >  > Subject: Re: Should IP Security be Optional? [Was RE: 
  > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?]
  >  > Date: Mon, 04 Mar 2002 15:03:00 +0200
  >  > 
  >  > > Francis Dupont wrote:
  >  > > 
  >  > > > => yes, ICMP is hard to protect and to use it for 
  > small services
  >  > > > does not make things simpler...
  >  > > 
  >  > > So, we agree on this at least...
  >  > > 
  >  > > > => there is an IAB statement about security. IPsec 
  > support was
  >  > > > made mandatory according to this statement and IMHO this was
  >  > > > a big step forward. There are other security mechanisms,
  >  > > > including some at the transport layer (SSL/TLS, IMHO IPsec
  >  > > > is better but real world considerations have to be 
  > considered :-)
  >  > > > and some at the application layer, with in some cases a very
  >  > > > different usage (PGP).
  >  > > > I have in favor of to make all core security 
  > mechanisms mandatory
  >  > > > (MUST or strong SHOULD), cf RFC 2316 section 10. 
  > IPsec is only
  >  > > > the first in the list.
  >  > > 
  >  > > I'm partially in favor of this approach, but not entirely.
  >  > > I'd be much more comfortable with trying to make a detailed
  >  > > recommendation on where different mechanisms are applicable
  >  > > and mandated, than try to mandate them all everywhere (likely
  >  > > with less than 100% success among implementors).
  >  > > 
  >  > > I think the general approach should be that security
  >  > > is mandatory, but not necessarily same type of security
  >  > > under all circumstances.
  >  > 
  >  > I agree.
  >  > 
  >  > If a very small host has single application (ex. web),
  >  > the implementer will want to implement an appropriate
  >  > security mechanism only (ex, TLS) because of fitting
  >  > its cost.
  >  > 
  >  > It should be our further work to make detailed
  >  > guideline for LCNA part.
  >  > 
  >  > ---- nobuo
  >  > 
  > --------------------------------------------------------------------
  >  > IETF IPng Working Group Mailing List
  >  > IPng Home Page:                      
http://playground.sun.com/ipng
 > FTP archive:                      ftp://playground.sun.com/pub/ipng
 > Direct all administrative requests to [email-masked]
 > --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Michael Thomas <[email-masked]>
Date: Mon, 4 Mar 2002 09:50:17 -0800 (PST)

> IKE? and perhaps use something else for 

I think the v6 host requirements struck the right
balance: require the IP packet layer transforms,
and be silent on key distribution. Key
distribution is clearly a huge problem, but IPsec
doesn't mandate a single solution so I don't see
why the cellular requirements draft should either.
You can run IPsec with manually configured keys,
after all, so at a base level you can get
interoperability. This is foward progress IMO,
even though we clearly need more going forward.

		  Mike

---

From: "Jari Arkko" <[email-masked]>
Date: Mon, 4 Mar 2002 21:27:30 +0200

> even though we clearly need more going forward.

I do agree that the ESP and AH are really
simple and easy compared to the rest. Unfortunately,
this isn't going to be quite as easy as that. 

As we point out in section 3.8 the current
cellular networks sometimes have dynamic IP
address changes, and therefore manually keyed IPsec
isn't going to work as such and key management is
needed. While there might be multiple options
here, interoperability is a concern and hence
I feel that we must have a mandated key management
scheme. In the cellular host requirements draft, we
have chosen to say that IKE is a MUST in those
cases where we mandate IPsec. Do you disagree?

(In a way you could say that the cellular draft goes
*beyond* what the current IETF MUSTs are, given
that we mandate a full security solution in all cases,
though at the same time we don't mandate the current
requirement of AH and ESP in all cases.)

Anyway, this is just *our* proposal on what we think
would make sense. But the document is controlled by the
WG; please state your proposed security MUSTs for
IPv6 hosts, cellular or otherwise. Mike, what would you
like to have there, for instance?

Jari

---

From: Michael Thomas <[email-masked]>
Date: Mon, 4 Mar 2002 11:49:17 -0800 (PST)

> cases where we mandate IPsec. Do you disagree?

   I don't know; it depends on what you're trying
   to accomplish. Is there a reason that you must
   choose one? I agree that dynamic addresses makes
   manual keying problematic, but I'm not sure that
   it follows that you need to pick one keying
   scheme. Even with IKE, there's room for
   interoperability issues (some might say far
   too much room, but I digress). 

 > requirement of AH and ESP in all cases.)

   Well, at its base it's about what needs to be
   implemented, right? 

 > like to have there, for instance?

   My personal feeling is that the ng working
   group has the consensus about right. We need
   a base level set of mechanisms for protecting
   IP packets. Since this is normally kernel
   level work, having a strong statement here
   is useful. And while I think there's pretty good 
   consensus that IPsec (eg, not IKE) is a
   a stable and mature, there's equally good
   consensus that IKE is not. Given KINK and
   JFK/IKEv2 -- not to mention how widespread
   transport mode keying really gets deployed -- 
   I'm not sure that I'd want to choose any one
   at this point. I personally think that the
   Kerberos based keying is well suited to 
   high fan out  kinds of applications like
   telephony, but I wouldn't claim that it is
   the only way (or The Way) to approach the
   problem of keying.

	      Mike

---

From: "Jari Arkko" <[email-masked]>
Date: Mon, 4 Mar 2002 22:10:39 +0200

>    too much room, but I digress). 

I think we can agree on wanting to change <keyword> IKE to
<keyword> IKEv2 as soon as that is possible.

>    the only way (or The Way) to approach the

Yes... this is not a bad approach. However, I still
feel that it is sort of an underspecification. For instance,
if we say that MUST ESP and leave key management
in the air, then distribute 100,000,000 devices with
no key management, 100,000,000 devices with IKE,
100,000,000 devices with IKEv2, 100,000,000 devices
with KINK, and 100,000,000 devices with a weird app
layer keying scheme that isn't documented anywhere, we
aren't going to get interoperability! We couldn't make a
server for all of these devices to connect to, and they
certainly couldn't contact each other.

I do understand your comments about kernels and so
on, but I feel that I should perhaps explain more about the
deployment aspects of handing out very large numbers of
devices to grandmothers and truck drivers: they expect their
device to work, and they aren't going to install isakmpd
after finding out that their device doesn't work with their
friend's device -- like you and I would. The device is a box
that either works or doesn't work.

Therefore, I'm not very happy with a half-way MUST
particularly on a device where it may not make much
sense to talk about kernels and application processes.
(This is also in part why I'm worried about putting in
extra features just in case, and why we wanted an
all-or-nothing approach: either you really are using
IPsec or TLS or you're not going to need to do some
part of them.)

Jari