[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ipsec error protocol
Hi,
Apologize for the late response. Got tied up in something else.
>From: owner-ipsec@lists.tislabs.com on behalf of Frédéric Detienne
>[fd@cisco.com]
>Sent: Wednesday, January 24, 2001 11:34 PM
>To: sankar ramamoorthi
>Cc: Derek Atkins; sommerfeld@East.Sun.COM; Scott G. Kelly;
>ipsec@lists.tislabs.com
>Subject: 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".
No, it is more like 'acknowledgements-when-needed'
>
>Take my first emails and re-read: acknowledgments are better.
>
acknowledgements only when needed is still 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 :)
Yes, but not all error/packets though, only the 'receipt-needed' type of
control packet.
>
>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.
>
I do not understand what you have in mind for the semantic of
acknowledgement field.
Yes, it would be nice to have an 'RECEIPT-NEEDED' and 'RECEIPT' type of
flags
in the ESP. It would also be nice to have versioning in ESP.
Any reason why versioning was left out of the initial ESP design?
>
>
>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..
As for as I understand the scheme, you have
O
peer wih out-of-sync/no ipsecSA peer sending data
step1
send ESP data
<-----------------------
no ipsec or ike state with
peer. send notification
step2
send 'invalid spi'
notification (signed?)
------------------------>
step3
initiate directed-ike phase1
or phase2 exchange
(ike for a particular reason)
sa proposal + 'because you do
not have SA xxx'
<---------------------------
if reason is satifactory
respond to IKE exchange
from peer
step4
--------------------------->
responder proposal (2nd
message of ike exchange
sa proposal + 'because I did
not have SA xxx'
Seems to be a neat way to avoid passive attacks. However the
initial IKE message is not authenticated and it now carries
additional information. What are the kind of attacks possible?
Comparing this with an ESP based scheme..
The receiver of 'invalid spi' has to go through the first 2 IKE
exchanges to ensure that 'invalid spi' is genuine. It means timers
have to be maintained, and the first IKE message has to be sent
several times to get through. Since the same cookie is now
resent on every retry, does it offer more information for the
attacker?
The sender of the 'invalid spi' also has to remember that it
sent the 'invalid spi' message to a peer. Otherwise someone
could send a 'invalid spi' of some random spi and force it to
start the series of directed IKE exchange. Remembering all the
machine to which 'invalid spi' was sent seems an additional
burden and open to DOS attacks.
>
>. acknowledgements are good but
> a) slower than direct notifications (need several lost packets,
Yes - but how fast do you want to recover?
Autenticated (replay proofed, DOS protected) notifications are best
for immediate recovery, but it seems such a difficult
problem to solve and any solution seems too heavyweight.
With the ipsec error protocol, speed of recovery is left to the
implementation. If one side needs a very fast recovery, a keep-alive
equivalent protocol can be implemented using the messages provided
in ipsec error protocol. For normal operations a triggered acknowledgement
scheme seems sufficient.
> difficult to restart at the right place (phase 1 or phase 2)),
>
not true.
As I mentioned earlier, 'invalid spi' ipsec error is sent only
when there is no phase1 SA with the peer. If there is a phase1 SA
it should always try to use 'invalid SPI' ike notification using the
info exchange. Getting 'invalid spi' ipsec error in the clear implies
the peer has lost both phase1 and phase2 state. If the receiver of
the 'invalid spi' can assure itself the message is genuine, it can
start phase1 exchange right away.
> 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.
>
Agreed. This is a problem. But if genuine ESP packets cannot get through,
the rekeys also won't succeed, which can give an early indication of
something
is wrong.
>
>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"
>
neat - however the message is in the clear and not authenticated.
What are the possible attacks on this?
>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 still do not fully grasp the proposal. I will wait for more explanation
from you.
>
>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.
>
Agreed - but I feel the authenticated notification is a harder problem
to solve. I still have not fully grasped the finer details of the
solution proposed by you and Bill Sommerfeld. I guess I will wait for
your draft. Good luck,
-- sankar --
>regards,
>
> frederic detienne
>
Follow-Ups: