Subject: [MSEC] Comments on Issue 3: Composite cryptographic groups

From: Brian Weis <[email-masked]>
Date: Thu, 17 Nov 2005 23:34:09 -0800

This email contains one viewpoint regarding Issue 3, which is wrestling 
with the idea of a single IPsec context having to possibly match a 
single multicast packet against multiple policies. [Note: the term 
"IPsec contexts" comes from Section 4 of rfc2401bis.] While it is a 
noble goal to ensure that all Ipsec systems to have this capability, I 
fear that it is an unreasonable goal from the standpoint of some Ipsec 
systems. Here are some reasons why.

This change requires *all* systems creating IPsec packets to implement 
at least two new processing steps.

   a. This proposed semantics requires the IPsec context to match a 
multicast packet against multiple IPsec policies. In the unicast case, a 
single SPD lookup always results in matching a single IPsec SA.

   b. The proposed semantics require an IPsec context to replicate 
packets (once for each matched policy). This is a completely new and 
disruptive processing step in the encapsulating an IPsec packet! In my 
estimation, this new semantic is disruptive to IPsec encapsulation 
processing in either a UNIX or UNIX-like system (acting as a sender, 
receiving a packet from a socket) or an IPsec gateway (relaying a 
multicast packet).

An alternative to requiring a single IPsec context to replicate packets 
would be to apply multicast packet replication where it usually happens 
-- as a result of multicast routing. Doing so does imply that there 
exists a different IPsec context for each policy. This is possible in an 
IPsec gateway with multiple interfaces, or perhaps in a host with a 
complex internal architecture. However, a simple host with a single 
IPsec context could not support encrypting to multiple groups -- it 
would be necessary for the sending host to deliver the packet to a LAN 
containing multiple IPsec contexts, one for each group. However, this 
avoids costly new semantics in the IPsec context itself.

Thanks,
Brian

-- 
Brian Weis
Advanced Security Development, Security Technology Group, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: George Gross <[email-masked]>
Date: Mon, 21 Nov 2005 18:47:48 -0500 (EST)

Hi Brian,

I set aside my first attempt at responding to your e-mail, as that
response delved into too much detail arguing about the technical
feasibility of implementing composite groups. I decided that was not
germane to our discussion. Each platform will have its own set of IP stack
level tools and facilities that could be a springboard for adding an IPsec
composite group capability. Given it is only software R&D, I don't think
that arguing feasibility is the primary issue that we face here....

As standards authors, I am pretty sure that we agree that our
responsibility is simply to outline those elements of an IPsec subsystem
that assure inter-op across the whole MSEC IPsec extensions lifecycle.

I remain convinced that the cryptographic algorithm migration problem is a
genuine deterrent to deploying MSEC IPsec extensions unless we can state
the conformance guidance that assures multiple vendors can cooperate to
make a composite group work. This implies both IPsec gateway and host OS
vendors all must clear the same hurdle. Our job is to identify the admin
knobs and GKMP related controls that make that happen, not to argue the
subjective complexity of introducing the composite group feature in a
hypothetical IPsec subsystem's implementation.

I should mention in passing that having a single packet match multiple SPD
policies is not without precedent. It is described in RFC2401 as the
"nested SA bundles" capability used to do ESP plus AH on a single packet.
As you know, RFC2401-bis no longer mandates this capability, but it does
acknowledge this capability is a valid IPsec implementation option.

That said, I would like to float an idea that might finesse your
misgivings about making a single packet match multiple SPD policies.
Perhaps we could agree that MSEC IPsec subsystems operating in transport
mode must be capable of being configured/controlled to doing the
following:

1) assign a distinct destination IP multicast address to each sub-group
within the composite group, along with a corresponding SPD/SAD entry that
applies the respective sub-group's security policy. The SPD entry would
match the sub-group's destination address, not the composite group's
destination IP address. It would make sense to have separate multicast
sub-groups in any case, since the two or more sub-group multicast data SA
flows are received and can only be decrypted at disjoint sets of
endpoints.

2) assign a unique destination IP multicast address to represent the
composite group. This destination IP address would be different than the
destination IP multicast address assigned to any of the sub-groups. For
host-based IPsec systems, this could be a virtual multicast group address
that is internal to the system (i.e. not seen on the wire).

3) Identify a new architectural component, called a "composite group
distributor", that intercepts each packet *before* the SPD/SAD see it. The
composite group distributor recognizes the composite group's IP multicast
address, and then replicates the IP packet for each sub-group.

As an example, the existing Linux iptables ULOG facility in combination
with a user level composite group distributor process could provide this
capability. It is an implementation choice whether packet replication
occurs in a user level process or at the kernel level. Of course, our
document would only describe the composite group distributor as a black
box.

4) After being replicated, each cloned packet is sent to its sub-group's
destination IP multicast address, not the composite group's IP multicast
address. The SPD/SAD entry matches and applies the respective sub-group's
security policy.

The key point to observe here is that the SPD/SAD does not need to match a
single packet against multiple security policies. In effect, we've solved
that problem in an adjacent MSEC IPsec architectural component, the
composite group distributor. This component would be required only for
transport mode group SA configurations.

Obviously, in a tunnel mode SA configuration, you have the lattitude of
letting multicast routing solve the replication problem, as was
illustrated in the slides presented at the Vancouver MSEC meeting.

br,
	George