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

Re: Secure remote access with IPsec




Tero, your text looks good and I like this. I'm OK with
notification approach. I also agree with your approach
to require the routability test everytime. There are
situations where you could avoid it, but imho SHOULD
is the right keyword right now; folks that want to work
out optimized signaling sequences can do the work on their
or later to figure out in which cases you can actually
leave it out. Finally, its good to allow the notification
to be sent from either the old or the new address; the
former may make sense when you know beforehand that you
will move.

Nits:

- s/mobile-ip/mobility/
- s/can be send/can be sent/
- s/ip-address/IP-address/ (or IP address)

Jari

> 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.