[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The world according to MCR
-----BEGIN PGP SIGNED MESSAGE-----
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?
3. IPSEC MIB
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
happen.
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
information?
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.
DeepCrack.
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.
Proposal:
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
ECN?
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
communication.
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
status.
IPSRA mailing list:
ietf-ipsra@vpnc.org... subscribe via ietf-ipsra-request@vpnc.org
http://www.vpnc.org/ietf-ipsra/
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQBVAwUBNu1wfx4XQavxnHg9AQEM7QH+LKnNTcnTPP8MK0Y7HTS4hqVZB0AlVemv
b/NlQmkqyedTa0w60CbHKLKPZdxHn+kVIrLE7V20bZRw79kgQrJC+w==
=ZY2w
-----END PGP SIGNATURE-----
Follow-Ups: