[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MM with signatures and dynamic IP addresses?
Hi Francisco,
francisco_corella@hp.com wrote:
>
> Ari,
>
> We were just discussing pretty much this same issue in another thread.
>
> The issue also arises in other scenarios, and there are cases where the
> initiator rather than the responder faces the issue. For example:
>
> (*) The responder has a dynamically assigned IP address. The initiator is a
> security gateway negociating on behalf of a client. The client knows the
> dynamically assigned IP address of the responder, but the gateway does not. The
> client requests the establishment of a phase 2 SA with that IP address. The
> gateway must first set up a phase 1 SA with that address, but does not know who
> it is talking to until it has received the ID payload from the responder during
> the phase 1 exchange.
>
> (*) The responder has a perfectly normal statically assigned IP address. The
> intiator is a gateway with a policy for the responder, but the policy is indexed
> by the distinguished name of the responder rather than by the IP address. A
> client of the gateway requests an SA with the IP address of the responder, and
> the rest is as above.
>
> Notice that the above two cases cannot be solved by the use of aggressive mode.
For both of these cases, how does the client request the establishment
of a phase 2 SA with that IP address? If this is done via some sort of
signalling protocol, then perhaps the client could give some identity
information along with its request. The case where the negotiation is
activated by the sgw's receipt of a packet from the client to the
responder is less clear. If aggressive (or base) mode were used, it is
possible that that the intitiator would discover upon receipt of the
responder's SA+ID payloads that the selected parameters are not
acceptable, but recovery would not be too complex: fail the negotiation
and re-initiate based upon the supplied ID. However, see further
comments below.
> In my opinion, the solution to this is very simple: have a policy for phase 1
> that is independent of the peer. After all, one of the roles of phase 1 is to
> find out the identity of the peer, so it does not make sense to make phase 1
> policy dependent on who the peer is.
Now I see where you've been going (at least, now that we've arrived
:-)). I think I like this, but there is still the issue with the binding
of the IDs to the phase 1 SA that I mentioned earlier. However, this is
resolved by the use of one sgw ID cert with bindings authorizing the sgw
to represent specific endpoints. In that case, authorized phase 2 IDs
(DNs, etc) are included in the phase 2 ID payload, so that one duly
authorized phase 1 SA may be used for any/all of them provided that PFS
is not required. I should note that the sgw cert+bindings is not my own
idea, and that I gleaned it from an off-list email exchange.
> I believe this solution is consistent with RFC 2401. Perhaps it is even the
> behavior that was intended by the authors of RFC 2401. Am I right? In any
> event, a clarification in RFC 2401 would be useful.
I also believe that this is consistent with RFC2401.
Scott
Follow-Ups:
References: