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

Re: IPv4 Security


All,

On Apr 14, 14:41, Randall Atkinson wrote in reply to an earlier message of mine.

In his message Ran took exception to a couple of the requirements for IPSP that I had listed in my message.

The requirements that Ran took exception to were:

1. >>* basing formats on NLSP (a rancorous issue for debate!)
   >
   >  I think there are a fair number of us who have real problems with
   >ISO OSI syntax and format conventions.  One of the major advantages of
   >the Internet suite has been its streamlined syntax...  

NLSP formats are not really all that bad. Any protocol that can be described in
one viewgraph*, as NLSP can, can't be that overly complex. I agree with you,
the real problem with the NLSP spec is that it is written in ISOese and not 
plain english.  However, we shouldn't let that color acceptance of the protocol
if it, in fact, is useful.  As far as the inefficiencey of TLV encoded fields 
goes, most of the NLSP fields are fixed format. In fact, if we do some 
reasonable profiling (limit PDU lengths to 30,000 bytes or less) we find that 
the first 14 bytes (excluding the Sync overhead in this count) of the NLSP 
header are fixed format (including the Clear Header,  and up through the Data 
Type byte of the Protected Contents). TLV encoded fields are used only to encode
the address fields, label field, data field (a mistake, I'll grant that - which
I'm working to change), and pad field.  

Depending upon how we profile the NLSP-CL, we could eliminate the address
fields. (They are implicit in the use of a particular association, and therefore
add no value).  This leaves the label fields, data, and pad as TLV encoded.
I maintain that any approach that allows explicit labels to be carried
is likely to end up with a TLV encoded value for its label field as well.
Witness the IPSO.  Therefore the delta in terms of encoding format is minimal.

In short, NLSP-CL really isn't that bad, once you profile out the useless parts.

2. >>* works with CLNP, as well as IP
   >
   >  This is most certainly NOT a requirement for me.  My GOSIP
   >transition plan is from IPv4 to IP:TNG only.  I think this is unduly
   >restrictive and it isn't clear to me that there was consensus that
   >this was a requirement...  

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).

Finally, my intent in putting forward the list of requirements from the IPSEC WG
meeting was to get the ball rolling on coming to closure as a group on the set
of requirements that we thought should be addressed by IPSP.  Achieving a
consensus on the requirements for IPSP first (before moving to a discussion of
formats and implementations) is a good place to start, for the obvious 
reason, as well as the fact that it looks like we wouldn't get far with any
other approach. 

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

* Clear Header
  - Security Association Identifier
  - PID  (Issue for debate!)
* basing formats on NLSP (a rancorous issue for debate!)
* Sequence integrity (swIPe has, NLSP-CL doesn't.
  Almost agreed to drop.  Still an "issue" for E-mail debate.)
* Fragmentation.  (We all agree to not handle within the security
  protocol. Not needed for ES implementation.)
* "peak through" (filtering routers problem)
* Word alignment (needed for efficient implementation of some upper layer
  protocols, like NFS.)
* Padding
* ICV
* works with CLNP, as well as IP
* Overhead
* efficiency (including emphasis on compact encoding suitable for low-speed 
links)
* Encipherment
* key Managment
* Negotiation of services
I'd add one:
* Explicit per PDU labelling/versus implicit labelling

Regards,
Jim Zmuda

*I regret not handing out my slides
Follow-Ups: