1Appendix:
2
3It's summary report of IPsec Interoperability Workshop Aug 31st- Sept 3 1998.
4To be consider each following items.. ;-(
5
6Location: Microsoft Campus, Redmond WA
7Attending: 60 people, 19 companies.
8		Axent/Raptor, Cisco IOS, Checkpoint, Intel, HiFn, Interlink,
9IRE, Microsoft NT5, Netscreen, Redcreek, SSH, Timestep, Worldcom/ANS, IRE,
10Free SWAN
11		Verisign, Entrust, Worldcom Advanced Networks - James
12Matheke, Digital Signature Trust Company, Microsoft PKI & Directory reps
13		L2TP/IPsec: Microsoft NT5 and Cisco IOS
14
15Handouts:
16(I will get these on a public web site ASAP.  Stay tuned for pointer)
17
18Network Configuration Tear Sheet - network topology explanation & diagram
19Testing Matrix: had 43 options * (transport + tunnel) * (initial + rekey) =
20172 tests.
21Rodney Thayer's draft IPsec certificate profile
22IPsec Rekeying Issues powerpoint slides, by Tim Jenkins of Timestep
23Working copy of Draft-ietf-ipsec-ldap-schema.txt
24Powerpoint slides presented at IETF Policy BOF explaining
25draft-ietf-ipsec-ldap-schema.txt
26Microsoft Directory Enabled Networking Powerpoint slides by Steve Judd
27Microsoft Public Key Infrastructure Powerpoint slides by Rick Johnson
28Windows NT5.0 Beta2 walkthrough guide for creating IPsec policy
29
30
31Debriefing Survey
32=================
33On Wed and Thursday, I surveyed 8 companies with the following questions,
34saying that I would compile a list of responses without indicating vendors
35and post the compiled report to the IETF IPsec mailing list.  Here are the
36results.  I have attempted to reduce duplication by indicating in
37parentheses how many of the respondants indicated a similar response, eg (4)
38means 4 out of 8 vendors.  There is no priority or ordering on these
39listings, other than popular reponses appear first.
40
41What did you fix?
42===========================================================
43Policy mgmt bugs. Modification on end-to-end policy configuration (3)
44Fragmentation on large packet (2)
45Vendor id payload support
463DES key generation
47Multiple MM proposals are not draft compliant
48Initial contact handling
49Additional padding that expands payload in IKE MM
50Construction of id payload of type ID FQDN and ID USER NAME during RSA
51Signatures
52Fixed the parsing of pulling out the SubjectAltName out of the cert.
53Problems handling multiple proposals
54Problems handling the payload when 2 lifetypes were being sent, for example
55seconds and bytes.
56Better understanding of what is in main mode
57Circular cert chain signature handling
58Draft change to support initial contact
59Make sure that if peer sends back invalid ids, that they do not overwrite
60the initiators ids 
61Ignore empty cert request payload
62Wrong checksum in inner payload header.  Other implementations were not
63checking
64Empty payload of cert caused AV
65Cert signed circular chain handling
66ISAKMP config mode- hashing incorrectly
67RSA encryption mode- not encrypting all that we should
68AH + ESP negotiated for tunnel mode
69Nothing
70If we didn't receive proxy IDs during QM when negotiating transport mode, we
71would fail. Most vendors don't send these. IOS and NT do this to support
72protocol and port based filters. We need to add a test case to do this
73regularly.
74If we did not receive the encapsulation attribute, we would send it back. 
75Wrongly padding  the Oakley header length to 4 byte boundaries
76Bug found in test tools
77Where and HOW to encode v3 extensions in PKCS10 requests.  Mostly due to how
78old BCERT toolkits used to do it which is not what RSA actually spec'd.
79
80What did you not fix - what still needs to be worked on?
81=========================================================
82PKI usage: Cert subject altname comparison with MM id payload, Certificate
83chain processing, CRL support, Cross-certification, DN in certs, Every (CA?)
84vendor had different cert request format (5)
85Using DSS/DSA - only supported by HiFn, CA vendors MS & Entrust & GTE (2)
86Fragmented TCP packets failing auth checks
87Need to send deletes for all of the SPIs when doing an AND proposal
88Initiating SAs
89Commit bit handling
90Rekey issues: Initiator switching to responder because original responder
91hit lifetime timeout first and visa-versa.
92Responder changing attributes in transform.
93The PKCS10 requests with v3 extensions.  Currently MS puts then in a
94proprietary attribute (said they would change), the 'standard' attribute to
95put them in is the rsaExtensionsAttribute, however RSA BCERT and TIPEM
96toolkits add an extra level of encoding and encode the sequence of extension
97as a T61String which is NOT the documented format.  The cure is to have CA
98vendors try to decode from both and have all new clients only do
99rsaExtensionsAttribute as Seq of Ext.
100
101What are the open IPsec design issues?
102========================================================
103PKI usage, cert formats, CA enrollment, deployment model for cert-based
104trust, supporting CRLs, supporting cert request payload (5)
105Peer Recovery, stale/Inactive SAs which linger when peer has lost state.
106Orphaned phase2 SA. This can be due to a missed delete (since deletes are
107not reliable) or a system crash of a peer (4)
108ISAKMP header not authenticated. Initial contact & all notifications are not
109authenticated (4)
110Commit bit. Since it is unauthenticated if it is present in the IKE header.
111Is it still a MUST? (2)
112Version#s not authenticated in IKE header
113Common policy configuration & distribution for multiple vendor devices that
114a single manager can use.
115Mobile clients - preshared key per user?  Lose identity protection with
116aggressive mode
117Rekey mechanism that doesn't lose traffic by design
118When tunneling traffic, do you reassemble packet first, then filter, then
119forward to tunnel?
120Configuration problems, ISAKMP config needs further work
121Support in drafts for authentication method per selector conflicts with
122using MM with QM.  Applications can't use their own trust system for their
123traffic - must be manually configured out-of-band between machines (IP
124addresses).  This is why MM with QM protection is abandoned by vendors in
125favor of aggressive mode, so that QM parameters, and also identities, can be
126known first to succeed with authentication.
127Race conditions when have multiple SAs to same box from one source, rekeying
128MM over multiple QM
129Multiple QM proposals
130How to get tunnels set up
131Mismatch filters in policy.  When initiator should propose both the full
132filter breadth, as well as the specific packet protocol type/ports to the
133responder, so the responder can pick the widest clean match.
134Need some kind of model for using SNMP MIB for reporting and management of
135IPsec enabled devices.
136Think IKE is open to denial of service attack because anyone can provoke DH
137computation in MM. Should only create state when get cookie back to reduce
138denial of service.
139IKE over non-IP
140Disagreement on how AH with ESP in transport or tunnel mode should be
141expressed in policy, negotiated, or have their separate SAs managed
142Need full client-side configuration to support simultaneous tunnels from one
143client to different gateways
144Need "Credential Request Payload" more general than just certificate request
145payload, to support retry for authentication when both systems participate
146in multiple trust models.
147
148What are the open IPsec interop issues? If products shipped today, what
149problems would customers encounter with multiple IPsec products?
150================================================================
151Policy expression, configuration for interop (5)
152Peer recovery of SAs, with mobile users, between two gateways (2)
153US export IPsec interop- no support at all in drafts for what products have
154to implement for ESP. Custom DH group for export not supported in drafts (2)
155Understanding why proposals failed- Error messages to detail why proposal
156not chosen (Michael Richardson going to collect error codes & messages from
157vendors)
158Multiple proposals for export not supported
159Policy distribution
160Client interop because clients haven't been tested much, mostly GW/FW
161Real world application usage/admin, where systems are taken up/down, address
162changes, etc.
163Biggest challenge is to cover all aspects/combinations
164Hard to balance tolerance of variance among IPsec implementations which is
165necessary for interop with strictness of checks to fulfill security and
166draft requirements.
167Scalability
168Some/many vendors not installing SA parameters which were negotiated, using
169what filter policy specified.
170Cert encoding for CRP, most people understand X.509
171Key usage flags in cert, what you expect to get back for generic or specific
172for data encryperment. Maybe define another type of cert field encoding,
173have 1-9, need 10.
174How to process Subject Altname
175Nobody else is doing encrypted nonces
176Enforcing check that traffic sent through IPsec format matches filter which
177was negotiated.  This must be agreed upon by other vendors.  Not covering
178this in bakeoff testing because people mostly ping and ftp test, not
179multi-protocol  or multi-port through same SA.
180Having certificate storage and key signing operations on smartcards, where
181they don't provide a signature without the OID
182What was good about the bakeoff?
183=========================================================
184Small size, good working time (4)
185Organized well (2)
186Providing PCs, cables (2)
187Beer (2)
188Having a preplanned test matrix
189Having several CA vendors, ability to discuss and try CRLs, different certs
190Plenty of space, good friendly atmosphere. Microsoft people being very
191helpful
192Timing was good
193The network was setup when we got there.
194More than one network allocated for each vendor to allow gateway testing
195
196What wasn't so good about bakeoff?
197========================================================
198Had to reconfigure because test net was not on Internet which for many
199caused a reboot. Only really need 4-5 class C addresses with preplanned
200private net space.  Should have DHCP on external net.  NAT from private to
201public wouldn't work using IPsec, of course, because using IPsec to get back
202home to company net. (3)
203Power failure Monday morning (2)
204Internet access via ISDN 128Kb was very slow (2)
205Didn't seem that anyone could cover the test matrix with another vendor even
20650%.
207Everyone still ping testing, not real traffic, limited ftp transfers for
208those who tried rekeying
209No T-shirts
210Clients were not really tested, mostly vendor's gateway/Firewall products.
211Not testing CRLs, not testing cert expirations
212Hard to understand why two systems would not interoperate
213Need phones at each station
214Network addressing plan was hard to read and understand what is needed.
215Need picture of topology.
216Impossible to design comprehensive test matrix, don't have time in a bakeoff
217to test all of these
218No time to get into real situation test
219Test matrix too confusing.  Rather see list of topologies with spec of "to
220reach my network do this MM proposal and these different policies for telnet
221and http"
222
223For next bakeoff at IBM, what should be done?
224========================================================
225Test rekey in each direction under stress (4).  Use FTP for this.
226Huge payload to test fragmentation & reassembly in IPsec ESP, AH under load
227(2)
228Seat vendors together who more advanced in their IPSEC/IKE implementations.
229Otherwise it will be n-X-n testing matrix which is impossible with 60
230vendors present.
231Post test matrix to the IPsec list before the event to get comments on it's
232completeness
233Make sure real world topology is tested: static IP client -> GW -- internal
234net -- servers on PCs
235ICSA should say more about rekeying issues, or allow vendors out of their
236NDA signed during certification testing to discuss rekeying issues
237Not relying on non-mandatory messages
238Peer recovery testing
239Negotiating and maintaining many SAs
240Need next NT5.0 post-beta2 release to test with
241Need denial of service and IPsec knowlegable attack tests
242Need a complete implementation of all IPsec capabilities to test against,
243Need an attacker box to test against
244All CA vendors should support Subject Altname
245Need telephone at desk
246Need vendors capabilities listed and what they want to test in advance
247Test nested tunnels
248Test transport over tunnel mode
249Test random IP addresses to simulate mobility
250Have bakeoff at the same place where you stay, in hotel
251Attack testing
252
253End of Report
254
255
256