[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Results of the IPSEC document reading party
Alexei,
> -------------------
> This observation of ISAKMP-OAKLEY-05
>
> ISAKMP-OAKLEY-05 states:
>
> > Using Quick Mode, multiple SA's and keys can be negotiated with one
> > exchange as follows: Initiator Responder
> > ----------- -----------
> > HDR*, HASH(1), SA0, SA1, Ni, [, KE ] [, IDci, IDcr ] -->
>
> COMMENT: If it is achieved with 'next payload == SA' inside the beginning
> of 'SA0' payload, it should be denoted in the ISAKMP draft sec 3.4
>
What is it exactly that you don't like about 3.4? It says if it's the last
payload then its "next payload" field is zero; if it's not last then its
"next payload" field is the next payload. The next payload for SA0 is SA1
and that's an "SA payload" (1). Then next payload of SA1 is Ni and that's a
"nonce payload" (10).
> Other comments:
> -------------------- Theodore wrote:
>
> :
> : 1. DOI of 0 in phase 1 says to use the ID semantics from the base
> : ISAKMP draft but the base ISAKMP draft doesn't define any semantics.
> : A minimal set of ID types has to be added to the base ISAKMP draft.
>
>
> Sorry, but the ID types are clearly defined in the DOI document.
> I did not find in DOI(6?) where it refers to ISAKMP for ID type.
It won't. The DOI value specifies which document to look in for the
appropriate semantics. Value 1 means look in the "IPSec DOI"; value 0
does not. If you put a zero as the DOI type in a phase I offer the ID
semantics are not those of the IPSec DOI, they are those of the base ISAKMP
document which, as is noted above, does not yet have them. It must.
> :. . .
> : 1. should mention that phase 2 proposals that are logically related
> : must be consistent and if PFS is desired the same group must be in all
> : proposals.
>
> That also requires to define the 'logically related proposals' term.
We've got to put a stake in the ground somewhere otherwise we'll have an
incredibly pedantic document. Is "logically related proposals" ambigouous
to you?
> : 2. should mention that phase 1 SA offers consist of a single proposal
> : with possibly multiple transforms and not multiple proposals-- the
> : protocol has to be ISAKMP anyway so multiple proposals doesn't really
> : make sense.
>
> Sorry, but the proposal payload itself does not really make sense for
> an _ISAKMP SA_ , as well as the 'SA' term does not really correspond to
> an _ISAKMP SA_. It's just reuse of ISAKMP syntax and probably in the
> not best way.
How do you negotiate ISAKMP SA parameters then? Of course the proposal payload
makes sense for an ISAKMP SA. The issue is does one have a single proposal
with possibly multiple transform payloads or does can one have multiple
proposal payloads each with a single transform payload? It was never spelt
out whether the latter is "legal". The consensus was that it is not.
> :. . .
> : 2. Arch doc seems to mandate that the "first" SA bundle be used to
> : protect targeted packets and not the most restrictive. E.g. if there
> : are SAs in the SADB currently for:
> :
> : all packets from net A to net B
> : all telnet packets from host a to host b
> : all packets from host a to host b
> :
> : (in that order) and a telnet packet from host a to host b comes along
> : the most restrictive SA (the one with the most exact matches vs. wild-
> : card matches), the one specifically for telnet packets from a to b
> : should be used and not "the first".
> :
> : I'm not sure I agree with this contention but the issue did arise.
> : As an aside, we (cisco) _always_ use the most restrictive SA as that
> : seems the best way to build and properly use shared SAs.
>
> Although it is possible (and reasonable) to employ 'most restrictive SA'
> approach for an Identifiers such as ID_IPVx_ADDR_SUBNET, an attempt
> to use the same for ID_IPVx_ADDR_RANGE identifiers leads to solving
> the problem of defining term 'most restrictive' for overlapped ranges.
> Don't think it is even possible.
> In turn, the requirement of arch draft about 'the SPD entries order'
> does prevent to deploy 'most restrictive SA' approach and does not
> solve the problem with ambiguous policy choices during creation of
> particular SA.
You're right that might not even be possible. What I was trying to capture
was the general feeling at the "reading party" that the language is a bit
ambiguous. "first" means different things to different implementations and
that it would be better to be more explicit. If we negotiate that all
communication between two particular subnets, subnet A and subnet B, uses
ESP with DES and HMAC-MD5 but all communication between host a (which is on
subnet A) and host b (which is on subnet B) uses ESP with 3DES and HMAC-SHA
then I must protect packets from a to b with the unshared SA using 3DES and
HMAC-SHA-- the "most restrictive" one-- not the shared SA using DES and
HMAC-MD5.
This is also an interoperability issue. If one party constructs a FIFO of
SAs, the notion of "first" may be different than one that constructs a tree
of SAs. Parties may (no, must) drop each other's traffic because it doesn't
match their policy.
But, as I noted, this issue was outside the scope of this particular clique
at the party. I mentioned it only because it came up in discussion.
c praznikom,
Dan.
References: