[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC tunnels for LAN-to-LAN interop issue
Howdy ()
Just an idea from crazy land; lets see how far this goes...
The Non-Encapsulating Tunnel Interface for use with IPSec and IGPs.
Intro:
IPSec introduces some problems for routing protocols. IGPs anticipate
that routing peers are reachable via a logical interface within 1 hop.
These IGPs then learn/construct routes to subnets. IPSec tunnels are
unsuitable for IGPs to run over as interfaces because they may reach
destinations which are more specific than a subnet and there may also be
_very_ many IPSec tunnels between peers. Creating a seperate generic
tunnel interface is also unsuitable because although it allows the IGP
to function, IPSec must either shunt all traffic into a transport mode
SA to cross the tunnel (which is insecure), or IPSec must encapsulate
its own tunnels and deliver the packet to the logical generic tunnel
interface which will encapsulate the packet in a point to point link
protocol and then also encapsulate the packet in IP again (which is
inefficient). BGP has been suggested as a routing protocol to use to
avoid the problem since it does not require the asumption that a peer
router be reachable on a particular interface within one hop. But even
if BGP is shown to be workable (still under debate at this time), it
introduces the administrative burden of managing a set of Autonomous
Systems.
This memo (could become a draft if it doesn't get shot down to badly)
proposes to use an interface contstruct which does not encapsulate
packets. Since IPSec tunnels have alread acomplished that work, doing so
again is redundant. The only reason an 'interface' is needed at all is
to facilitate IGPs. A non-encapsulating tunnel interface carries all of
the IPSec tunnels which are desinted to the same peer.
Properties:
1) is in ifTable above a physical/ip layer interface
2) runs a keep-alive protocol
3) is usable by SPD
4) MUST have an IPSec policy matching at least endpoint to endpoint
routing and keepalive messages which provides identity
authentication.
5) any traffic being sent via the interface which is not destined for
the interface's peer is dropped and audited.
Processing:
INBOUND:
o Link driver receives a packet on a physical interface
o this interfaces updates ifTable stats
o recognize packet as IP
o run verification tests
o recognize as special case of addressed to me = addressed to my tunnel
intf
o (reassemble if necessary)
o update ifTable stats for tunnel intf
o IPSec process w/ ingress interface = tunnel intf
o Fwd or locally receive
OUTBOUND:
o After IPSec processing:
o Route to far-end tunnel IP has true physical next hop(s) but also has
exit interface = tunnel Intf
o update stats in ifTable for tunnel intf
o ARP for true physical next hop
o append link headers for physical link
o update stats in ifTable for physical intf send packet
Originating an IGP Routing Message:
Both ends of the tunnel interface are configured to be in
the same subnet. IGP messages sent to unicast neighbors are sent to
the far-end tunnel IP. IGP messages sent to multicast addresses are
sent via the local tunnel interface. An IPSec policy matches and MUST
tunnel this packet (not transport, that would blow-up with multicast)
to the far end tunnel IP. Then the packet is forwarded as per
outbound processing.
Receiving an IGP Routing Message:
Packet is received via inbound processing as above. The packet
is delivered locally.
Keep-alive:
Whatever keep-alive protocol is utilized, they are originated
and received just like unicast routing messages. The keep-alive state
machine may mark this tunnel as operStatus up or down in the ifTable.
When a tunnel is marked as operStatus=down, the routes through this
interface should be removed from or invalidated in the routing table.
Also, any IGP on this device should be notified of the link-down (or
link-up) event in the normal way.
When is a non-encapsulating tunnel interface invoked:
This is under administrative control. An implementation MUST
be able to create a tunnel interface, set it to non-encapsulating
mode and name its peer. Any packet entering the tunnel which is not
destined to the peer is to be dropped and audited.
One could imagine a Tunnel discovery protocol based on the
configured list of peers in IKE. Maybe later.
Security Considerations: (need help with this section)
1) Masquerade
Since tunnel endpoints must be Internet reachable, they are
also masquaradeable. As long as IPSec is authenticating packets
received on the tunnel interface, however, there would be now way
for the malicious user to inject bogus information into your IGP or to
inject bogus keepalives into your state machine.
2) DOS
A masquerader would be able to successfully divert the
keepalives and would therefor be able to make your link appear to be
down at any time. However, this is an improved situation from today
where Internet traffic could be diverted from an IPSec tunnel and you
would have no notification of the event.
Comparison to other options:
1) IPSec Tunnel is an interface:
There may be multiple IPSec tunnels to the same peer and these
IPSec tunnels may be for endpoints which are applications on hosts. Both
of these facts may confuse a routing protocol.
2) IKE Tunnel is an interface:
This is not an encapsulation technology... it just won't work.
3) GRE tunnel is an interface, All relevant IPSec tunnels run over it:
This works but takes a _lot_ of headers.
4) GRE tunnel is an interface, one IPSec transport SA carries all
traffic:
Insecure.
5) IPSec tunnel is an interface, rely on administrators to not come up
with configurations which would confuse routing protocols:
Yeah right.
6) IPSec tunnel may be marked as an interface, then the implementation
disallows other configuration which would confuse routing protocols:
Difficult to implement, reduces security flexibility.
--
####################################
# Ricky Charlet
# (510) 795-6903
# rcharlet@redcreek.com
####################################
end Howdy;
Follow-Ups: