[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Results of the IPSEC document reading party
Three own observations followed by
'comments on comments' as per Theodore message.
-------------------
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
-------------------
This observation of Section 4.4.1 of DOI :
> As a result, the protocol suites listed below
> form the set of protocols that can be negotiated at the same time.
. . .
> Protocol ID Value
> ----------- -----
> RESERVED 0
> PROTO_ISAKMP 1
> PROTO_IPSEC_AH 2
> PROTO_IPSEC_ESP 3
> PROTO_IPCOMP 4
COMMENT: The PROTO_ISAKMP and any other cannot be negotiated at
the _same_ time.
--------------------
This observation is of ISAKMP-08, 'Delete SA' payload definition.
(I'm not sure it was already cleared at least in the list discussion)
COMMENT: It is not clear what to use as SPI value when notifying on
deletion of ISAKMP SA.
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.
:. . .
: 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.
:
: 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.
: . . .
: Issues outside our scope that came up anyway
:-------------------------------------------------
:
: 0. there is no way to negotiate cascaded SAs. This may be moot based on
: the results of the Arch+DOI parties.
SAs bundle, Multiple SAs, Multiple SA proposals, Cascaded SAs.
Should they all be differentiated in some 'well-known',
probably in arch draft?
:. . .
: 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.
Regards,
---
Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694
Software Architecture&Development Consultant.
---
Follow-Ups: