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

Re: Position statement on IKE development

On the one hand, I agree with Paul that these aren't part of the base
IKE spec (as it stands today) and, unfortunately, there's nothing
IPSRA will be able to do to address them.  So, are we to assume that
the IPSEC WG is responsible for these things?

Judging from the "IKE Position Statement" and follow-up e-mails, it
sounds as if item #1 are to be addressed immediately, while #3 is to
be addressed, possibly, later in 'son-of-IKE'.  However, that leaves
item #2, which I agree with you, should be standardized in IPSec and IS
NOT only "an application issue".

So, I have to ask: who is keeping track of these, and other
requirements, at what point they will be addressed and where is it all
documented?  It seems to me to be good common, and engineering, sense
to put in a draft all the requirements for what we want out of a
'son-of-IKE' and 'next-gen-IKE'.  Then, we can compare the two
requirements docs side-by-side and judge which proposal meets the
needs of the community best.

-shane  




On Tue, Aug 07, 2001 at 01:01:34PM -0600, Horn, Mike wrote:
> <snipped>
> 
> > Speaking from an operator's viewpoint, I have to agree with Mike and
> > other posters in support of jumping over 'son-of-IKE' and, instead,
> > launching a new initiative for a 'next-generation' IKE that is based
> > on a clearly defined set of *requirements* from the operator and
> > implementor community.  In fact, starting with *requirements draft*
> > BEFORE 'son-of-IKE' would be immensely helpful in gathering consensus
> > on whether it is even worth it to do 'son-of-IKE' or just jump over it
> > and start from scratch. 
> 
> I tried to get additional requirements added to the IPSRA requirements
> document, but I was told things like keepalives were out of scope due to the
> "no changes to IKE" requirements.  These are some of the replies I got from
> Paul Hoffman when I suggested additions to the requirements draft.
> 
> Mike Horn: 1) The IRAS and IRAC SHOULD support NAT traversal.
> Paul Hoffman: We don't yet have a standard for that.
> Mike Horn: 2) The IRAC SHOULD support redundant gateways.
> Paul Hoffman: This is an application issue, not a protocol issue.
> Mike Horn: 3) The IRAS and IRAC SHOULD support a keepalive or make dead
> mechanism.
> Paul Hoffman: We don't yet have a standard for that.
> 
> I thought the point of a requirements draft was to clearly define the things
> that need solutions, not how to use existing solutions.  
> 
> Mike Horn
References: