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

Re: Draft Charter IPSEC WG


I'm a little concerned that the wheel is going to be reinvented here
yet again.  Not that it shouldn't, just that it might.

The main reasons [SP{2,3,4}|{N,T}LSP] efforts have not "culminated in a
usable protocol" are threefold, as I can see:
	
	1. an unfortunate choice of securing a stack that nobody uses
	2. delays and overdesign caused by unproductive religious 
	   bickering over layer issues
	3. the fact that not enough people actually feel they want it

I can do something about the first two, like compromise my own sometimes
too dug-in positions, but I have been at wits end to deal with the third.

I have been as guilty as this group seems to be of the "it we build it, they
will come" mentality.  We built it, and they didn't come.  Others built
it, too, and a few potential users came by and sniffed, but rarely did
anyone buy except under duress.  I'd feel better if there were some actual 
quantification of need, expressed in a public forum, with potential users
(not "the government and the banks") actually identified.

Sorry to be so negative, it's based on years of fun.

Now some more constructive comments, on Alton Hoover and Paul Lambert's
Draft charter.

1.  What do you mean by "access control"?  Do you mean labelling? Packet
    filtering?   This should probably not be an early requirement. 

2.  Sprinkle "algorithm independence" in somewhere.

3.  What do you mean by "integrity" for a datagram service?  This is a snake
    pit if you are worried about replay.

4.  "Subnet-to-subnet ... recursive ... encapsulation" is a bit too specific
    for terms of reference.

5.  Key management - let's be realistic.  I suggest the "minimalist" (KISS)
    approach to start: manual keying via SNMP (: duck :) with a nice little
    MIB.  Next should come a peer-peer exchange in the layer ("Key Exchange 
    Control Protocol"), something akin to what Phil Karn (others before him) 
    have suggested, but as lightweight as possible.
   
    Later on (much later) should come the all-singing-all-dancing-802.10-KMAE-
    X9.17-compatible-Holy-Grail ultimate one-size-fits-all key exchange 
    application, if ever.

6.  Finally, is it integrated in IP or a sublayer?  In other words, is this
    limited to "externally observable" interworking issues or are you going
    to delve into end-system interface issues?  This starts to get into the
    "assurance" question...

The schedule looks ok for an encapsulating frame, no replay integrity hacks,
SP3-D-based protocol with MIB keying, end-system-to-end-system, no assurance,
no access control or authentication beyond "yup, key works!".

I think the schedule is a bit optimistic for resolution on gateway-to-gateway 
or key management layer debates, but why not try?

-- Joe
References: