[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
My summary from the VPN Interoperability Workshop in San Diego

To: ipsec@lists.tislabs.com
Subject: My summary from the VPN Interoperability Workshop in San Diego
From: Tero Kivinen <kivinen@ssh.fi>
Date: Wed, 27 Sep 2000 05:18:04 +0300 (EET DST)
Organization: SSH Communications Security Oy
Sender: owner-ipsec@lists.tislabs.com
Summary
=======

Misc
----

	About 90% of those I asked had found out bug(s) in their own
	code.

	About 90% of those having bugs fixed them here...

	100% of those I asked said this was useful.

	100% of those I asked said they will come to the next meeting
	WHEN there is going to be one.


IKE problems
------------

	- Bundles and protection suites
	- SA bundles and multiple SAs
	- IP+AH+IP+ESP+IP+packet or IP+AH+ESP+IP+packet
	- Rekeying problems. Both in phase 1 and 2.
	- Nat traversal, not enough time to address it because this was
	  so soon after ietf.
	- Agreeing on PFS (no negotiation there)
	- Using DOI 0.
	- Vendors requiring payloads being in specific order.
	- Vendors not able to handle long proposal lists.
	- Signature authentication.
	- Starting proposal numbers from zero.


Document issues
---------------

	- What identity types are allowed in phase 1 and 2.
	- Give example of RSA signature exchange.
	- Add more examples how to behave in the different situations.
	- Dynamic address box solution is missing for subnet vpn.


Commit bit
----------

	- Commit bit issues, it is not very clear.
	- What spi we use in the SPI field in the connected
	  notification if we are negotiation AH+ESP etc.


Supporting things
-----------------

	- Vendors not doing group 1.
	- Vendors not doing DES.
	- Vendors not supporting aggressive mode
	- Vendors not supporting FQDN as identity for phase 1.
	- Vendors not supporting tunnel mode.


Notifications
-------------

	- SPI inside the initial contact notification
	- Does the initial contact must be encrypted.
	- Vendors not implementing notification payloads.
	- Some vendors do not support main mode and they dont send
	  proper notification (invalid exchange type), but they send
	  some other error message.
	- Delete payload problems, can we send delete payloads
	  in all packets?
	- Does the delete for phase 1 SA need the protection from the
	  phase 1 SA
	- Clarify what SPI to send in the Delete payload.


Certificates
------------

	- Multiple certificate formats
	- Vendors require ip-address in certificates
	- Vendors not putting ip-address in certificates
	- How to bind certificate and ID together
	- UTF 8 encoding in certificates
	- Vendors not able to handle several certificate requests
	- Vendors requiring certificates to be on specific order.
	- Vendors not able to handle certificates having multiple
	  subject alt names


Son of the IKE
--------------

	- Vendors implementing parts of the son of the IKE draft, but
	  it is expired. For example SPI size. New notifications,
	  using old exchange number.
	- What is the status of this.


Lifetime
--------

	- Lifetime problems (configuring them)
	- Lifetime what are the defaults, we need defaults
	- When we use defaults. Only if no lifetime attributes, or
	  only when one of them is missing. 
	- Phase 1 SA lifetimes in kilobytes.
	- Using variable length encoding for kilobyte lifetimes. 


IPComp
------

	- The IKE does not work well with only ipcomp and with well
	  known cpis
	- CPI size (2 or 4).
	- IPComp problems.
----------------------------------------------------------------------

Comments about the plans to combine ISAKMP+IKE+IPSEC DOI to one document:
----------------------------------------------------------------------
Q: 7) If we are going to do that are we allowed to change the bits in the
      wire?
A: 9 yes
----------------------------------------------------------------------
Q: 8) What would you like to REMOVE from the IKE during that?

A: - Too much options, Agressive mode, New group
   - Remove the original RSA encryption mode
   - PFS, Dangling SAs, Commit bit, Aggressive mode replaced with base
     mode, quick mode 3 or 4 packets, Change to cookies to just message
     ids, removing differencens in the SKEYID generation for different modes.
   - Only one RSA mode, propably revised
   - Negotiating PRF, add phase 1 responder lifetime
   - Reduce number of algorithms
   - Email address, remove extra identities

   (In this question I just wanted to know what people would like to remove,
    they didn't see the list below when answering to this, the answers in
    this item are also counted in the cases below)
----------------------------------------------------------------------
Q: 8a) Do we need two different public key encryption
       authentication method. If not which one we should remove?

A: 6 only one (3 dont care which one), 2 keep both
----------------------------------------------------------------------
Q: 8b) Do we need both aggressive and main mode? Which one?

A: 1 remove aggressive, 3 replace aggr with base, 3 keep both
----------------------------------------------------------------------
Q: 8c) How about new group mode?

A: 3 remove, 1 keep
----------------------------------------------------------------------
Q: 8d) How about private groups in the phase 1?

A: 2 remove, 2 keep
----------------------------------------------------------------------
Q: 8e) Do we need both RSA and DSS signature authentication
       modes? Which one?

A: 3 remove DSS, 2 keep both
----------------------------------------------------------------------
Q: 8g) Can we remove the whole DOI field?

A: 2 remove, 4 keep it
----------------------------------------------------------------------
Q: 8h) Can we remove the situation stuff?

A: 4 remove, 2 remove or just ignore it always
----------------------------------------------------------------------
Q: 8i) Negotiation multiple SAs over one Quick mode?

A: 3 remove, 3 keep
----------------------------------------------------------------------
Q: 9) Do we want to fix the authentication hash at the same time (revised
   authentication hash)?

A: 6 yes, 1 only minimal changes
----------------------------------------------------------------------

IPsec questions:
----------------------------------------------------------------------
Q: 12) Is there anything in the IPsec that you would like to be removed?

A: - AH, DES, Manual keying to be optional and mostly for testing
   - AH, Transport mode, DES
   - AH, Manual Keying to be SHOULD
   - Transport mode, or tunnel mode and use GRE
   - AH
   - Remove ESP authentication, keep AH
   - AH
   (This is again their answers without showing the list below).
----------------------------------------------------------------------
Q: 12a) AH

A: 7 remove AH, 2 keep it
----------------------------------------------------------------------
Q: 12b) Manual keying

A: 6 Manual key to optional, 1 keep it
----------------------------------------------------------------------
Q: 13) Do you plan to implement IPv6 IPsec also? Do we need possibility to
    test that too?

A: 13 plan to implement IPv6, 2 no, 1 do not know
-- 
kivinen@ssh.fi                               Work : +358 303 9870
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
Prev by Date: RE: CERT_REQ_PAYLOAD usage
Next by Date: RE: CERT_REQ_PAYLOAD usage
Prev by thread: RE: CERT_REQ_PAYLOAD usage
Next by thread: ICMP "Destination unreachable" - should it be sent?
Index(es):
- Main
- Thread