[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: ipsec error protocol
>From: sommerfeld@thunk.east.sun.com on behalf of Bill Sommerfeld
>[sommerfeld@east.sun.com]
>Sent: Thursday, January 25, 2001 10:20 AM
>To: sankar ramamoorthi
>Cc: ipsec@lists.tislabs.com
>Subject: Re: FW: ipsec error protocol
>
> To cross this point the attacker has to be really be sophisticated.
> Not only he has to sniff and spoof the packet, but also send the
> 'invalid spi' message in a short time window.
>
>I'm aware of active attack code which does stuff like this already for
>tcp connections.
>
>In addition, a (deliberately or not) misconfigured host along the path
>which implements your scheme would trivially implement this part of
>the attack -- just convince it that one of its host addresses is the
>target's address and arrange for the packet stream to hit its
>ip_input() or equivalent.
>
One thing to note though is if there is a misconfiguration like that
it does'nt help a lot since all the follow up communication
(like probes, rekeys) to the intended address also will fail, and the
problem can be tracked through general network diagnostic mechanisms
By 'sophisticated' I meant someone who is able to inject these packets
without affecting normal flow of traffic and make the sender do a lot
of wasted work without making the problem visible to general network
diagnostics.
> 5. If a valid packet is received on the inbound ipsec-sa or
> a valid 'receipt' type of ipsec-control packet is received for the
> inbound sa, reset the counter and clear the flag. The 'invalid spi'
> notification was bogus.
>
>This assumes that:
> a) there is bidirectional traffic flow, and
not necessarily, since the 'receipt' control packet takes care of
the unidirectional traffic - the 'receipt' packets actually generate
a bidirectional flow in the absence of any already exisiting bidirectional
traffic.
> b) the implementation maintains a linkage between the "inbound" and
>"outbound" SA's
>
>Addressing each of these in turn:
>
>If you have redundant tunnels and are running dynamic routing over
>them (and before you dismiss this as unlikely, I know people who have
>talked seriously about deploying just this), then due the vagaries of
>dynamic routing, the traffic flow over any given tunnel may be
>unidirectional..
>
>Existing implementations I'm familiar with don't do (b), and adding
>this mapping is non-trivial because multiple equivalent SA's may exist
>between a pair of communicating nodes.
>
Yes - this would be a problem.
How are the SAs distributed between the pair of communicating nodes?
Could'nt the same channel be used to keep information in sync.
Yes, it would be non-trivial work in this particular scenario,
but so would distribution of SAs.
If there is no linkage between inbound and outbound SA then there are
other issues as well. If there are multiple SAs with a peer, coordinating
the move from a old SA pair to a new SA pair requires coordination
between inbound and outbound sa (packets arriving on an inbound sa gives
clue that the peer is using that sa pair - Tim Jenkins rekeying draft).
-- sankar --
> - Bill
Follow-Ups:
References: