Subject: RE: Requirements Draft

From: "Horn, Mike" <[email-masked]>
Date: Tue, 10 Jul 2001 19:08:42 -0600

I guess my point is that "We don't yet have a standard for that."  Without
it being explicitly stated as a requirement, how will it ever become
standardized?  Additional comments inline.

<trimmed>

> 
> There is a big difference between market desires and market 
> requirements. There are many very successful products available that 
> do not match more or more of the features you list below.
>

I do not agree.  Name one client vendor that is not claiming to support
XAUTH.  A quick search shows the following vendors currently supporting it
include Lucent, Cisco, SSH, Symantec, Nortel, IRE [SafeNet], etc.  The list
is almost as long for NAT traversal.  If these weren't really market
requirements I don't think all these vendors would have implemented
proprietary solutions to meet the requirements I list.

> >1) The IRAS and IRAC SHOULD support NAT traversal.
> 
> We don't yet have a standard for that.

Should it not be _explicitly_ stated as a requirement?  The problem is
generic to IPsec, but it has the biggest impact in the remote client
implementation.

> 
> >2) The IRAC SHOULD support redundant gateways.
> 
> This is an application issue, not a protocol issue.

Sometimes there are required enhancements to the protocol to make redundancy
work properly.  For instance dynamically passing a secondary SGW to the
client upon tunnel establishment would be a nice thing to have.  Also
keepalives (or makedeads) are important.  I can think of several other
redundancy features that might  also require protocol enhancements.

> 
> >3) The IRAS and IRAC SHOULD support a keepalive or make dead 
> mechanism.
> 
> We don't yet have a standard for that.

See my comment on NAT traversal.

> 
> >4) The IRAS SHOULD support auditing of the assigned VIP, 
> public IP, and
> >username in addition to the start and end time.
> 
> Auditing is not covered in this WG.

Then why is auditing stated as a requirement at all?  If you are going to
capture start and end times, there is some useful information that could
also be captured.  One thing that I don't see being covered anywhere (except
potentially with DHCP) is the VIP.  This could be critical in auditing a
security event.

> 
> >5) The IRAS and IRAC MAY support load balancing.
> 
> It can't be a requirement and a "MAY" at the same time. And, again, 
> it's not a protocol issue.

Ok. Make it SHOULD.  Again see my comments on redundant gateways.

> 
> >I understand these issues might fall into a gray area 
> between the IPSRA and
> >IPSEC working groups, but these are true needs of the user 
> community and
> >should be addressed.
> 
> They are being addressed by many vendors.

Without consensus from the IETF WG's!!  This is a major stumbling point for
many IPsec technology deployers.  I need to use a specific client with a
specific SGW to get the functionality I need.  That is not what standards
are about.  I wish everyone was ready to embrace PKI, but to date that has
not happened.  Also, it is interesting that the focus of this WG is supposed
to be primarily legacy authentication support, but the first approved
standard is for DHCP.

> 
> >   I think the requirements draft is the  right place to
> >capture user requirements, it shouldn't mandate the 
> solutions for how these
> >requirements are met, but it should clearly define the needs 
> of the user
> >community.
> 
> Again, "needs" is probably too strong a term to use here.
> 
> --Paul Hoffman, Director
> --VPN Consortium
>