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

Re: IPv4 Security redux

On Apr 19, 14:33, Jim Zmuda wrote:
> Subject: Re: IPv4 Security

% Well, the idea of putting this on the list was to find out if it was
% desirable to include this as a requirement.  Please note that this
% requirement doesn't imply that we choose the same protocol as the ISO
% folks, but just that whatever we do can be made to work in the ISO
% world - and I do recall a consensus being reached that this was a
% requirement - explicitely that whatever we do now not will not have to
% be redone when IP:TNG comes along.  If one includes the possibility
% that that could be CLNP, then one has to include the capability to
% grow to CLNP...things which NLSP's Protocol ID byte, and TLV-encoded
% address fields directly support.  And unfortunately, it is not a
% simple matter of just slapping on a convergence protocol containing a
% PID in front of IPSP, because that would screw up word orientation for
% upper level protocols - something you don't want to do, even in this
% context (apparently byte-oriented network layer protocol).

Let me briefly revisit the above.  

  In particular, using NLSP syntax favours one of the IP:TNG proposals
at the expense of the other proposals.  This is not a legitimate thing
to do -- we must be careful to be proposal-neutral with respect to
IP:TNG.  A convergence protocol WILL work fine for NLSP.  Adding PIDs
and such ISO-centric items to the IPv4 Security Protocol is biasing
towards ISO and against not only IPv4 but also the other IP:TNG
proposals (e.g. SIP, which uses a payload-pointer scheme).  

  I think that reuse of the IPv4 Security Protocol work for IP:TNG
should be limited in scope to the mechanisms and not include syntax
reuse because several of the IP:TNG streamline syntax even more from
the IPv4 syntax (which is a WHOLE LOT easier to parse than ISO
syntax).  I really thought we had agreed to mechanism-reuse rather
than syntax-reuse during the Ohio meeting.  ISO-centric items such as
PIDs are syntactic glue rather than being real security mechanisms and
should not appear anywhere in the IPv4 Security Protocol.

  Agreeing fully on all requirements in a legalistic style is
certainly conventional in the ISO world.  However, here in the IETF
the process is "rough consensus" and avoidance of rigid definitions.
I think we should be careful not to let ourselves get bogged down into
a legalistic style of operation and instead should use the
conventional more flexible IETF style.  After all, we are working on
security for _IPv4_ in this group.

% My list of the requirements I thought (and still do) we had agreed to
% review for inclusion in IPSP looked like this:

  - PID  (Issue for debate!)

  There was NO consensus in favour of the PID and in fact there has
been consistent vocal objection to its inclusion.  It should not
appear in the "list of requirements [that] we had agreed to" include.

* basing formats on NLSP (a rancorous issue for debate!)

  See above.  There was clear vocal opposition to basing anything on
NLSP syntax.

* Sequence integrity (swIPe has, NLSP-CL doesn't.
  Almost agreed to drop.  Still an "issue" for E-mail debate.)

  Did not "almost agreed to drop".  Did discuss at length with
  no real consensus either way.  Several comments that an online
  spec of swIPe is needed soon.

* works with CLNP, as well as IP

  Absolutely did NOT agree to.  Strong, clearly expressed objections
to this, though there was consensus that the _mechanisms_ (e.g.
datagram encapsulation) should be reusable for ALL of the IP:TNG
proposals (certainly not just CLNP).  This MUST NOT appear as an
agreed upon requirement because it most assuredly was NOT agreed to in
the form presented above.

* Overhead

  Almost certainly this should read "Low Overhead" ???

* efficiency (including emphasis on compact encoding suitable for low-speed 
links)

  Best expressed as "Scalability -- protocol viability over low-speed links 
  scaling upwards and also being viable over very high-speed 
  gigabit/second links.

I'd add one:
* Explicit per PDU labelling/versus implicit labelling

Ran
atkinson@itd.nrl.navy.mil

P.S.
  Someone in private email noted that there is apparently some DoD directive
saying that we must move towards OSI.  Let me observe (not speaking officially
of course) that exemptions from that for backwards compatibility with IPv4
are easier to obtain than Ada exemptions.  Rate of installation of IPv4
continues to be much faster than rate of GOSIP installation in all parts
of the government that I deal with...
References: