[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-bugs
Subject:    system/4314: isakmpd(8) Phase 2 "IPsec-ID" limitations
From:       "Brian A. Seklecki" <bseklecki () collaborativefusion ! com>
Date:       2005-07-29 20:39:03
Message-ID: 1122669543.580.12.camel () soundwave ! collaborativefusion ! com
[Download RAW message or body]

>Number:         4314
>Category:       system
>Synopsis:       isakmpd(8) Phase 2 "IPsec-ID" ambiguity and proposed
>Confidential:   yes
>Severity:       non-critical
>Priority:       medium
>Responsible:    bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 29 21:40:01 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Brian A. Seklecki
>Release:        OpenBSD barricade 3.7 BARRICADE_POWEREDGE#0 i386
>Organization:
Collaborative Fusion, Inc.
net
>Environment:
        System      : OpenBSD 3.7
        Architecture: OpenBSD.i386
        Machine     : i386
>Description:
        What is defined in isakmpd(8) and isakmpd.conf(5) as a Phase 2
"Ipsec-ID" is ambiguous at best.  Unlike it's counter-part Phase 1
"Phase1-ID" which is critical in Phase 1 authentication (if pre-shared
keys are not in use), Phase 2 "Ipsec-ID" is not used in authentication.

It is, however, used in the negotiation of IPSec proposals.  It is
therefore not really an "ID", as it would relate to "authentication" or
"authorization". i.e., Credentials.

It defines simply an IPV6 or IPV4 ACL of hosts/networks for tunnel or
transport mode end-points and as to which traffic should be encrypted.

Is therefore not an "ID" at all and it may be beneficial for the user
community if it was not referred to that.  Other IPSec implementations
refer to it as a "Map" or "ACL" or "Net".

Additionally, the present IPSec-ID syntax allows for granular selection
of  IP address / or IP Subnet/Mask, Port, and Protocol, etc.  However
granular, multiple IPSec-IDs cannot exist for a given Phase-1/Phase-2
SA/Proposal set (i.e., tunnel/transport).  Other implementations permit
for this, which is frequently required when less-than-optimal addressing
schemes are used in a network, i.e., discontinuous or dis- contiguous
subnets on either side of a tunnel.

The result is that, for each discontinuous subnet that would like to
egress the tunnel, a separate tunnel must be configured.  This does not
scale well.

>How-To-Repeat:
        Deploy OpenBSD IPSec Firewalls in your organization using ISAKMP
>Fix:

*) Engage in discussion of the possibility of renaming the "IPSec-ID"
configuration directive to something more appropriate, as well as
a migration path

*) For the Multiple-Subnet issue, one obvious solution would be to
use hooks from pf(4) / pf.conf(5) syntax processing to obtain the
desired behavior

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]


>Release-Note:
>Audit-Trail:
>Unformatted:
 changes

[prev in list] [next in list] [prev in thread] [next in thread]