[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Secure remote access with IPsec
antonio.forzieri@cefriel.it (Antonio Forzieri) writes:
> - NAT-T capability are enabled in IKEv2, and I think it works well (what
> about let IKE speaks on UDP 4500 directly even when there isn't NAT-T
> function enabled? What's wrog with that?). I know the pseudo-NAT
> problem, however I think that an attacker on the path could easily
> delete all the message.
The current IKEv1 NAT-T requires that implementations MUST be able to
handle initial connections coming to port 4500. I think this should be
taken to IKEv2 also.
> - IPsec is well integrated with MIPv6
> [draft-ietf-mobileip-mipv6-ha-ipsec-03.txt], so we can think of a mobile
> node connecting back to his Corporate Network, without need rekeying
> when it changes his address (can we change the selectors of a SA or an
> entry of the SPD upon the receiving of a BU message?)
I was talking with Jari Arkko about this last night, and I came up
with following proposal:
----------------------------------------------------------------------
2.25 Explicit Address Updating
For some cases there are needed for explicitly update the peer
address. This can be used to support mobile-ip, multihoming, and to
help SCTP support. The difference with implicit address updating, is
that in this case the other end can actually notify the other end
about the change in the address, and authenticate the new address (and
port). The explicit address update is done by sending
SOURCE-ADDRESS-CHANGED notification, having new port and ip-address
inside, to the other end. 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.
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). When the
host requesting the change replies to that notification, and proofs
that it can actually receive packets sent to that address the actual
change should take effect. 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).
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).
This requires implementations to support mutating the already existing
SAs (one way to implement this is to atomically delete the SA and then
add it back with new information). Similar feature is also needed for
the implicit address updating needed for NAT traversal, where we need
to update the UDP encapsulation addresses and ports.
----------------------------------------------------------------------
Following text should be added to section 3.10.1 after
HTTP-CERT-LOOKUP-SUPPORTED:
----------------------------------------------------------------------
SOURCE-ADDRESS-CHANGED 24587
This notification is sent when the other end has changed
its IP-address and wants the responder of this
notification to update the IKE SA remote peer address and
port. When this notification is received the host MUST
do the dead peer detection against the address given in
this payload, and if that is successful then the IKE SA
peer address and all the child SA tunnel endpoint
addresses MUST be updated to new address. This
notification is not used in the NAT traversal case, as the
host behind NAT does not know when its address changes.
The data associated with this notification is 2 byte port
number and 4 or 16 byte IP-address.
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/