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

Re: Results of the IPSEC document reading party



At 13:22:34 PST on Tues, 23 Dec 1997 John Burke wrote:
> At 11:25 AM 12/23/97 -0800, Daniel Harkins <dharkins@cisco.com> wrote:
> >  Alexei, 
> [ "Alexei V. Vopilov" <alx@elnet.msk.ru> wrote ]
> >> -------------------
> >> This observation of ISAKMP-OAKLEY-05 
> >> 
> [ ... ]
> >> :  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.
> [ ... ]
> >  c praznikom,
> >
> >  Dan.
> 
> Is this in fact consensus?  I.e. that you're not allowed to use two
> Proposals in an ISAKMP-SA offer, but must use one with multiple Transforms.
> It is, as Dan says, not spelled out and it's strictly arbitrary.  Did an
> ISAKMP author (Doug) announce his intention to include such a limitation in
> the next version of the draft?

I'll leave it up to the co-chairs of the IPSec Working Group to define
what constitutes concensus on a particular issue. No, "an ISAKMP author 
(Doug)" did not announce this but an ISAKMP/Oakley author (me) did. Is that
unacceptable to you?

> Our implementation accepts offers structured either way; in offers which we
> send, the structure can be explicitly configured either way.  As things
> were last September (last bakeoff), doing otherwise seemed brain-dead to
> me; implementors shouldn't be forbidding variations allowed by the draft.
> I don't see why the draft should introduce limits like this at this late
> date, in absence of strong arguments.

What seems brain-dead is to have another configurable option to give to the
administrator which will ultimately have absolutely no impact on the system.
That's a recipe for confusion and frustration. 

The motivation for doing this was to prevent confusing but legal offers like:

   SA, prop1, trans1, trans2, prop2, trans1, prop3, trans1, trans2, trans3 

What is the sender of this trying to convey? It is arbitrary and confusing.
We decided that not allowing people to be arbitrary and confusing when
negotiating security parameters is good and this was declared illegal. It 
also has the potential (depending on specific implementations your mileage
may vary) to simplify what are already very confusing parsing rules.

Phase 1 negotiation can only result in a single SA (unlike phase 2 negot-
iation); that single SA can only be one possible protocol (unlike IPSec SAs);
the logical relationships possible with IPSec-- eg ((X AND Y) OR Z)-- are not 
possible with the single ISAKMP SA; and, there is no "SPI" for this proposal.
So the only thing possible with multiple proposals for an ISAKMP SA is to have 
them all be identical except their proposal numbers which are monotonically 
increasing which means logical "OR". By making this limitation we are in no 
way limiting the things that can be expressed, only limiting the way they are 
expressed; we are forcing people to be clear and consise. 

This simplifies security parameter negotiation and does not limit the things
that can be described in offers. Aside from easing your UI and documentation 
burden what impact does this have on you? 

  Dan.



References: