[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: quick mode "proxy" case
Hi Francis,
To add to ur question can anybody tell me how do we specify
address range, say IPV4addressrange in proxy mode using identity payloads.
Also what i couldnt understand was, are u interested in IKE or IPsec role.
Since IKE doesnt care whether its Tunnel or transport. It just exchanges the
attributes and IDi,IDr. Local policies in IPsec does the rest
Regards
Saket.
----- Original Message -----
From: "Francis Dupont" <Francis.Dupont@enst-bretagne.fr>
To: <ipsec@lists.tislabs.com>
Cc: "Jari Arkko" <jari.arkko@kolumbus.fi>
Sent: Tuesday, September 10, 2002 7:22 PM
Subject: quick mode "proxy" case
> RFC 2409 specifies:
>
> The identities of the SAs negotiated in Quick Mode are implicitly
> assumed to be the IP addresses of the ISAKMP peers, without any
> implied constraints on the protocol or port numbers allowed, unless
> client identifiers are specified in Quick Mode. If ISAKMP is acting
> as a client negotiator on behalf of another party, the identities of
> the parties MUST be passed as IDci and then IDcr. Local policy will
> dictate whether the proposals are acceptable for the identities
> specified. If the client identities are not acceptable to the Quick
> Mode responder (due to policy or other reasons), a Notify payload
> with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent.
>
> In order to make the discussion clearer I propose this terminology:
> - for these phase 2 identities: "traffic selectors"
> - for the case where the initiator acts on behalf of another party:
> the "proxy" case
> - for the "local policy" requirement: "authorization".
>
> The question is: [how] do you implement the "proxy" case for
> transport mode? (please provide the interesting details!)
>
> Regards
>
> Francis.Dupont@enst-bretagne.fr
>
> PS: a better wording for the SOI should be wellcome (as I am afraid
> this is rarely implemented because not understood or not understable
> by users).