2401bis Issue #67 -- IPsec management traffic

[Karen Seo <kseo@bbn.com>]

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