Subject: 2401bis Issue #67 -- IPsec management traffic

From: Karen Seo <[email-masked]>
Date: Fri, 12 Sep 2003 20:26:53 -0400

Folks,

Here's a description and proposed approach for:

IPsec Issue #:	67

Title:		IPsec management traffic

Description:
============
SPD entries apply only to subscriber traffic. However, 2401 says that 
the "SPD must be consulted during the processing of all traffic..." 
leading to confusion about whether IPsec management traffic should 
have an SPD entry, etc.  Should the text be modified to make it clear 
that an IPsec implementation is able to send and receive traffic for 
itself independent of SPD/SAD entries or should there be an explicit 
SPD entry to cover IPsec management traffic?

Note: If one chose to allow IPsec management traffic to bypass SPD 
lookup, then how would one implement a policy of "don't accept IKE 
traffic from src A"?

Note: There MUST be an entry in the SPD to cover transiting IKE 
traffic that is not destined for the system itself.

Proposed approach:
==================
The proposed approach has several components:

1. Add adjective "subscriber" in front of "traffic" in the sentence 
the "SPD must be consulted during the processing of all traffic..."

2. Add text to say "An IPsec implementation may originate and 
terminate its own management traffic, e.g., IKE,  irrespective of the 
SPD and SAD entries used to manage subscriber traffic.  If SNMP 
traffic directed to the IPsec device is protected via IPsec, then it 
should be treated the same as subscriber traffic. SNMP traffic 
directed to the IPsec implementation and not protected by IPsec could 
fall into the same category as IKE, i.e., it might be exempted from 
SPD/SAD constraints. Outbound ICMP traffic arriving on a secure (red) 
interface of an IPsec implementation should be subject to normal, 
SPD/SAD controls, as should inbound ICMP arriving via an SA. ICMP 
traffic arriving on an insecure (black) interface must be treated 
specially, and this topic will be addressed in a separate note.

3. IKE is designed to be minimally vulnerable to DoS attacks that 
result from IKE exchanges, so there is no need to reject initial IKE 
messages based on a configured policy. However, it may be reasonable 
to add a policy DB that says with whom the IPsec system will execute 
IKE, e.g., with whom it will complete an IKE exchange, what form of 
authentication is required, etc.

Thank you,
Karen

---

From: "Wenxiao He" <[email-masked]>
Date: Tue, 16 Sep 2003 12:40:56 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Karen Seo
> Sent: Friday, September 12, 2003 5:27 PM
> To: ipsec mailingList
> Cc: [email-masked]; [email-masked]; Angelos D. Keromytis; 
> [email-masked]; [email-masked]
> Subject: 2401bis Issue #67 -- IPsec management traffic
> 
> 
> Folks,
> 

When talking about "send and receive traffic for itself independent of
SPD/SAD entries", are you saying all end host IPSec management traffic
should be in cleartext? Using the example below, assuming IPSec tunnel
between H1 and SG2 is ready and H1 sending IKE messages to H2, should
these IKE messages be in cleartext or protected  by H1/SG2 tunnel SA? On
the 2nd note below are you saying when IKE traffic (H1/H2) going through
SG2 it will require a SPD?

        ======================================================
        |                                                    |
        |==============================                      |
        ||                            |                      |
        ||                         ---|----------------------|---
        ||                         |  |                      |  |
        H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
              ^                    |           Intranet)        |
              |                    ------------------------------
        could be dialup              admin. boundary (optional)
        to PPP/ARA server

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Sep 2003 17:14:19 -0400

At 12:40 -0700 9/16/03, Wenxiao He wrote:
>should be in cleartext?

NO. what we said was that IKE SAs are treated specially by the 
host/SG that terminates or originates IKE traffic, and thus need not 
be subject to SPD/SAD controls.

>Using the example below, assuming IPSec tunnel

The IKE traffic from H1 is treated like any other subscriber traffic 
from H1, and thus requires an appropriate SPD entry to be allowed to 
pass. However, at H1, the IKE traffic it emits and receives need not 
be authorized by an entry in its SPD.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Sep 2003 21:06:56 -0400

At 16:50 -0700 9/17/03, Wenxiao He wrote:
>I am still confused. Let me ask some questions first:
>* What is IPSec management traffic? Does it include IKE traffic
>(UDP/500)?

yes, it includes IKE traffic, but the text refers to IPsec management 
traffic originated or terminated by the device in question, not ALL 
IPsec management traffic.

>* What traffic is not subject to SPD/SAD control?

that's the subject of this change, see above!

>* When a traffic is not subject to SPD/SAD control, it sounds it is
>cleartext to me. Without consulting SPD/SAD, how can the traffic get
>sent with SA protection(which SA to use)?

IKE provides its own protection for its traffic, but it does not use 
ESP.  that is an example of protected traffic that would not be 
processed via the SPD, e.g., since the SPD entries are defined to 
apply ESP and/or AH, but not the crypto protection employed by IKE.

Steve

---

From: "Wenxiao He" <[email-masked]>
Date: Wed, 17 Sep 2003 16:50:43 -0700

---

From: Francis Dupont <[email-masked]>
Date: Thu, 18 Sep 2003 16:32:44 +0200

In your previous mail you wrote:

=> IMHO it is convenient to be able to do both, i.e., the standard way
is that the IKE daemon asks itself for the "bypass" for UDP/500 but
the administrator can choose to enter specific SPD entries for UDP/500.
(for instance in order to solve the issue of IKE messages going throught
the local node)
BTW the RFC 2401 text is fine: it suggests this usage of the "bypass" but
mandates nothing more than common sense.

Thanks

[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 Sep 2003 18:24:07 -0400

>[email-masked]

Francis,

I looked at 2401 and the text I found in Section 4.4.1, is what I 
assume folks had in mind when they thought that IKE traffic needed to 
have SPD entries:

"The SPD is used to control the flow of ALL traffic through an IPsec
system, including security and key management traffic (e.g., ISAKMP)
from/to entities behind a security gateway.  This means that ISAKMP
traffic must be explicitly accounted for in the SPD, else it will be
discarded.  Note that a security gateway could prohibit traversal of
encrypted packets in various ways, e.g., having a DISCARD entry in
the SPD for ESP packets or providing proxy key exchange.  In the
latter case, the traffic would be internally routed to the key
management module in the security gateway."

What I think I had in mind here was that IKE (or other security 
management) traffic passing  the through device needs to be accounted 
for in the SPD. But, IKE traffic created in the device does not pass 
through it, in my mind, and thus was exempt from this requirement.

Is there some place in 2401 that refers to bypass of UDP/500 traffic for IKE?

Steve

---

From: Francis Dupont <[email-masked]>
Date: Sun, 21 Sep 2003 16:37:45 +0200

--============_-1148198426==_ma============
   Content-Type: text/plain; charset="us-ascii" ; format="flowed"
   
   >mandates nothing more than common sense.

=> my purpose is to not rely on the "In host systems, applications MAY
be allowed to select what security processing is to be applied to the
traffic they generate and consume." to solve the "protection bootstrap"
problem of IKE. And the clean way is to offer a second way by the SPD.

   
   
=> in the PANA IPsec document you can get a nice case where the traditional
"bypass set by the IKE application" is not enough: a client (the PaC) has
a local ESP tunnel with a SG (the EP) and a second ESP tunnel with a
remote SG. The IKE messages with the remote SG should be encapsulated
locally (i.e., between the PaC and the EP). This can be done only with
a suitable SPD, for instance if the SPD has the "apply first match" style,
on the PaC the SPD in the out direction is:
 - source=PaC, destination=EP, ULP=UDP port 500: bypass
 - source=PaC, destination=remote SG, ULP=UDP port 500: ESP tunnel (PaC-EP)
 - source=PaC, destination=behind remote SG, ULP=any:
    ESP tunnel (Pac-remote SG) then ESP tunnel (PaC-EP)
 - source=PaC, destination=any, ULP=any: ESP tunnel (PaC-EP)

   Is there some place in 2401 that refers to bypass of UDP/500
   traffic for IKE?
   
=> no, IMHO we don't need such thing.

Thanks

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Sep 2003 10:44:19 -0400

Francis,

Your example is a good one. In cases like that it is necessary to 
place IKE messages inside a tunnel, even when they originate at the 
IPsec implementation in question. In those cases that one would need 
to make use of the SPD, as shown in your example.

I agree that use of the SPD for dealing with IKE traffic is needed 
when we supported nested SAs that terminate at the same IPsec 
implementation, something that several folks at least want to retain 
as an option, if not a requirement. So, we will reword the text to 
say that one can deal with locally generated and terminated IKE and 
similar management traffic either via SPD entries or via other, 
locally defined, means.

There is one slight catch, however. There is no SPD entry action to 
cause delivery of a received message to IKE. So, while your example 
is appropriate for outbound IKE traffic, I don't think we ever 
defined a way to express appropriate internal forwarding of inbound 
IKE traffic.  Any suggestions?

Steve

---

From: Francis Dupont <[email-masked]>
Date: Sun, 28 Sep 2003 16:14:02 +0200

=> I agree but I don't believe there is a solution inside IPsec itself:
to enforce the delivery of packets maching a filter to a process/user/...
is a "personal firewall" function only.

Thanks