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

The world according to MCR


Monday March 15, 1999
1300-1500 Salon EF

1. Agenda Bashing
	Tso's and Moskowitz

2. Document Administrivia
	Tso's and Moskowitz
	One more transform: RIPEM-MD for authentication. In last call.
	RFC1825-1827 were obsoleted by new drafts.
	RFC1828/1829 (AH/ESP transform) were not obsoleted as well as RFC1851 (3DES)
	will be moved to historic:
		1. sequential counter for the IV
		2. stated objected to make old trnasforms to go away. 
		3. ... what was the third reason??

	Go to draft standard from proposed standard. To get to there we need to
	have a MIB. This is the last critical item before proposed standard.

	Hugo: Do we want to go ahead with the DH-free authentication system for
	IKE? Draft is nearly expired, and has not received any comments. Question of
	proceedure: within IPsec vs start new group. Is there even any
	interest in implementing this?   (Some silence from the room)

	What about the rekeying issue? Maybe we could have a BCP as
	well as a change document?

	Tim Jenkins

	An architecture only for the MIB. No point in arguing about
	what goes into the MIB until we know what it looks like.

	Monitoring only of IKE and IPsec
	 seperate branches in MIB tree:	ISAKMP DOI-independant, IKE,IPsec
	 intended to provide a base for application specific users for phaseI/II.
		(tunnel concepts, and other stuff will be built upon this)
	entity stats, six IPsec phase 2 SA tables.
		inbound x outbound x ESP x AH x IPCOMP
	DOI-independant notify table.

	protection suite: pulls together individual IPsec phase 2 SAs
		to reflect how they were negotiated using IKE.

	SEE TABLE (Tim, please provide!)

	Eleven things are required to make the protection suite table unique.
	This is far too cumbersome to use as an index. Typically have
	a 1-1 mapping between ISAKMP SA/IKE SA, but that is not the
	general case.
	If the IKE SA expire before the protection suite? Should never

	What about if I do an identity PFS? That would be an exception.

	RA: envision a world where I use ISAKMP/IKE SAs but not IPsec.
	People who are not implementing IPsec, but are using ISAKMP.

	Tim: You mean Protection Suite Table should be seperate from IKE?
	RA: IKE and IPsec should be seperate.
	RA: not objecting to Protection Suite Table, but I want them
	quite decoupled. 
	Tim: we need to the split as high as possible, and I've not
	yet decided how high it needs to be. It sounds like you want them
	done at the highest level.

	Q: is basic arch. correct?
	Q: where should branches split? Different documents? different
	tables in same MIB?
	Q: provide multiple tables to make it easier to hide more sensitive
	Q: IPv4 and IPv6 addressing. Currently propose duplicating
	addresses where needed.
	Q: indexing of protocol suite table

	Straw poll:

	RA: fundamental problem is that I want to use ISAKMP for
	things other than IPsec.

4. Deprecating 1DES
	J. Gilmore... presented by Hugh Daniels.

	How many want to use DES? Noone.

	A problem is that we take 5 years to trust an algorithm, yet
	we need to distrust something within 5 minutes.

	What if in 5 years, something takes Blowfish (e.g.) out, we
	need to know how to switch things.

	A second problem is that DES is used for more than just bulk encryption.
	It is also used for IKE.

	speaker: I'd like to use DES in some situations where it has
	commercial value.

	Proceedure issue: it is a must implement for 1DES. 
	Proposal is that "MUST implement" gets changed from 1DES to
	X. 1DES because MAY implement. 

	Hugh: It is a MUST NOT. 

	Roy: I understand that DES is crackable, but we use it in the
	real world.

	Dan: DES is crappy. But that isn't the issue. Our new default algorithm
	should be FOO. I'd like some alternatives.

	SMB: Two alternatives are 3DES and DESX. 
	SMB: Not suggesting that it be changed to MUST NOT. The
	question is what is your threat model. It is good against joy hackers.
	Matt Blaze: One problem with existing IPsec is that there are
	too many algorithms to chose from. At low layer, one has to
	provide services of some kind in a black box way. If you have weak
	pieces it invites protocol interactions where you get faults.
	Have 3DES be MUST, 

	Charlie Koffman: Impassioned plea at Danvers for mandating DES. Logic was
	political. At the time DES export was illegal, and we could
	push them over the edge and make DES export legal. Now, we
	need to mandate 3DES for the same reason.

	JI: Moore's law. Computers are twice as fast as a year
	ago. 3DES is half the speed, so we aren't any worse. 
	And who is killing your friends with DES?

	Hugh: My software is being used by human rights groups... and
	yes lives are at stack.

	Mike: we should have backwards compatibility. Distinction
	between MUST implement and MUST use as default.

	RA: fundamentally, if we split the default from MUST be
	implemented. retain 1DES as must implement. 

	Straw poll: 3DES MUST IMPLEMENT. Many yeahs, some objections
		DESX MANDATORY: not many.
		Remove DES from MANDANTORY: some
		Keep DES in the MANDANTORY: more

5. IKE SA's w/non-fixed IP address
	Yael Dayan

	Aggressive mode with preshared key.

	A user with a non-constant IP address, then we must use
	Aggressive mode. 

	The problem is that the responding (the gateway) must do DH operations
	before it really knows if the user is legit.

	Proposal for a New Phase I Exchange.
	[MCR's comment: Vendor ID payloads can be used in Aggressive
	mode to enable a new feature]a

6. IPSEC Interactions with ECN
	Sally Floyd

	Explicit Congestion Notification.... rfc2481.
	Redefines two bits in the IP header.
	ECN Capable transport bit. Set by the end node.
	Congestion Experienced bit. 
		Set by the router instead of dropping the packet.
	If set, causes the receiver to act as if the packet was dropped.

	Inner header gets copied to outer header. Congestion
	Experienced gets set, then it gets decapsulating, throughing out the
	Congestion Experienced bit.		

	Two options:
	- limited functionality option. Outer header shouldn't have
		the ECN Capable set. Don't copy the ECN bit.
		No added security vulnerabilities.

	- full functionality option: Outer header in IPsec tunnel can
		be marked as ECN capable. If congestion is
		encountered, packet can be marked instead of dropped.
		That bit gets copied to the inner header on decapsulation.
		Security implication. Dropping of a packet is not reverseable.
		But, the Congestion Experienced bit can be reset. So
		the indication of Congestion is inaccurate, causing
		impacts on any other competing flows.

	1. Add new field to SAD.
	2. Change IPsec tunnel header processing for the ECN field.
	3. add the optional ability for IPsec tunnels to negotiate the
	use of ECN.

	Kent: it is premature to make a change at this stage to
		accomodate an experimental protocol.

	Charlie: why not have a second experimental draft on IPsec.
	Sally: ECN is incrementally deployable.

	Bob: the reason why ECN is experimental is because it is using
		a very valuable quantity: those two bits in the TOS
		field. It experimental because we just don't know if
		the gain will be worth the two bits.

	speaker: we could seperate the three proposals.

	JI: what happens if to the world if you just leave things as
		they are? Are we worse off than if you didn't have

	Sally: it causes congestion control to be turned off in the
		end-node, which causes congestion collapse, which is
		pretty serious.

	JI: I'm not convinced that there will be sufficient interaction
		between IPsec and ECN in the next two years to get any
		real data?	

	Ted: if we mandate clearing the bit and the ECN fails, then we
		have a problem when the IESG reassigns the bit.

	Kent: If we do anything, then we should do all three points.

7. Other Open Work Items
	Tso's and Moskowitz

	Error codes.
	Ted: error codes should be vaguely consistent to allow

	Certain fields in the IKE were not protected.
	Ted: no clear problem, but might be worisome.
	MCR: what do the version numbers mean?
	Ted: major/minor numbers? When do we change them? major for
		incompat change, minor for compatible change.

	Bob: Tim Jenkins' rekeying BCP.

	PKIX/PKI requirements stuff: Rodney and WG chairs will determine 
	what forum will do the work.

	Murash?: what about ICMP errors? 
	SMB: ...
	MCR speaks, and all record is lost in the confusion.

	Ted: i hear call for volunteers.

IPsec workshop
	Fess Parker's DoubleTree Resort Santa Barbara, CA
	Asked for Ericsson VPN Interoperability Workship rate
	May 23-28, 1999.

VPN Consortium (www.vpnc.org)
	- Has a page of all known active drafts. 
	- which are still serious? Which have been abandoned by
	everyone but the author? 
	Could all authors' consult with Paul Hoffman about their

IPSRA mailing list:
	ietf-ipsra@vpnc.org... subscribe via ietf-ipsra-request@vpnc.org	

Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface