Folks -- Jim and I talked about this a few days ago. Teething children (and
the accompanying sleep-deprivation) kept me from mailing this sooner.
On Sun, Oct 09, 2005 at 03:01:53PM -0400, James Carlson wrote:
>
> For RFC 2401 mode, matching based on a prefix implies having a route
> associated with the tunnel. Tunnels are point-to-point entities; to
> have an ingress that is defined in terms of a prefix means that you
> need to insert an entry to the kernel's forwarding table. Does this
> mean that in.iked becomes a routing daemon? (And what does that
> mean for the existing routing daemons we have? How do they
> cooperate?)
We only apply policy to packets that make it to the tunnel.
Routing/forwarding determines what packets hit a tunnelling interface.
Security policy takes over AFTER routing/forwarding decisions happen. This
makes the concerns in the next two paragraphs...
> Matching on protocol and/or port numbers means that we're defining a
> generalized FEC (Forwarding Equivalence Class) mechanism for
> Solaris. This is probably a good thing, as it's something we'd
> likely need to do a competent implementation of MPLS or int-serv
> RSVP, but it's not a small thing.
>
> How exactly are FECs to be manipulated, managed, and handled within
> Solaris?
... non-issues.
> What is the impact of ignoring RFC 3884? It looks like the design
> isn't done for that part. Who is using RFC 3884, and does it matter
> if Solaris lags here?
RFC 3884 suggests using transport mode IPsec SAs for securing tunnels. Since
we mostly do this in S9 and S10 FCS, Tunnel Reform will make this an option
going forward.
> At what point does policy selection become simply generalized packet
> filtering?
When we dig ourselves DEEP into the forwarding path, and not just deal with
packets we originate or receive (tunnel interfaces count here, because the
origination happens when that outer IP header gets slapped on).
> What's the impact of ignoring RFC 2401bis selector ranges? Are they
> used in any important place?
Not currently. If I start down the 2401bis slope, I have to go all the way,
and that pushes the scope of this project well beyond what it should be.
> Please explain spd_ifid_* -- I can't quite figure out what that six
> octet "uid" might be.
It's an interface name that can extend off the 6 octets in the structure. We
do the same trick in PF_KEY.
> Open-ended question: what might happen if the outer addresses become
> dynamic? Clearly, the system could select the right receiving
> tunnel based on the SA alone (right?), so is it possible to float
> those addresses?
Not right now, but 2401bis has no-address IPsec SAs (i.e. the SPI alone
selects the SA on the inbound side).
> More information on the system performance issues with the SPD might
> be needed. It's not clear to me exactly why these tunnels represent
> a special new problem.
Because right now tunnels make the simplifying assumption that all traffic on
the tunnel is treated the same way. That assumption is shattered with Tunnel
Reform.
> I don't think that "sol9-tunnel" (or the other keywords here) are
> exactly the right answer.
Between that, and the realization that the S9 IKE daemon doesn't mind if the
remote-side uses transport mode for tunnels TODAY, we can eliminate
sol9-tunnel as a concept. Also, because we wish to avoid the
routing/forwarding problems with policy-directed tunnels, we are elminating
them too.
Basically, tunnels now can be configured to tell key management to negotiate
Tunnel Mode SAs (with proper Tunnel Mode selectors) or Transport Mode SAs
(and the IKE daemon post-Tunnel Reform will deal with the Solaris 9 initiator
case).
> It seems to me that the extended-ACQUIRE mode (if it's needed --
> aren't these messages extensible?) could just be a separate flag,
> rather than being part of the keyword introducing the tunnel name.
Agreed, and the two choices are "tunnel" and "transport". See the next
document revision (next e-mail) for details.
> How will tunnel names be kept in sync with vanity naming? Should
> the vanity naming project reach into the IPsec database and
> manipulate these entries?
That will be an issue between me and the Clearview team. The answer is:
- Running kernels that get interfaces renamed keep track of things.
- The Clearview folks may want to poke in /etc/inet/ipsecinit.conf
and change interface names accordingly.
- Cases where ipsecconf(1m) input is not from
/etc/inet/ipsecinit.conf are not covered.
Thanks Jim! A new document has just been posted. See the next note.
Dan
