Subject: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?]

From: Margaret Wasserman <[email-masked]>
Date: Mon, 04 Mar 2002 03:17:04 -0500

And the next issue, IP Security...

>   >          - Situation where IP Security should be optional/disabled
>   >                  (and the whole distinction between "Core IP" and
>   >                  "IP Security")
>
>=> The distinction between IP security and core IP
>is merely an editorial distinction. For example
>you can see that in 'core IP' we list all the 
>IPv6 WG RFCs. 

Publishing a document that makes this distinction, however, will give
the impression that IP Security (AKA IPSec) is not a _core_ part of
IPv6.  Some people may take that to mean that they can produce a 
complete IPv6 implementation that does not include IP Security.

>As to whether IP security (I assume you mean IPsec)
>should be mandated or not, we can discuss that.
>But some questions that we would need to answer:
>
>- By 'mandated' do we mean implementation or use?
>- What should be mandated? 
>- Why should it be mandated?

RFC 2460 says:

"A full implementation of IPv6 includes implementation of the
    following extension headers:

            Hop-by-Hop Options
            Routing (Type 0)
            Fragment
            Destination Options
            Authentication
            Encapsulating Security Payload

    The first four are specified in this document; the last two are
    specified in [RFC-2402] and [RFC-2406], respectively."

So, a "full" implementation of IPv6 must include an implementation
of the Authentication and ESP headers from RFCs 2402 and 2406.

Obviously, it is possible for a host to implement RFCs 2402 and 2406,
but to be configured such that no traffic is ever authenticated and/or
encrypted.

The draft-ietf-ipv6-cellular-host-00.txt document, however, seems to 
assume that there may be hosts that do not implement these headers.
It says:

"  - AH and ESP headers: In the case of the Core IP functionality 
        only, AH and ESP headers are treated as if the Security 
        Association had not existed, i.e. - packets with these headers 
        are dropped.  When the IP Security functionality is in use, they 
        are processed as specified in RFCs 2401, 2402, and 2406."

I am not sure about the wording here, but this paragraph implies to
me that cellular hosts that only implement the "Core IP" functionality
may not actually implement AH or ESP processing.  This conflicts
directly with RFC 2460.

Now, I don't actually live under a rock, so I do understand that most
of today's IPv6 nodes don't actually implement IP Security.  In the
past, however, the IESG had mandated that IP Security would be a
mandatory part of IPv6, and I don't believe that they've changed that
statement.

So, where do we go from here?

No document can be published as an RFC without IESG approval, and I don't
think that we'll get IESG approval for a document that says (or even
strongly implies) that IP Security is optional in IPv6.  Maybe our
ADs could comment on this?

Margaret

--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Mon, 04 Mar 2002 10:39:51 +0100

I agree with you and Hesham: IPsec is required for any compliant
IPv6 implementations and we should not accept an exemption for
a device which can get a global address in the Internet.
BTW the complexity argument is not very sound because IPsec
with IKE is already available on PalmPilot and PSions (cf ipsec
wg mailing list).
Security should not be a compromise!

Thanks

[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Mar 2002 11:46:18 +0200

Thanks Margaret for opening up discussions on each of
the specific points you raised. I think we do need
the discussion.

> mandatory part of IPv6, and I don't believe that they've changed that

First I'd just like to note that the main approach
to security is outlined in the beginning of section 3.
Section 2.4 text is just a consequence of that.

Now, I actually believe there's today a better understanding
of what security is required when, and what are the
true capabilities of various security mechanisms than back
when some of the base IPv6 RFCs were created.

What we describe in section 3 tries to reflect some of
that new understanding. In particular, we realize that
there are a few different security mechanisms, and often
IETF application protocol RFCs specify a particular security
mechanism to be used. This isn't always IPsec. In other
cases a single mechanism is simply the most appropriate
one. As an example of this, consider the use of TLS vs.
IPsec for web access; I think the appropriate security
mechanism is quite clear in this case. 

Secondly, we now have a better understanding of what
IPsec can do in the area of protecting IPv6 control
signaling -- it can do things, but not perhaps quite
as much as was originally believed [1, 2, 3]. IPsec
is however, obviously the used in e.g. corporate intranet
access and VPN solutions.

Therefore we feel that on size- and power-constrained
devices one should select the implemented security
mechanisms based on the requirements of the applications
rather than a general rule. The general rules aren't
very good if in the end the application RFC you were running
would demand something else than the general rule, or if
the deployment at the other end was something else.

This conclusion seems to be supported by other approaches
to host requirements [4].

In any case, I'd be very happy to get feedback on
exactly what we should write as the host requirements
for security. I'm reasonably happy with what we have
written -- in particular I believe this is roughly
where the world seems to be heading -- but if you
have other ideas or improvement suggestions, please
present them!

Jari
----
[1] http://search.ietf.org/internet-drafts/draft-kempf-ipng-netaccess-threats-00.txt
[2] http://www.arkko.com/publications/draft-arkko-manual-icmpv6-sas-00.txt
[3] http://www.ietf.org/internet-drafts/draft-arkko-mipv6-bu-security-01.txt
[4] http://search.ietf.org/internet-drafts/draft-okabe-ipv6-lcna-minreq-01.txt
--------------------------------------------------------------------
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: Tim Chown <[email-masked]>
Date: Mon, 4 Mar 2002 09:56:43 +0000 (GMT)

Margaret,

Another important reference is in RFC2401, "Security Architecture for 
the Internet Protocol"

10. Conformance Requirements

   All IPv4 systems that claim to implement IPsec MUST comply with all
   requirements of the Security Architecture document.  All IPv6 systems
   MUST comply with all requirements of the Security Architecture
   document.

There was a thread along these lines a few months back, the conclusion
of which was that full implementations of IPv6 must implement IPsec, but
that use of IPsec was not mandatory.  So the cellular hosts document may
choose to distinguish between implementation and use also.

Tim

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Mar 2002 12:50:49 +0200

> with IKE is already available on PalmPilot and PSions (cf ipsec

True, and I've personally done even smaller implementations
of IPsec... however this isn't really the point. The point
is the use of appropriate mechanisms for the task at hand.
Even the other mechanisms may be complex and troublesome
to implement. But we should avoid adding other mechanisms
that we do not need.

> Security should not be a compromise!

I agree. However, I disagree with the thinking that
e.g. my web-browsing-phone has somehow compromised on
security when it implemented TLS instead of IPsec.

Please note that I do NOT want to say that we shouldn't
use IPsec. Rather, you could say that I'd like to get
a more appropriate applicability statement for it than
we currently have. For instance, the recommendations we have
in some base IPv6 RFCs on the use of IPsec for ICMP protection
are at least misleading -- and this is from personal
experience on actually trying to do that. Have you tried
it?

Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 04 Mar 2002 12:14:18 +0100

In your previous mail you wrote:

   But we should avoid adding other mechanisms that we do not need.

=> we need IPsec and we need even other mechanisms because IPsec
is not all the security. For instance for mails between humans
we need PGP or S/MIME too.

   we currently have.

=> 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.

   For instance, the recommendations we have
   in some base IPv6 RFCs on the use of IPsec for ICMP protection
   are at least misleading -- and this is from personal
   experience on actually trying to do that. Have you tried
   it?
   
=> yes, ICMP is hard to protect and to use it for small services
does not make things simpler...

Regards

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Mar 2002 15:03:00 +0200

> does not make things simpler...

So, we agree on this at least...

> (MUST or strong SHOULD), cf RFC 2316 section 10. IPsec is only

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.

Jari

---

From: OKABE Nobuo <[email-masked]>
Date: Mon, 04 Mar 2002 22:35:53 +0900 (JST)

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

> is mandatory, but not necessarily same type of security

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

---

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

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

---

From: Robert Elz <[email-masked]>
Date: Tue, 05 Mar 2002 14:13:03 +0700

Date:        Mon, 04 Mar 2002 12:50:49 +0200
    From:        Jari Arkko <[email-masked]>
    Message-ID:  <[email-masked]>

  | The point
  | is the use of appropriate mechanisms for the task at hand.

Yes, but you can't possibly know the mechanisms unless you know the
requirements of the nets at both ends of the connection.   You know
only one of them.   If you want your devices to ever be able to communicate
with a net being installed in a new building currently being fitted out
in Melb Uni, you will need to have IPsec implemented, nothing using clear
IP will be connected (ie: packets will be dropped).   If the application
requires TLS, then it will use TLS, which will mean TLS over IPsec, which
is just fine (might seem like overkill, but each is offering different
functionality, so it isn't really).

Requiring IPsec in *all* IPv6 is what makes this feasible - we know that
everyone we're ever going to communicate with will be able to use IPsec.

No exceptions.

kre