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

Re: IPv6 Security Last Call Initial Questions


>Maybe this is not the place we will cure this problem .. I imagine
>that taking the economic argument to the folks who pass te laws is the
>most likely place to fix the problem .. from the IETF Briefing at
>InterOp_95 is was pretty clear that there is unamimous support for the
>goal of one encryption methodoly for all domestic and exports .. least
>so said the show of hands.

>Doubt if we will change the view here among our selves.

>I DO NOT SPEAK FOR ANY BUT ME ..  /Ev/

I heard about Interop_95.  I also have seen a grass roots movement since
last night at the IETF when Dan Nessett and I were finally able to bring this 
up in an IPng Forum as it was still on the IPng list for last call.  Its now
on IPSEC.  WHich was not clear to all until last night.

We were able to present our arguments without being interupted and the
issues of REQUIRING vendors to conform to standards that cannot be
exported.  Several users and now other vendors do understand the issue
because we were able to state our case.  So I assure all again I am not
the only one here with this objection.  I only hope this grass roots
effort is exponential.

This will be put together in a last call objection to the IESG. I don't
see any point of discussing it anymore on the list other work is too
important.  The onus is on those of us who believe that MUST any
encryption by any standards org that will force vendors who want to be
IPv6 compliant to not be able to export a product is just WRONG.  
The case will be stated OK.  A product can be IPv4 compliant and not
implement security.  This is how IPv6 should be too.  The market sector
that needs, wants, desires, and requires security for IPv4 or IPv6 will
put out RFP's requiring IPSP with a stated encryption algorithm to make
their market sector interoperable.  If a vendor cannot provide that
security then they cannot bid on that particular venture.  Its very
simple the market will do the right and needed thing.  The IETF just
needs to give them a standard not mandate it in an IPv6 network kernel
protocol implementation.

As a 'user' stated in the IETF.  If I want to purchase systems from
U.S. Vendors in Europe, and I specify that they must be IPv6 compliant,
and then they cannot be IPv6 compliant because they cannot export their
product which requires ESP DES to be IPv6 compliant, that is wrong.

What we need in the spec is an 'if clause before the MUST do encryption
was a suggestion from another vendor (not Dan or I).

About all I can say.  But there is a real grass roots movement and I am
going to keep pushing it with several other members as of right now. I
don't think the issue has been thoroughly discussed or all the problems
put on the table.  This is not fair to the vendor community who in fact
have helped build and support what is the Internet and TCP/IP today.

Look around how many proponents of MUST encryption are system vendors
who ship International products.  How many are system integrators, ONE
country only vendors, or Academics who do not build products or live and
die by the hard rules of business in an International environment.

The IETF wants to be an International Standards Organization.  Well rule
#1 is you don't put MUST standards on the community that is going to
build those standards and provide them in an International market, that
they cannot implement and claim a conformant product.  This to me is just 
common sense.  

Users will have security at Interop_95 that is interoperable without
putting a MUST encryption to be IPv6 compliant.

Note: now I do not believe any encryption should be specified as a MUST,
strong or weak.  And now I think DES is weak and IDEA is strong fyi.

p.s. There is no issue with MUST authentication if that has become
confused.  

/jim