[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ipsec error protocol

notice that you made a lot of progress. Your "slight changes" actually shift the original paradigm from a "keepaplive in disguise" into "acknowledgement in disguise".

Take my first emails and re-read: acknowledgments are better.

Your problem is that you really want to trigger this with an "invalid SPI" message. And you come up with pretty fancy packets. Not that I do not like them (they're a valid vector after all) but now your philosophically correct pseudo-ICMP's tunnel data :)

Question: what if every ESP (for instance) packet would piggy back an acknowledgement field (in both direction) ? That would solve quite a few issues, no ? And would also be much more efficient.



One more thing: with acknowledgments alone, there are still possible DoS. All that will be in the draft I am cooking up but it is all about this:

. my "invalid SPI notification" variant (i.e. within an IKE offer) may not work when under DoS. (flooding and rate limiting may prevent a good "invalid SPI" from being sent).  BUT I do not restart IKE unduly, which is good. Bill Sommerfeld's CoB makes recovery faster..

. acknowledgements are good but
    a) slower than direct notifications (need several lost packets, difficult to restart at the right place (phase 1 or phase 2)),

    b) if uncontrolled, may restart IKE for nothing. E.g., Under a DoS, genuine ESP packets with a valid seq# may not reach the destination which in turn could not acknowledge them => forcing an undue rekey.


In order to avoid undue rekeying within the acknowledgements scheme, the peers lacking the acknowledgment send an initialization offer saying:

CKi | SA offers | "because you do not have inbound SPI xxx"

If the recipient DOES have SPI xxx, it simply does not respond to the offer.

Well, there are some more things (no details here) but you got the idea.

I believe that notifications are good (fast and robust) in environments where flooding and such things do not happen (a private Frame Relay network or a direct link for instance).

Acknowledgments are certainly suitable for Internet like medium.

These two methods work together but I would suggest that they can be turned on/off independently.

regards,

	frederic detienne



sankar ramamoorthi wrote:
> 
> >From: Derek Atkins [warlord@MIT.EDU]
> >Sent: Wednesday, January 24, 2001 2:59 PM
> >To: sankar ramamoorthi
> >Cc: fd@cisco.com; sommerfeld@East.Sun.COM; Scott G. Kelly;
> >ipsec@lists.tislabs.com
> >Subject: Re: ipsec error protocol
> >
> >"sankar ramamoorthi" <sankar@nexsi.com> writes:
> >
> >> I think there is some confusion here. The 'invalid spi' is sent
> >> by the host which has lost the SA state (because of reboot or
> >> other means) and received by one trying to send data.
> >>
> >> The rebooted host does not have to worry about the decrypting
> >> the inside ESP packets. It will drop the 'receipt-needed' packets
> >> and the sending host will detect the condition after sending a few
> packets.
> >
> >Ok, so hosts A and B have IPSec SAs, but B is generally communicating
> >with A, with A rarely having anything to say except in response to B.
> >A reboots, losing all state.  B sends an ESP packet to A.  A doesn't
> >understand it, so it builds an invalid spi message to send back to B.
> >B sees the invalid spi message and knows it needs to rekey before it
> >can send anything to A.  Is this what you envision?
> 
> Yes with minor correction,
> 
> B sees the invalid spi messages,
> goes through few levels of steps to assure itself the message
> is genuine and then rekeys.
> 
> >
> >> Yes - there is no authentication of the 'invalid spi' message.
> >> But there are ways to ensure the message is genuine. At the first
> >> level, the 'invalid spi' message can be made to carry some information
> >> about the packet it received (8 bytes just as in icmp). That information
> >> can contain the spi and sequence of the packet for which 'invalid spi'
> >> is being generated. This can be used the receiver of the 'invalid spi'
> >> to ensure that the message is reasonably genuine. It still is possible
> >> that the message has been spoofed. The ipsec control packets
> >> 'recipt-needed' and 'recipt' as described in the scheme can be used
> >> to ensure the message was really genuine.
> >
> >Assuming my last interpretation is correct, an attacker can force a
> >pair of hosts to rekey just by forging an invalid spi message.  All
> >they need to do is be able to copy an ESP packet off the wire and then
> >build an invalid spi message around it.  There is no proof that the
> >invalid spi actually came from the intended recipient.
> >
> 
> Assuming he can send the forged 'invalid spi' packet in some reasonable
> time window from which the original ESP packet was sent.
> 
> Yes, detection of the forged 'invalid spi message' is the problem to be
> solved.
> That is why the receiver of the 'invalid spi' has to take some
> extra steps to ensure the 'invalid spi' actually came from the
> intended recipient before rekeying. The suggested approach outlines
> ways to do that.
> 
> OR
> 
> find ways to ensure the 'invalid spi' message is always authenticated
> (as in the solution proposed by Bill Sommerfeld and Fredric detienne).
> 
> OR
> 
> some variations of these (as in keepalive based solutions proposed in
> the draft by Andrew krywaniuk and others).
> 
> -- sankar --
> 
> >-derek
> >--
> >       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> >       Member, MIT Student Information Processing Board  (SIPB)
> >       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
> >       warlord@MIT.EDU                        PGP key available
Follow-Ups: References: