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

Re: Results of the IPSEC document reading party

Hi, Daniel.


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


If I got the right idea, a next to a SA payload is a 'Proposal payload',
but the SA 'next payload' field is never filled with the 'Proposal payload'
value. Probably, the name of the field should be other than 'next payload',
say, 'next context-depended payloads group' ;-)
Seriously, the semantic of ISAKMP goes far beyond simple parsing rules...

:[. . .]
:
: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.

OOPS, I did not even find in ISAKMP-08 that value = 0 is reserved by
base ISAKMP document. For me DOI=0 is reserved by IANA, not by ISAKMP.
Sorry.

:[. . .]

: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?

VERY!
Do proposals for the same SA under same Proposal N are logically related?
Do proposals from the same proposal list are logically related?
Do proposals of a SA bundle are logically related?
Do all proposals from the same ISAKMP message are logically related?

:[. . .]
:
: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.

If ISAKMP states that any payloads order should be supported, why not
allow the latter case? BUT if there was the consensus on that -
no more questions.

:[. . .]
:> 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.

I agree with you since did the same.
IMO, what could keep IPsec from interoperability troubles is either
of two approaches:
(I like first but vote for latter as less-complicated for now)

1. - Remove mention about RANGES from ID payload
   - Keep the notion of port the same and never introduce a ranges in future
   - Employ 'most restrictive approach' whenever it is possible.

2. - Remove everything that implies a wildcard for addresses,
     protocols and ports to make traffic discrimination
     the straightforward operation.
   - Add to ISAKMP support of two negotiation types
     (actually should be done in any case)
     a) Join particular TCP/UDP/ connection to a specified SA
     b) Remove particular connection from a specified SA

AND work hard on the definitions of Security Policy Management
scope and functionality (in IPsecond)!
I will return to FIFO and TREE problem sometime later,
you are right again: it's not in the scope of current job,
unfortunately.

:  c praznikom,
:
:  Dan.


Thank you and Merry Xmass to you all!

(Here we have Xmass celebration at Jan 7, but a new year comes in the same date
;-)
--Alexei