[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Secure remote access with IPsec
Francis Dupont writes:
> => note that when NAT-T is not activated we need an explicit protection
> of the peer addresses (notifications like NAT-DETECTION-*-IP carrying
> the full address and port) so the only guy who can put fake new addresses
> is the peer.
Yep, that is the reason for the SOURCE-ADDRESS-CHANGED notification
(i.e it says the address have changed, and the new ones are here).
> The explicit address update is done by sending
> SOURCE-ADDRESS-CHANGED notification, having new port and ip-address
> inside, to the other end.
>
> => so new port and address don't need to be inside the notification
> because they are inside the (protected) message.
The new address and port need to be somewhere in the protected
message, thus they do need to be in some notification. I do not want
to reuse the NAT-DETECTION-*-IP for them, so it is easier to simply
put them to this notification.
> This notification can be send either using
> the old or new address, but the sender MUST be able receive in the new
> address before sending this out.
>
> => I disagree: there is no problem to require they are sent using
> the new address.
To be able to respond the return routability check we need to be able
to receive in the new address.
> When receiving the SOURCE-ADDRESS-CHANGED notification the IKE process
> MUST check that the other end can receive the packets sent to new
> address, by sending empty notification to the peer addres and port
> given inside the notification (not the UDP outer address).
>
> => I disagree: this return routability check should not be mandatory,
> i.e., one MAY trust its peer. But IMHO it should be explained (as it
> adds in fact nothing in the protocol it is free) and a config knob
> should enable it. We have to provide the default value for this knob,
> I am in favor of ON, i.e., perform the check by default.
I think it is mandatory. Note, that this is protecting another kind of
attack:
Lets take example. www.videos.cnn.com is offering HDTV level video
streams, but only with oppurtunistic encryption. Alice connects to
this service and starts video transfer from the www.videos.cnn.com.
After the video stream is going Alice, decides that he wants to really
be Malice, and sends authenticated SOURCE-ADDRESS-CHANGED packet to
the www.videos.cnn.com and says that his new address is Bob's address.
If the www.videos.cnn.com does not do the return routability check
then it will diver this 10 MBit/s video stream from Alice/Malice to
the Bob's ADSL line blocking it completely.
If the Bob is smart enough to be running IKEv2 and IPsec, he can
recover, but if he does not know anything about IKEv2 and IPsec only
think for he to do is to call the cnn and ask for their help to stop
the sending the video feed. If he supports IKEv2 he will be seeing
traffic to unknown SPI, thus he will send unauthenticated IKEv2
notification to the www.videos.cnn.com about invalid SPIs and when the
www.videos.cnn.com receives that, it will start dead peer detection to
see if the IKEv2 SA is still up. Bob will not reply to that and after
IKE timeout the www.videos.cnn.com will drop the IKEv2 SA, IPsec SA
(i.e the attack stops).
> This change affects the IKE SA used to
> receive the notification (i.e all future exchanges started on that IKE
> SA will use this new address) and all child IPsec SAs created by this
> IKE SA (i.e tunnel endpoint updated to new address).
>
> => I disagree: we need more fine grain stuff for multi-homing.
Do we? I think it is easier to gain that with multiple IKEv2 SAs each
having the IPsec SAs that are tied together.
> What I propose is to put the list of affected SAs in the notification
> with an "all SAs" flag which does exactly what you describe with
> a restriction for proxy case SAs which must be never affected.
I do not think we want to put that in there now. I think we can
postpone that until later.
> The reply to the original SOURCE-ADDRESS-CHANGED notification is sent
> back to the address where it was received, as is also all other
> requests, where reply is not yet sent (i.e they follow normal rule,
> that the reply is sent back to the address where the packet
> originated). Note, that all hosts are required to process this
> notification while waiting for reply to their SOURCE-ADDRESS-CHANGED
> notification (see section 2.3).
>
> => is this text really useful?
Hmmm... it seems to be little unclear. The thing I was trying to say
there is that the IKEv2 mandatates that if you have one exchange going
out you must be able to process another exchange coming in. I.e when
you send SOURCE-ADDRESS-CHANGED notification to the other end and the
other end does the return routability check (using informational
exchange and notifications), then you must be able to reply to that.
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/