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

["Wenxiao He" <wenxiao.he@hp.com>]

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com 
> [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Karen Seo
> Sent: Friday, September 12, 2003 5:27 PM
> To: ipsec mailingList
> Cc: byfraser@cisco.com; tytso@mit.edu; Angelos D. Keromytis; 
> kivinen@ssh.fi; kseo@bbn.com
> Subject: 2401bis Issue #67 -- IPsec management traffic
> 
> 
> 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?
> 

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


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