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

No Subject

[192.94.214.100])
	by portal.ex.tis.com (8.9.1/8.9.1) with ESMTP id RAA10907
	for <ipsec@ex.tis.com>; Wed, 4 Nov 1998 17:46:26 -0500 (EST)
(4.1)
	id xma003607; Wed, 4 Nov 98 12:56:27 -0500
From: Charles Kunzinger <kunzinge@us.ibm.com>
To: <ipsec@tis.com>
Subject: Issues raised at VPN Interoperability Workshop
Message-ID: <5040300022235103000002L032*@MHS>
Date: Wed, 4 Nov 1998 16:50:41 -0500
MIME-Version: 1.0
Content-Type: text/plain
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk

This note supplements Roy Periera's earlier posting, listing those issues
 which I collected on my summary foils during last week's interoperability
workshop:

1. Is it mandatory to check the contents of the ID payload against the
subjAltName
in the associated certificate?  Is their a mandatory action on mismatch?
 The Domain of Interpretation, section 4.6.2.1, states that "When an IKE
 exchange is authenticated using certificates..., any IDs used for
input
 to local policy decisions SHOULD be contained in the certificate used
in
 the authentication of the exchange."  I didn't see any text saying what
to
 do if there's a mismatch.

2. Is there a recommended way to deleta an SA and establish a new one without
losing traffic?
 Suggestion  from the floor was to use "draft-jenkins-ipsec-rekeying-00.txt"
 as a starting point and then discuss on the list.

3. Is the action for NOTIFICATION-inital contact defined?
 See section 4.6.3.3 of "Domain of Interpretation" for details.

4. What action shold be taken if "Vendor ID Payload" is received by a system
that does not use it?
 Consensus was you can ignore it if you wish, but you can not allow your
 system to crash when it's received.

5. Are there limits on sizes of nonces used in IKE?
 Nonces must be between 8 and 256 bytes in length as noted in "IKE"
spec,
 section 5.

6. Can Vendor ID Payload be carried in Phase 2 IKE exchanges?
   If used, it MUST be present in Phase 1 flows; it's also not an error
to
 include it elsewhere in addition.

7. What are details for handling "opitons"?
 This is too general a question.  Any specific issues should be raised
for
 discussion  on the mailing list.

8. Is the use of IKE by IPPCP defined?
 See the relevant IPPCP drafts.

9. Many venodrs use different GUIs for configuration.  Will there be any attempt
by the working group to develop a common approach?
 No, GUIs are an implementation option that vendors will use to differentiate
 their products.  However, the working group will develop a common LDAP
 Schema for configuring and administering VPNs.  See
  "draft-ietf-ipsec-policy-schema-00.txt", and discuss as needed
on the mailing list.

10. Miscellaneous Lifetime/lifesize issues:
 New text to cover handling during Phase 1 is being developed.  Once
avaailable,
 we can discuss on the mailing list.

 Also, "Domain of Interpretation" document, section 5.4, discusses
 lifetime/lifesize, but text does not mention default values.

 If a system receives a lifesize and lifetime attribute but supports
only
 one of them, the text in +Domain of Interpetation", section 5.4,
indicates that
 " ...if an implementation receives a defined IPSec DOI
attribute...which it
 does not support, an ATTRIBUTES-NOT-SUPPORT SHOULD be sent and the
security
 association setup MUST be aborted, unless the attribute is in the
reserved
 range.

11.  If L2TP and IPSec are used in conjuc=nction, and there is no ID payload in
the
IKE Phase 2 exchanges, should the default be to a)apply IPSec protection to all
IP
packets, b) apply IPSec protection only to packets going through the L2TP
tunnel,
or c) reject the SA proposal?
 Consensus appeared to be that only the "tunneled" traffic should get
IPSec
 protection.

12. If "Next Payload" points to a private payload, should this payload be
ignored
in the absence of a Vendor ID Payload?
 Consensus was to discuss this on the mailing list.

13. For Phase 1 ID payloads, is it OK to not check that protocol/port have been
set
to 0/0 or UDP/500?
 This issue has been raised on the mailing list, but has not gotten any
response
 as yet.  Discuss as needed on the list.



`


____________________________
Charles A Kunzinger (kunzinge@us.ibm.com)
TCP/IP Technology Management, JDGA/501, RTP
Phone: Tie 8-444-4142 ,  External 1-919-254-4142
Fax: Tie 8-444-6243,  External 1-919-254-6243
VM:  IBMUSM27(KUNZINGE)
Follow-Ups: