[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IKEv2 traffic selector subsetting.

At 11:56 PM -0500 12/23/01, Andrew Krywaniuk wrote:
>  > > It seems to me that 2401 is trying to skirt the issue by
>>  integrating the
>>  > functionality of a very basic firewall into IPsec (thus
>>  *causing* the SADB
>>  > and firewall to be on the same machine).
>
>>  Exactly!  This is never advertised as such in the IPsec
>>  documents for some
>>  unfathomable reason -- much confusion would be saved if it
>>  were made more
>>  explicit -- but they basically include a specification for an
>>  Internet-standard minimum firewall mechanism.
>
>
>Which brings us right back to the original point of the thread. Traditional
>firewalls enforce a policy without advertising it. IPsec SPD firewalls add
>this extra 'selector negotiation' feature. However, the IPsec selectors are
>not adequate to express the entire spectrum of what a fully featured
>firewall can use. I prefer the model in which each side merely enforces its
>own policy.
>
>If you desire the capability to detect and avoid black holes (a feature not
>found in traditional firewalls), then it would be preferable for both peers
>to issue ukases describing what types of traffic they are willing to accept.
>This avoids the aforementioned problem where the responder chooses selectors
>that don't match the triggering packet, and it makes it easy to add or
>delete policies without renegotiating the SA.

There are a few ways in which what we do in IPsec differs from the 
functionality of a basic firewall:

	- first, we have the option to use crypto-authenticated 
symbolic identities (e.g., DNS names, RFC822 addresses, DNs, etc.), 
not just NOT addresses, and to have these identities mapped to IP 
source/destination addresses when an SA is estyablished. This can be 
done irrespective of the availability of DNS security, although it 
would be even better with DNSSEC. this more powerful feature makes 
use of an SA management protocol, e.g. IKE or its successors.

	- we have the ability to map different traffic streams to 
different crypto protection suites, or to the same suite but with 
different SAs. I don't think one can achieve the same effect with a 
separate firewall capability. also, SPD mismatches here could be very 
confusing and hard to detect and resolve.

	- if one did try to make the firewall capability very 
separate, the there would be a new management problem, i.e., ensuring 
synch between the SPD and the firewall database, which could be 
especially difficult when symbolic SPD entries are used.

	- fundamentally, when an initiator creates an SA to a 
responder, if the initiator fail to advertise what traffic will be 
sent over the SA, and what traffic would be accepted via the SA, the 
responder is at a disadvantage in terms of processing the inbound 
traffic, and the responder may have a harder task of mapping outbound 
traffic to the SA. (This is because the responder does not know what 
range of traffic the initiator expected would be mapped to the SA. 
This can occur when two sites have SPDs that allow different classes 
of traffic to be exchanged between them, but may want different SAs 
for the different classes of traffic.)

Much of our recent discussion on this list has focused on how to 
improve the manageability of IPsec, to facilitate more widespread 
adoption.  This underlies the debate about pre-shared keys, for 
example. I think the goal of quickly detecting mismatches in SPD 
configuration and providing feedback that allows site security 
administrators to resolve such mismatches, is consistent with the 
goal of trying to make IPsec easier to use, and thus we should retain 
the negotiation of SA traffic selectors as part of any IKE 
replacement.

Steve
References: