From owner-ipsec@lists.tislabs.com Wed Apr 2 05:40:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32DeQJM003144; Wed, 2 Apr 2003 05:40:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04890 Wed, 2 Apr 2003 07:45:37 -0500 (EST) Message-Id: <200304021128.GAA04126@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-06.txt Date: Wed, 02 Apr 2003 06:28:10 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-06.txt Pages : 93 Date : 2003-4-1 This document describes version 2 of the IKE (Internet Key Exchange) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations. This version of IKE simplifies the design by removing options that were rarely used and simplifying the encoding. This version of the IKE specification combines the contents of what were previously separate documents, including ISAKMP (RFC 2408), IKE (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy authentication, and remote address acquisition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-1154437.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-1154437.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Apr 3 06:31:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33EVEJM017639; Thu, 3 Apr 2003 06:31:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08691 Thu, 3 Apr 2003 08:43:03 -0500 (EST) Message-Id: <200304031136.GAA14551@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-flowmon-mib-tc-00.txt Date: Thu, 03 Apr 2003 06:36:37 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPsec Flow Monitoring MIB Textual Conventions Author(s) : C. Madson et al. Filename : draft-ietf-ipsec-flowmon-mib-tc-00.txt Pages : 0 Date : 2003-4-2 This document describes the SMI textual coventions required to support the definition of IPsec MIBs. It is necessary to separate the definition of the textual conventions into a separate document due to their dependence on IANA assigned numbers for transforms and Diffie-Hellman groups supported by IPsec protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-flowmon-mib-tc-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-flowmon-mib-tc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-flowmon-mib-tc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-2123610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-flowmon-mib-tc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-flowmon-mib-tc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-2123610.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Apr 3 06:52:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33Eq6JM018249; Thu, 3 Apr 2003 06:52:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08899 Thu, 3 Apr 2003 09:21:18 -0500 (EST) Date: Thu, 3 Apr 2003 17:01:18 +0300 (EEST) Message-Id: <200304031401.h33E1Ig04999@tero.kivinen.iki.fi> X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: DHCP over IKE draft 3/3 Organization: Helsinki University of Technology Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-Edit-Time: 0 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IP Security Protocol Working Group (IPSEC) T. Kivinen INTERNET-DRAFT 2 April 2003 draft-ietf-ipsec-dhcp-over-ike-radius-00.txt Expires: 2 October 2003 Using RADIUS backend for DHCP over IKE Status of This Memo This document is a submission to the IETF IP Security Protocol (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@lists.tislabs.com) or to the editor. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes method of using Remote Authentication Dial In User Service (RADIUS) as a backend for the internet key exchange (IKE) version 2 host configuration protocol. T. Kivinen [page 1] INTERNET-DRAFT 2 April 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Using RADIUS backend . . . . . . . . . . . . . . . . . . . . . . 2 3. Mapping of DHCP options to RADIUS request attributes . . . . . . 2 4. Mapping of RADIUS attributes to DHCP options . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 7. Normative References . . . . . . . . . . . . . . . . . . . . . . 3 8. Non-Normative References . . . . . . . . . . . . . . . . . . . . 4 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction The IKEv2 [IKEV2] offers way to put DHCP [RFC2131] packets inside the IKE packet exchange to do the host configuration for the remote access clients. This protocol describes how to use existing RADIUS [RFC2865] server to get the configuration data needed for the IKEv2 host configuration protocol. 2. Using RADIUS backend The security gateway using the RADIUS as backend for the configuration, is acting as a protocol converted between DHCP and RADIUS. This can also be seen as if there is minimalistic DHCP server in the security gateway, and that DHCP server is then using the RADIUS server to get the actual IP address. This DCHP server is then also responsible to remembering the configuration given to client, in case client decides to request it again later (i.e when client does RENEW or REBIND). If the client sent DHCP(DISCOVER) to the security gateway, then the security gateway MUST send the DHCP(OFFER) back with the configuration parameters found from the RADIUS attributes. The client will then reply to that with DHCP(REQUEST). The security gateway MUST then check that the paremeters are valid compared to the configuration parameters received earlier from the RADIUS and if so sent back DHCP(ACK). Note that security gateway MUST NOT leave out the DHCP(OFFER) packet, i.e it MUST NOT reply to DHCP(DISCOVER) with DHCP(ACK) even when there would not be anything for the client to do with DHCP(OFFER). This would be against the DHCP protocol. The client may also start directly with DHCP(REQUEST), in which case security security gateway simply verifies that the parameters are valid (if there are no parameters inside then they are valid, and server can reply back immediately with full set of parameters) and replies with DHCP(ACK) with final configuration parameters. If the DHCP(REQUEST) parameters are not valid, the security gateway MUST reply with DHCP(NAK) which will cause the client to start again with DHCP(DISCOVER) payload. 3. Mapping of DHCP options to RADIUS request attributes T. Kivinen [page 2] INTERNET-DRAFT 2 April 2003 The mapping of the DHCP options in the DHCPDISCOVER or DHCPREQUST payload to the RADIUS attributes is following: DHCP option RADIUS attribute ----------- ---------------- Requested IP address (50) Framed-IP-Address (8) Subnet Mask (1) Framed-IP-Netmask (9) Domain Name Server (6) VendorID [ID#], VSA [#] Hostname (12) VendorID [ID#], VSA [#] NetBIOS Name Servers (44) VendorID [ID#], VSA [#] IP Address Lease Time (51) Session-Timeout (27) or VendorID [ID#], VSA [#] The RADIUS server may also support other DHCP options by using vendor specific attributes. 4. Mapping of RADIUS attributes to DHCP options The mapping of the RADIUS attributes to DHCP options in the DHCPOFFER or DHCPACK payload is following: RADIUS attribute DHCP field ----------- ---------------- Framed-IP-Address (8) yiaddr Framed-IP-Netmask (9) Subnet Mask Option (1) VendorID [ID#], VSA [#] Domain Name Server Option (6) VendorID [ID#], VSA [#] Hostname Option (12) VendorID [ID#], VSA [#] NetBIOS Name Servers Option (44) Session-Timeout (27) or IP Address Lease Time (51) VendorID [ID#], VSA [#] The RADIUS server may also support other DHCP options by using vendor specific attributes. The actual values for the Vendor ID and VSA (vendor specific attribute) depends on the RADIUS server vendor. 5. Security Considerations The connection between security gateway and RADIUS server migth be vulnerable to different kind of attacks, and that connection should be protected using IPsec or some other means. 6. IANA Considerations This document does not have any actions for IANA. 7. Normative References [IKEV2] Kaufman C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf- ipsec-ikev2-05.txt, February 2003 T. Kivinen [page 3] INTERNET-DRAFT 2 April 2003 [RFC2131] Droms R., "Dynamic Host Configuration Protocol", March 1997 [RFC2865] Rigney, C., S. Willens, A. Rubens, and Simpson W., "Remote Authentication Dial In User Service (RADIUS)", June 2000. 8. Non-Normative References 9. Authors' Addresses Tero Kivinen SSH Communications Security Corp Fredrikinkatu 42 FIN-00100 HELSINKI Finland E-mail: kivinen@ssh.fi T. Kivinen [page 4] -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Apr 3 06:55:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33EtKJM018329; Thu, 3 Apr 2003 06:55:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08893 Thu, 3 Apr 2003 09:20:17 -0500 (EST) X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16012.15978.73686.651145@tero.kivinen.iki.fi> Date: Thu, 3 Apr 2003 17:00:10 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: DHCP over IKE draft 1/3 X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: Helsinki University of Technology X-Edit-Time: 8 min X-Total-Time: 9 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here is the DHCP over IKE draft(s) I promised to send to here. This first draft is the replacement text to the draft-ietf-ipsec-ikev2 draft, and it would replace the configuration payload text in it. It includes the basic description of the protocol, but not how to actually use the RADIUS or DHCPv4 etc backends. It tries to include enough information about the DHCP protocol itself so that most implementators can simply read this text without need to go to the DHCP RFC. Next draft will describe how to use DHCP server and/or client with this protocol, and the last draft will describe how to use RADIUS backend with this protocol. Later we need document describing how to use DHCPv6, but as the DHCPv6 is still a draft itself I didn't want to write that document yet (i.e if we decide to select configuration payload anyways)... These drafts ARE NOT yet submitted as IETF drafts, as I didn't get reply back from the WG chairs whether they should be WG drafts or not. I will submit them as real drafts when I get that information. ---------------------------------------------------------------------- IP Security Protocol Working Group (IPSEC) T. Kivinen INTERNET-DRAFT 2 April 2003 draft-xxx-dhcp-over-ike-00.txt Expires: 2 October 2003 DHCP over IKE Status of This Memo This document is a submission to the IETF IP Security Protocol (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@lists.tislabs.com) or to the editor. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes method of getting the IP security (IPsec) remote access client configuration information from the security gateway by tunneling dynamic host configuration protocol (DHCP) packets inside the internet key exchange (IKE) version 2 protocol. T. Kivinen [page 1] INTERNET-DRAFT 2 April 2003 Table of Contents 1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. DHCP-over-IKE protocol . . . . . . . . . . . . . . . . . . . . . 3 4. DHCP packet formatting . . . . . . . . . . . . . . . . . . . . . 6 5. DHCP payload . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Format of DHCPv4 packet . . . . . . . . . . . . . . . . . . . . 7 7. Typical DHCPv4 packet exchange . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . . . 12 9. Non-Normative References . . . . . . . . . . . . . . . . . . . . 12 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 1. Requirements The DHCP-over-IKE protocol described here fullfills the following requirements: o Get the IP address for the client "in time" for use in the Traffic Selectors. o Protocol must be able to be use any method of getting the actual configuration data in the security gateway end. This is including but not limiting to: RADIUS, DHCPv4, LDAP, DHCPv6, RS/RA-stateless-IPv6, Diameter, PIB, or local configuration information database in the security gateway. o The configuration protocol might be tied to the EAP authentication progress, i.e for some cases the authentication of the client must be done first before the security gateway can get the configuration information for that client. o It should be possible for the client to get the same address each time it requests it. This implies some kind of persistent "hardware"/node identifier (note "hardware"/node ID != IKE ID). 2. Introduction The basic protocol is to put the DHCP [RFC2131] packets inside the IKEv2 packets as separate payload(s). This does not imply that either end actually has to use DHCP for configuration, but we are simply reusing the existing packet format, which allows wide variety of configuration options. This also allows us to support all current and future configuration needs as defined in the DHCP protocol. The basic flow of the DHCP exchange is: Server 1 Client Server 2 -------- ------ -------- <----------- DHCPDISCOVER (broadcast) ---------> T. Kivinen [page 2] INTERNET-DRAFT 2 April 2003 DHCPOFFER --------------> <------------------ DHCPOFFER <------------ DHCPREQUST (broadcast) ----------> <-------------------- DHCPACK The DHCPDISCOVER and DHCPOFFER packets might be missing if the client already have configuration and only wants to request that it can actually use it. The actual binding for the addres happens during the DHCPACK packet. 3. DHCP-over-IKE protocol The protocol flow of the DHCP-over-IKE combined with EAP is as follows: Client Security Gateway ------ ---------------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr, DHCP} --> <-- HDR, SK {IDr, [CERT,] AUTH, [EAP,] DHCP} (following packets can be repeated as many times as needed) HDR, SK {[EAP,] [DHCP]} --> <-- HDR, SK {[EAP,] [DHCP]} HDR, SK {[EAP,] [AUTH,] [DHCP] } --> <-- HDR, SK {[EAP,] [AUTH,], [DHCP,] SAr2, TSi, TSr } The first two packets are the normal IKE_SA_INIT exchange. The IKE_AUTH phase following that can take as many steps as needed to finish both the EAP and DHCP protocols. The EAP protocol is finished when the security gateway sends EAP(success) packet. The DHCP protocol is finished when the security gateway sends DHCP(ACK) packet. In the first IKE_AUTH packet the client will include the DHCP payload indicating it wants to have configuration from the security gateway. This DHCP payload may either be DHCPDISCOVER (the client does not already have address, i.e it is in DHCP init state) or DHCPREQUST T. Kivinen [page 3] INTERNET-DRAFT 2 April 2003 (client is requesting for previously given address, i.e it is in DHCP init-reboot state). If the first packet is DHCPDISCOVER then the security gateway will eventually reply with DHCPOFFER payload, and then client sends DHCPREQUEST payload. When security gateway replies to the DHCPREQUEST with DHCPACK then the configuration protocol is finished. If the first DHCP payload is DHCPREQUEST, the reply might either be DHCPACK (finishing the configuration) or DHCPNAK, meaning that the client was denied to use of requested address. After DHCPNAK the client MUST start the configuration protocol from the beginning by sending DHCPDISCOVER packet (i.e move to the DHCP init state). If the paramters are not accetable the security gateway SHOULD reply with DHCPNAK instead of waiting for the client to timeout the DHCP rebooting phase and fall back to DHCP init state (i.e back to sending DHCPDISCOVER). The EAP process might be going on before, after or simultaneously to the configuration progress. I.e in case of RADIUS [RFC2865] backend is used then the configuration data might be only known after the authentication process is finished, in which case the security gateway will postpone replying to the DHCPDISCOVER or DHCPREQUEST until EAP prosess is finished. The AUTH payload in the reply to the first IKE_AUTH packet is normal authentication packet of the security gateway, i.e either the signature or the MAC depending which authentication method is used. If the EAP method is such that it creates a shared key between the client and security gateway then the packets having the final EAP payloads MUST also have AUTH payloads created using that shared key. When the security gateway detects that both EAP and DHCP configuration is finished it will send reply packet containing the final EAP or DHCP payload (depending which of those ended last), and payloads needed to complete the CREATE_CHILD_SA (i.e SAr2, and Traffic Selectors). When using DHCP to request configuration data from the security gateway the client MUST use wildcard address range in traffic selectors when starting to create the SA, and the security gateway MUST then narrow the traffic selectors down. I.e the client uses address range from 0.0.0.0 to 255.255.255.255 in TSi and TSr when sending the SAi2. The protocol and port range can be specified, but address normally cannot be, as it is not yet known (the client is requesting it from the security gateway). The security gateway MUST narrow the traffic selectors so that the TSi includes only the configured IP address of the client, and the TSr SHOULD include the subnet(s) accessable through the security gateway. Note, that since the security gateway might be using external configuration backend, the client needs to use normal DHCP retransmission policies when sending the requests. I.e if the security gateway does not reply with a packet containing DHCP payload, the client should send new IKE packet having the same DHCP payload (but new message id), so that security gateway has possibility to sending back the reply T. Kivinen [page 4] INTERNET-DRAFT 2 April 2003 (security gateway cannot send the DHCP packet before client sends next request to it), and if client is trying to use DHCPREQUEST and does not get any reply back (or receives DHCPNAK) then client starts again with DHCPDISCOVER. Security gateway might also send multiple DHCPOFFER packets, and client can select the one that suits it best to be used. The security gateway SHOULD wait for configurable time (few seconds) for the replies from external configuration backends and collect all replies to the reply packet (as separate DHCP payloads) going back to the client. It can also send reply back immediately when it has first reply, to fasten up the process (for example in case where it knows there is only one DHCP server in the network). If no replies are received during that time the security gateway MUST send reply to the IKE packet, without the DHCP payload. Example data flow with new client doing DHCP and one-time-password EAP: Client Security Gateway ------ ---------------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi(0.0.0.0-255.255.255.255), TSr(0.0.0.0-255.255.255.255), DHCP(DISCOVER)} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP(OTP-Challenge), DHCP(OFFER, ip=1.2.3.4)} HDR, SK {EAP(OTP-Reply), DHCP(REQUEST, ip=1.2.3.4) } --> <-- HDR, SK {EAP(success), DHCP(ACK, ip=1.2.3.4), SAr2, TSi(1.2.3.4-1.2.3.4), TSr(0.0.0.0- 255.255.255.255)} Another example doing signature authentication for both ends, and client requesting reuse of the previous address: Client Security Gateway ------ ---------------- T. Kivinen [page 5] INTERNET-DRAFT 2 April 2003 HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERT], [CERTREQ,] [IDr,] AUTH, SAi2, TSi(0.0.0.0-255.255.255.255), TSr(0.0.0.0-255.255.255.255), DHCP(REQUEST, ip=1.2.3.4)} --> <-- HDR, SK {IDr, [CERT,] AUTH, DHCP(ACK, ip=1.2.3.4), SAr2, TSi(1.2.3.4-1.2.3.4), TSr(0.0.0.0- 255.255.255.255)} 4. DHCP packet formatting The DHCP packet is filled as normally, except the client will use hardware type (htype) of 31 signifying an IPsec tunnel mode virtual interface. The chaddr field MUST include an identifier unique to the virtual subnet. The client MUST use the same chaddr field in all subsequent messages within the same exchange. In addition, the chaddr SHOULD be persistent between reboots so that the DHCP server will be able to re-assign the same address if desired. The hlen and chaddr fields SHOULD be determined as follows: o If one or more LAN interfaces are available, the hlen and chaddr fields SHOULD be determined from the active LAN interface with the lowest interface number. If no active LAN interface is available, then the parameters SHOULD be determined from the LAN interface with the lowest interface number. This enables the chaddr to be persistent between reboots, as long as the LAN interface hardware is not removed. o If there is no LAN interface, the chaddr field SHOULD be determined by concatenating x'4000', the IPv4 address of the interface supplying network connectivity, and an additional octet. The x'4000' value indicates a locally administered unicast MAC address, thus guaranteeing that the constructed chaddr value will not conflict with a globally assigned value. The additional octet (which MAY represent an interface number) SHOULD be persistent between reboots, so that the chaddr value will be persistent across reboots if the assigned IPv4 address remains consistent. T. Kivinen [page 6] INTERNET-DRAFT 2 April 2003 If the above prescription is followed, then the chaddr will always be unique on the virtual subnet provided that the remote host only brings up a single tunnel to the security gateway. Where a LAN interface is available, the chaddr will be globally unique. When a non-LAN interface is available and a unique Internet address is assigned to the remote host, the chaddr will also be globally unique. Where a private IP address is assigned to a non-LAN interface, it will not be globally unique. 5. DHCP payload The DHCP payload, is used to exchange configuration information between IKE peers. The DHCP Payload is defined as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Packet Type ! ! +-+-+-+-+-+-+-+-+ ! ! ! ~ Configuration Packet ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Packet Type - Type of the DHCP packet. Currently defined types are: Packet Type Value =========== ===== RESERVED 0 DHCPv4 packet [RFC2131] 1 o Configuration Packet (variable length) - Contains the configuration packet. The exact packet format depends of the packet type. The payload type for the DHCP Payload is sixteen (16). This document describes the DHCPv4 packet type, and other documents may later describe other packet formats (for example DHCPv6). If unknown DHCP Payload packet type is received then UNKNOWN-DHCP- PAYLOAD-TYPE notification MUST be sent back. This allows future versions to probe if the newer packet type is supported or not (i.e if server responds with notification, then it is not supported, if it replies or does not reply at all immediately, then it is supported). 6. Format of DHCPv4 packet The typical packet put inside the DHCP Payload will be (described here T. Kivinen [page 7] INTERNET-DRAFT 2 April 2003 only to make it easier for implementators to understand what goes where, see [RFC2131] for full details): 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! op ! htype ! hlen ! hops ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! xid ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! secs ! flags ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ciaddr ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! yiaddr ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! siaddr ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! giaddr ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! chaddr ! ! (16 bytes) ! ! ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! sname ! ! (64 bytes) ! ~ ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! file ! ! (128 bytes) ! ~ ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! byte 99 (0x63)!byte 130 (0x82)! byte 83 (0x53)! byte 99 (0x63)! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! opt53 ! option len (1)! opt53 value ! opt50 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! option len (4)! requested IP address ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ...... ! opt255 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o op - BOOTP message option code / message type, 1 = BOOTREQUEST (from client to server), 2 = BOOTREPLY (from server to client) o htype - Hardware address type, 31 = IPsec tunnel mode virtual interface [RFC3456]. o hlen - Hardware address length = 6. o hops - Client sets to zero, optionally used by relay agents when T. Kivinen [page 8] INTERNET-DRAFT 2 April 2003 booting via a relay agent. o xid - Transaction ID, a random number chosen by the client, used by the client and server to associate messages and responses between a client and a server. o secs - Filled in by client, seconds elapsed since client began address acquisition or renewal process. o flags - Flags (normally zero). o ciaddr - Client IP address; only filled in if client is in BOUND, RENEW or REBINDING state and can respond to ARP requests, i.e in normal initial exchange always zero, i.e client fill with zeros and the server copies from the request packet. o yiaddr - 'your' (client) IP address. Never filled in by the client, sent by the server to client telling the clients new IP address. o siaddr - IP address of next server to use in bootstrap. Normally zero. o giaddr - Relay agent IP address, used in booting via a relay agent. Packets inside the DHCP payload this is normally set to zero. o chaddr - Client hardware address. Filled in by the client as specified in section 4. o sname - Optional server host name, null terminated string. Normally zero. o file - Boot file name, null terminated string; "generic" name or null in DHCPDISCOVER, fully qualified directory-path name in DHCPOFFER. Normally zero. o byte 99, 130, 83, 99 - Magic cookie. o opt53 - DHCP Message Type. o option len - Length of the option in bytes not including the option tag and this length byte. o opt53 value - Type of the DHCP message. Client normally first send DHCPDISCOVER, and the server replies with DHCPOFFER. Then client finishes the exchange by sending DHCPREQUEST and server verifies that exchange is done by DHCPACK. Type Value ==== ===== DHCPDISCOVER 1 DHCPOFFER 2 DHCPREQUEST 3 T. Kivinen [page 9] INTERNET-DRAFT 2 April 2003 DHCPDECLINE 4 DHCPACK 5 DHCPNAK 6 DHCPRELEASE 7 DHCPINFORM 8 o opt50 - Requested IP Address. Only present in the DHCPREQUEST, when client requests to be allowed to use this IP address. o requested IP address - IP address client requests to use. Client copies the ciaddr field from the DHCPOFFER to here when sending DHCPREQUEST. o opt255 - End of options. Some other useful options [RFC1533] and their formats are: o Pad - opt0, no data. Used for padding. o Subnet mask - opt1, data: 4 subnet mask bytes. o Domain name server - opt6, data: 4 * N address bytes for N dns servers. o Hostname - opt12, data: N bytes of hostname. o NBNS - opt44, data: 4 * N address bytes for N NetBIOS name servers. o IP address lease time - opt51, data: 4 bytes, lease time in seconds. o Server identifier - opt54, data: 4 bytes, address of the DHCP server, send by server, and copied back in client if known. o Parameter request list - opt55, data: N bytes, each byte specifying one option which is requested from the server (client sends this, server tries to put all these options in its reply). o Option overload - opt52, data: 1 byte. Value 1 means that the file field contains options instead of its normal contents. Value 2 means that sname fields contains options, and value 3 means that both of those fields contain options. 7. Typical DHCPv4 packet exchange The client will first create DHCPDISCOVER payload, and fill in the following data: o op - 1 = BOOTPREQUEST o htype - 31 = IPsec tunnel mode virtual interface o hlen - 6 T. Kivinen [page 10] INTERNET-DRAFT 2 April 2003 o xid - random transaction id o chaddr - hardware address, as specified in section 4. o magic - bytes 99, 130, 83, 99 o DHCP Message Type option - bytes 53, 1, 1 o Parameter request list option - bytes 55, n, n bytes of option numbers, of which the client wants to request. o End of options - bytes 255 All other fields are filled with zeros. The server will reply with DHCPOFFER payload, with following data: o op - 2 = BOOTREPLY o yiaddr - IP address offered for client o magic - bytes 99, 130, 83, 99 o DHCP Message Type option - bytes 53, 1, 2 o Server identifier - bytes 51, 4, IP address identifying the server giving out information (DHCP server, security gateway etc). o Other configuration options. o End of options - bytes 255 All other fields are copied form the DHCPDISCOVER packet. DHCP options are not copied from the DHCPDISCOVER packet. Those first two packets can be ignored if client already has IP address and wants to try to use that one. Client will request to use given address by sending DHCPREQUEST payload, with following data: o op - 1 BOOTREQUEST o htype, hlen, xid, chaddr - same as DHCPDISCOVER (== copied from DHCPOFFER). o yiaddr - filled with zero o magic - bytes 99, 130, 83, 99 o DHCP Message Type option - bytes 53, 1, 3 o Requested IP Address - bytes 50, 4, IP address to be requested (i.e the yiaddr from the DHCPOFFER or the old IP address). T. Kivinen [page 11] INTERNET-DRAFT 2 April 2003 o Server identifier - bytes 51, 4, IP address - copied from the DHCPOFFER (if trying to use previous IP address this should be filled with the value from the previous run). o Parameter request list option - bytes 55, n, n bytes of option numbers, of which the client wants to request. o Other options can be copied from the DHCPREQUEST payload. The server will reply with DHCPACK payload, and finish the configuration protocol. The DHCPACK is filled with following data: o op - 2 = BOOTREPLY o yiaddr - IP address offered for client o magic - bytes 99, 130, 83, 99 o DHCP Message Type option - bytes 53, 1, 5 o Server identifier - bytes 51, 4, IP address identifying the server giving out information (DHCP server, security gateway etc). o Other configuration options. o End of options - bytes 255 The option should be same that what was in the DHCPOFFER payload. 8. Normative References [RFC2131] Droms R., "Dynamic Host Configuration Protocol", March 1997 9. Non-Normative References [RFC2865] Rigney, C., S. Willens, A. Rubens, and Simpson W., "Remote Authentication Dial In User Service (RADIUS)", June 2000. [RFC1533] Alexander S., and Droms R., "DHCP Options and BOOTP Vendor Extensions", October 1993. [RFC3456] Patel B., B. Adoba, S. Kelly, and Gupta V., "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", January 2003. 10. Authors' Addresses Tero Kivinen SSH Communications Security Corp T. Kivinen [page 12] INTERNET-DRAFT 2 April 2003 Fredrikinkatu 42 FIN-00100 HELSINKI Finland E-mail: kivinen@ssh.fi T. Kivinen [page 13] -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Apr 3 07:02:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33F2UJM018492; Thu, 3 Apr 2003 07:02:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08934 Thu, 3 Apr 2003 09:24:20 -0500 (EST) Date: Thu, 3 Apr 2003 17:01:01 +0300 (EEST) Message-Id: <200304031401.h33E11P04996@tero.kivinen.iki.fi> X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: DHCP over IKE draft 2/3 Organization: Helsinki University of Technology Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-Edit-Time: 1 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IP Security Protocol Working Group (IPSEC) T. Kivinen INTERNET-DRAFT 2 April 2003 draft-ietf-ipsec-dhcp-over-ike-dhcpd-00.txt Expires: 2 October 2003 Using DHCP server/client backend for DHCP over IKE Status of This Memo This document is a submission to the IETF IP Security Protocol (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@lists.tislabs.com) or to the editor. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes method of using dynamic host configuration pro- tocol (DHCP) as a backend for the internet key exchange (IKE) version 2 host configuration protocol. T. Kivinen [page 1] INTERNET-DRAFT 2 April 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Using existing DHCP client . . . . . . . . . . . . . . . . . . . 2 3. Using existing DHCP server . . . . . . . . . . . . . . . . . . . 2 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 6. Normative References . . . . . . . . . . . . . . . . . . . . . . 4 7. Non-Normative References . . . . . . . . . . . . . . . . . . . . 5 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The IKEv2 [IKEV2] offers way to put DHCP [RFC2131] packets inside the IKE packet exchange to do the host configuration for the remote access clients. This protocol describes how to use existing DHCP client and/or server with IKEv2 host configuration protocol. 2. Using existing DHCP client The host configuration protocol in IKEv2 is defined so that it can be easily be used with currently existing DHCP client. All packets normally sent by the DHCP client are simply intercepted and put inside the DHCP payload. If this is during the initial IKE SA creation phase, the the DHCP payloads are sent inside the IKE_AUTH packets. If the DHCP packet is intercepted when the IKE SA is already ready, then the DHCP payloads are sent as informational exchange. Informational exchanges MUST NOT be used before the IKE SA creation is finished. The reason for the interception and sending DHCP packets inside IKE is that the IPsec SAs created between the client and security gateway might not allow DHCP traffic, and also because replies to the DHCP packets might come as broadcast in some cases (DHCPNAK), and to get those working we MUST use DHCP relay processing in the security gateway end. Also the actual configuration backend on the other end might not be DHCP server, but for example RADIUS [RFC2865] server. Note, that the reply to the information exchange having DHCP payload, might not contain the reply to the actual DHCP request, i.e it might be empty, and the reply might be sent as separate informational exchange initiated by the security gateway when the reply packet is available or during the next reply to IKE_AUTH if the IKE SA is not yet ready. 3. Using existing DHCP server If the security gateway wants to use existing DHCP server(s) it MUST act as a DHCP relay. When it receives DHCP payload from the client it MUST set the giaddr field to contain one of its own IP addresses, and it SHOULD add DHCP Relay Agent Information Option [RFC3046] (DHCP option code 82) as last DHCP option just before end option. The Agent Circuit ID Sub-option (sub-option code 1) is filled with the security gateways T. Kivinen [page 2] INTERNET-DRAFT 2 April 2003 IKE SPI value. In some cases the security gateway might put this DHCP relay to its own IP alias and use that address in the giaddr field. This is especially useful if the security gateway already has DHCP server or DHCP relay running. Where the DHCP server does not support the Relay Agent Information Option, stateless Relay Agent behavior will not be possible. In such cases, implementations MAY devise a mapping between the xid, chaddr, and IKE SA in order to route the DHCP server response to the appropriate IKE SA. Note that this is particularly undesirable in large VPN servers where the resulting state will be substantial. After sending the request out (either to the configured DHCP server(s) or to broadcast address), the security gateway should wait for configurable time (default should be few seconds) and collect replies received during that. The security gateway might reply immediately when the first reply is received, or it might wait for the full time and send all packets received during that time. It normally is not useful to wait for multiple DHCPACK packets, as there should only be exactly one of those. On the other hand when waiting for the DHCPOFFER packets in environment where there are multiple DHCP servers available (load balancing, high availability cases etc) it might be better to wait for more than one DHCPOFFER packet. When the security gateway gets DHCP replies back from the network it should use the DHCP Relay Agent Information to associate the reply to specific IKE SA. The security gateway MUST remove the DHCP Relay Agent Information Option and set the giaddr to 0 before encoding the DHCP packet inside the IKE DHCP payload. If during the IKE SA creation phase the security gateway receives DHCP replies during the time it does not have request to be replied (i.e it has replied to last IKE request from the client, and the client has not yet sent a next request), it MUST keep at least the last DHCP reply it has received, and send it to the client when possible (i.e when the client makes next IKE request). Security gateway cannot during the IKE SA creation phase initiate exchanges to the client itself, it must wait for the client to drive the exchange. After the IKE SA is created then the security gateway can send replies back to the client as separate informational exchanges. When security gateway sees DHCPACK it must get the yiaddr from the payload and configure that to be the clients IP address. This clients IP address is used during the IKE_AUTH exchange to narrowing the TSi selector down to only include clients IP address. Security gateway MUST also make sure that if the same client IP address is given out to two different entities (== clients IKE SA authenticated IKE identity are different) the older one of those IPsec SAs is deleted. I.e if DHCPACK is received to address which is already associated with T. Kivinen [page 3] INTERNET-DRAFT 2 April 2003 some other entity, then the old entities IPsec SAs are deleted. The DHCP server should be sending the reply packets to the Relay address, i.e to the security gateway, but in some cases the DHCP server might also try to send the packet directly to the client's IP address (DHCP renewing state, or replies to DHCPINFORMs). The security gateway SHOULD try to intercept all DHCP packets going directly to clients IP address and encapsulate them inside the DHCP payload in the IKE SA. This is never needed for the IKE_AUTH state as the DHCP server will not try to send packets directly to the client (the client is either in DHCP init or DHCP init-reboot state, it cannot be in DHCP renewing state). The reason for the interception is to make sure the DHCP requests gets back to the client even if the IPsec SA created between client and security gateway does not allow DHCP traffic in it, or the client might not be actually using DHCP client to do the configuration. As any of those packets going directly to the client cannot have effect to the security gateway operations, there is no mandatory requirement for the security gateway to intercept those packets. Only packet that could affect the security gateway operations are the DHCPACKs which have different IP address than given in previous case, and those packets cannot be sent to the client directly. If client never gets DHCPACK back (which might be sent by the DHCP server directly to the client) when in DHCP renewing state, it moves to DHCP rebinding state, which uses broadcasts, and the client will get packets through. The client MUST NOT use DHCPINFORM packets, but use normal DHCP address allocation instead. The security gateway does need to support DHCPINFORM processing. 4. Security Considerations If real DHCP server is used, then the DHCP protocol between security gateway and the DHCP server might be vulnerable to different kind of attacks. If the DHCP server is inside the security gateway itself then such attacks are not possible. 5. IANA Considerations This document does not have any actions for IANA. 6. Normative References [IKEV2] Kaufman C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf- ipsec-ikev2-05.txt, February 2003 [RFC3046] Patrick M., "DHCP Relay Agent Information Option", January 2001 T. Kivinen [page 4] INTERNET-DRAFT 2 April 2003 [RFC2131] Droms R., "Dynamic Host Configuration Protocol", March 1997 7. Non-Normative References [RFC2865] Rigney, C., S. Willens, A. Rubens, and Simpson W., "Remote Authentication Dial In User Service (RADIUS)", June 2000. [RFC1533] Alexander S., and Droms R., "DHCP Options and BOOTP Vendor Extensions", October 1993. 8. Authors' Addresses Tero Kivinen SSH Communications Security Corp Fredrikinkatu 42 FIN-00100 HELSINKI Finland E-mail: kivinen@ssh.fi T. Kivinen [page 5] -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Apr 3 07:52:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33FqpJM022618; Thu, 3 Apr 2003 07:52:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09237 Thu, 3 Apr 2003 10:13:26 -0500 (EST) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 3 Apr 2003 07:17:39 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ipsec@lists.tislabs.com cc: "Wijnen, Bert (Bert)" Subject: Use of unassigned SMI numbers in IPsec Flow Monitoring MIBs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, I notice that the IPsec Flow Monitoring MIB module in and the associated TC MIB module in use root OIDs { experimental 171 } and { experimental 170 } respectively. These OIDs are not listed in the IANA SMI Numbers registry. If they are in fact unassigned numbers, then I suggest that the authors either go to the IANA to get legitimate experimental assignments or else use the { mib-2 xxx } convention that is customary in Internet Drafts (and recommended in Section 4.5 of the MIB review guidelines document ). Appropriating unassigned SMI numbers is not a good idea, even if they appear only in an Internet Draft. Thanks, Mike Heard From owner-ipsec@lists.tislabs.com Thu Apr 3 09:09:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33H97JM028762; Thu, 3 Apr 2003 09:09:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09491 Thu, 3 Apr 2003 11:27:44 -0500 (EST) Message-ID: <3E8C6072.2080109@sockeye.com> Date: Thu, 03 Apr 2003 11:25:22 -0500 From: John Shriver Organization: Sockeye Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-flowmon-mib-tc-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Most of the textual-conventions duplicate those in draft-ietf-ipsec-doi-tc-mib-07.txt, on which there is a final push effort on to get "done". Some are different in ways that cause them not to match the protocol values (IkeNegoMode). Some are not numbers used in any protocol, so I don't see why the IANA would be maintaining them (ControlProtocol). This looks to be a duplication of effort, with far less coverage of the number space than the established project. From owner-ipsec@lists.tislabs.com Thu Apr 3 14:22:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33MMUJM018054; Thu, 3 Apr 2003 14:22:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10568 Thu, 3 Apr 2003 16:49:15 -0500 (EST) Date: Thu, 3 Apr 2003 16:52:48 -0500 From: Uri Meth To: ipsec@lists.tislabs.com Subject: IKEv2 cookie question Message-ID: <20030403165248.A15033@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Organization: SPARTA Inc. (Secure Systems Engineering Division) USMail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x233 Fax: (410) 381-5559 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In the MSEC group, there has been a proposal to potentially add cookies to the GSAKMP protocol. Since IKE had already dealt with this issue I looked into how you did cookies. I am very intrigued by your use of cookies, but in reading through the IKEv2 spec I have some questions. Either I do not understand your syntax, something is missing, or there is some mis-information. Please help me clarify what is happening. In Section 2.6 - Cookies , you give the disection for you message structure using cookies: Initiator Responder ----------- ----------- HDR(A,0), SAi1, KEi, Ni --> <-- HDR(A,0), N(COOKIE_REQUIRED), N(COOKIE) HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> >From this message I interpret that the reponder sends the initiator a message with two (2) notification payloads, cookie_required and cookie. The initiator then rebuilds the initial message with the cookie received from the responder in the notification cookie payload. However, in Section 3.10.1 - Notify Message Types, you only have a value for COOKIE and not for COOKIE_REQUIRED. All this leads me to believe that what you really meant to say is that the responder sends a message with one (1) notification payload containing the Cookie value. The initiator takes this cookie value from the notification payload and sends it back to the responder in the rebuilt initial message. So which definition is correct? Is there any way to fix the spec to clear up this ambiguity? Thanx UM -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 From owner-ipsec@lists.tislabs.com Thu Apr 3 15:41:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33NfGJM022741; Thu, 3 Apr 2003 15:41:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA10740 Thu, 3 Apr 2003 18:10:25 -0500 (EST) Message-Id: <200304032313.h33NDu005901@sydney.East.Sun.COM> Date: Thu, 3 Apr 2003 18:13:56 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: IKEv2 cookie question To: ipsec@lists.tislabs.com, umeth@sparta.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8BB1enpDFjxQT0r/RIeVGQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Uri is correct. (good catch!) The reason for having both N(COOKIE_REQUIRED) and N(COOKIE) is that IKEv2 has high numbers for type codes for notifies for "just information" vs low numbers for type codes of notifies for "errors". Since Alice also sends a COOKIE in the next message, then that would argue for making the cookie notification payload a "just information" type. But since Bob is explaining why he's refusing the connection attempt, it would argue for being an error type when Bob sends it. So the spec does it by having two payloads...one an error (COOKIE_REQUIRED), and the other (COOKIE) passing the cookie. Certainly there are lots of perfectly reasonable ways of doing this (for instance, just removing the N(COOKIE_REQUIRED) and not having it look like an "error", or having two type codes for COOKIE, depending on which direction the COOKIE is travelling). Nothing really wrong with how Charlie chose to do it, other than as Uri points out, the spec is inconsistent. So probably the easiest change is to add a low-number notification type for COOKIE_REQUIRED, e.g., COOKIE_REQUIRED 12 IKE_SA_INIT rejected because no cookie was included. >>Is there any way to fix the spec to clear up this ambiguity? err...yeah...I believe it's not too late at this point. Thanks, again. Radia From: Uri Meth In the MSEC group, there has been a proposal to potentially add cookies to the GSAKMP protocol. Since IKE had already dealt with this issue I looked into how you did cookies. I am very intrigued by your use of cookies, but in reading through the IKEv2 spec I have some questions. Either I do not understand your syntax, something is missing, or there is some mis-information. Please help me clarify what is happening. In Section 2.6 - Cookies , you give the disection for you message structure using cookies: Initiator Responder ----------- ----------- HDR(A,0), SAi1, KEi, Ni --> <-- HDR(A,0), N(COOKIE_REQUIRED), N(COOKIE) HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> From this message I interpret that the reponder sends the initiator a message with two (2) notification payloads, cookie_required and cookie. The initiator then rebuilds the initial message with the cookie received from the responder in the notification cookie payload. However, in Section 3.10.1 - Notify Message Types, you only have a value for COOKIE and not for COOKIE_REQUIRED. All this leads me to believe that what you really meant to say is that the responder sends a message with one (1) notification payload containing the Cookie value. The initiator takes this cookie value from the notification payload and sends it back to the responder in the rebuilt initial message. So which definition is correct? Is there any way to fix the spec to clear up this ambiguity? Thanx UM -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 From owner-ipsec@lists.tislabs.com Fri Apr 4 05:50:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34DojJM004042; Fri, 4 Apr 2003 05:50:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12707 Fri, 4 Apr 2003 08:11:05 -0500 (EST) Message-Id: <200304032103.QAA13664@ietf.org> To: IETF-Announce:;;;;@tislabs.com;;; Cc: RFC Editor , Internet Architecture Board , ipsec@lists.tislabs.com From: The IESG Subject: Protocol Action: The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec to Proposed Standard Date: Thu, 03 Apr 2003 16:03:15 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has approved "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec" as a Proposed Standard. This document is the product of the IPsec Working Group. The IESG contact persons are Steve Bellovin and Russ Housley. Technical Summary This document defines a new hash algorithm for use in IPsec ESP. It is a variant of the traditional use of a cipher in Cipher Block Chaining (CBC) Mode to compute a hash value. However traditional CBC mode hashes are vulnerable to attack if the amount of data to be protected is of variable length. This document defines a variant of this approach, applied to the Advanced Encryption Standard (AES) that is proof against this vulnerability. Working Group Summary There was working group consensus on this document. Protocol Quality These documents were reviewed by Jeff Schiller. From owner-ipsec@lists.tislabs.com Fri Apr 4 09:58:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34HwFJM022456; Fri, 4 Apr 2003 09:58:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13497 Fri, 4 Apr 2003 12:18:58 -0500 (EST) Date: Fri, 4 Apr 2003 12:23:06 -0500 From: Uri Meth To: ipsec@lists.tislabs.com Subject: Re: IKEv2 cookie question Message-ID: <20030404122306.A19821@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com References: <200304032313.h33NDu005901@sydney.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200304032313.h33NDu005901@sydney.East.Sun.COM>; from Radia.Perlman@sun.com on Thu, Apr 03, 2003 at 06:13:56PM -0500 Organization: SPARTA Inc. (Secure Systems Engineering Division) USMail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x233 Fax: (410) 381-5559 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Based on the addition of the COOKIE_REUQIRED type, and there being 2 notification payloads in the responder message, I still would like to make sure I understand one last point - the contents of N(COOKIE_REQUIRED) (the notification payload of type COOKIE_REQUIRED). The Notification_Data field of this payload, will be empty as there is nothing more to pass except to let the initiator know that a cookie is required. The real information that will be necessary to extract from the message is the computed valued which is contained in the Notification_Data field of the N(COOKIE) payload. Is all this correct? Thanx UM On Thu, Apr 03, 2003 at 06:13:56PM -0500, Radia Perlman - Boston Center for Networking wrote: > Uri is correct. (good catch!) > > The reason for having both N(COOKIE_REQUIRED) and N(COOKIE) > is that IKEv2 has high numbers for type codes for notifies > for "just information" vs low numbers for type codes of > notifies for "errors". Since Alice also sends a COOKIE > in the next message, then that would argue for making > the cookie notification payload a "just information" type. > But since Bob is explaining why he's refusing the connection > attempt, it would argue for being an error type when Bob sends it. > > So the spec does it by having two payloads...one an error (COOKIE_REQUIRED), > and the other (COOKIE) passing the cookie. > > Certainly there are lots of perfectly reasonable ways of > doing this (for instance, just removing the N(COOKIE_REQUIRED) > and not having it look like an "error", or having two type > codes for COOKIE, depending on which direction the COOKIE is > travelling). Nothing really wrong with how Charlie chose to > do it, other than as Uri points out, the spec is inconsistent. > > So probably the easiest change is to add a low-number notification > type for COOKIE_REQUIRED, e.g., > > COOKIE_REQUIRED 12 > > IKE_SA_INIT rejected because no cookie was included. > > > >>Is there any way to fix the spec to clear up this ambiguity? > err...yeah...I believe it's not too late at this point. Thanks, again. > > Radia > > > > > From: Uri Meth > > > In the MSEC group, there has been a proposal to potentially add cookies > to the GSAKMP protocol. Since IKE had already dealt with this issue I > looked into how you did cookies. I am very intrigued by your use of > cookies, but in reading through the IKEv2 spec I have some questions. > Either I do not understand your syntax, something is missing, or there > is some mis-information. Please help me clarify what is happening. > > In Section 2.6 - Cookies , you give the disection for you message > structure > using cookies: > > Initiator Responder > ----------- ----------- > HDR(A,0), SAi1, KEi, Ni --> > > <-- HDR(A,0), N(COOKIE_REQUIRED), > N(COOKIE) > > HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> > > > From this message I interpret that the reponder sends the initiator a > message with two (2) notification payloads, cookie_required and cookie. > The initiator then rebuilds the initial message with the cookie received > from the responder in the notification cookie payload. > > However, in Section 3.10.1 - Notify Message Types, you only have a value > for COOKIE and not for COOKIE_REQUIRED. > > All this leads me to believe that what you really meant to say is that > the responder sends a message with one (1) notification payload > containing the Cookie value. The initiator takes this cookie value from > the notification payload and sends it back to the responder in the > rebuilt initial message. > > So which definition is correct? Is there any way to fix the spec to > clear up this ambiguity? Thanx > > UM > -- > Uri Meth (410) 872 - 1515 x233 (voice) > SPARTA, Inc. (410) 872 - 8079 (fax) > 7075 Samuel Morse Drive umeth@sparta.com > Columbia, MD 21046 > -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 From owner-ipsec@lists.tislabs.com Fri Apr 4 13:35:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34LZeJM004941; Fri, 4 Apr 2003 13:35:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14007 Fri, 4 Apr 2003 16:03:20 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Fri, 4 Apr 2003 16:06:52 -0500 To: Barbara Fraser , "Theodore Ts'o" From: Karen Seo Subject: new versions of IPsec AH and ESP specs Cc: ipsec@lists.tislabs.com, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Barbara, Ted, We have submitted revised drafts for AH & ESP with the changes listed at the end of this message. - draft-ietf-ipsec-esp-v3-04.txt - draft-ietf-ipsec-rfc2402bis-02.txt We believe these revisions address all comments received to-date. So we'd like to request that the working group initiate Last Call on these two drafts. Thank you, Karen In addition to minor edits for clarity and consistency, typo fixes, and updates to dates and references, the following changes were made to both AH and ESP (see details below) 1. The MSEC working group has published an ID that makes it clear that multicast support will require additional changes beyond the demultiplexing and sequence number management changes that were made in the previous versions of these drafts to better accommodate multicast. Therefore, we have changed the drafts to make whether or not multicast requirements for SA lookup are mandatory, dependent on whether the IPsec implementation supports multicast. This avoids burdening unicast-only implementations with multicast-related requirements. 2. To clarify SA lookup for multicast traffic, we removed use of protocol field for SA lookup. 3. We moved references to mandatory algorithms to a separate document IP Authentication Header (AH) ============================= Section 2.4 Security Parameters Index (SPI), Paragraph 2, first 2 sentences From: IPsec implementations SHOULD be prepared to support both unicast and multicast SAs using the following algorithm for mapping inbound IPsec datagrams to SAs. Each entry in the Security Association Database (SAD) [KA97a] must indicate whether the SA lookup makes use of the source and destination IP addresses, in addition to the SPI (and, optionally, the protocol field). To: If an IPsec implementation supports multicast, then it MUST support multicast SAs using the following algorithm for mapping inbound IPsec datagrams to SAs. (Implementations that support only unicast traffic need not implement this demultiplexing algorithm.) Each entry in the Security Association Database (SAD) [KA97a] must indicate whether the SA lookup makes use of the source and destination IP addresses, in addition to the SPI. (For multicast SAs, the protocol field is not employed for SA lookups.) Section 2.4 Security Parameters Index (SPI), Paragraph 2, sentence 7 From: For multicast methods that rely only on the destination address to specify a multicast group, only the second bit would be set to "1," implying the need to use the destination address plus the SPI (and, optionally the protocol) to determine the appropriate SA. To: For multicast methods that rely only on the destination address to specify a multicast group, only the second bit would be set to "1," implying the need to use the destination address plus the SPI to determine the appropriate SA. Section 3.2 Integrity Algorithms, Paragraph 1, last 2 sentences Deleted: The mandatory-to-implement integrity algorithms are described in Section 5 "Conformance Requirements". Other algorithms MAY be supported. Section 3.4.2 Security Association Lookup, Paragraph 1, sentence 3 From: For multicast SAs, the destination address is also employed in the lookup (in addition to the SPI and, optionally the protocol), and the sender address also may be employed, as described in Section 2.4. To: If an implementation supports multicast traffic, the destination address is also employed in the lookup (in addition to the SPI), and the sender address also may be employed, as described in Section 2.4. Section 5. Conformance Requirements, Paragraph 1 From: Implementations that claim conformance or compliance with this specification MUST fully implement the AH syntax and processing described here and MUST comply with all requirements of the Security Architecture document. If the key used.... To. Implementations that claim conformance or compliance with this specification MUST fully implement the AH syntax and processing described here for unicast traffic, and MUST comply with all requirements of the Security Architecture document [KA98a]. Additionally, if an implementation claims to support multicast traffic, it MUST comply with the additional requirements specified for support of such traffic. If the key used.... Section 5. Conformance Requirements, Paragraph 1, last sentence From: A compliant AH implementation MUST support the following mandatory-to-implement algorithms: - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] To: The mandatory-to-implement algorithms for use with AH are described in a separate RFC, to facilitate updating the algorithm requirements independently from the protocol per se. Additional algorithms, beyond those mandated for AH, MAY be supported. Section 7. Differences from RFC 2402, Bullet 1 From: o SPI -- modified to specify a uniform algorithm for SAD lookup for unicast and multicast SAs, covering a wider range of multicast technologies. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with the destination address, and optionally the source address, to select an SA. If the receiver (unicast) or the multicast controller (multicast) opted to use the security protocol (AH) in selecting the SPI, then the security protocol is also used in the lookup. To: o SPI -- modified to specify a uniform algorithm for SAD lookup for unicast and multicast SAs, covering a wider range of multicast technologies. For unicast, the SPI may be used alone to select an SA, or may be combined with the protocol, at the option of the receiver. For multicast SAs, the SPI is combined with the destination address, and optionally the source address, to select an SA. Section 7. Differences from RFC 2402, new bullet Added bullet 3 o Moved references to mandatory algorithms to a separate document. IP Encapsulating Security Payload (ESP) ======================================= 2.1 Security Parameters Index (SPI), paragraph 3, sentences 1 and 2. From: IPsec implementations SHOULD be prepared to support both unicast and multicast SAs using the following algorithm for mapping inbound IPsec datagrams to SAs. Each entry in the Security Association Database (SAD) [KA97a] must indicate whether the SA lookup makes use of the source and destination IP addresses, in addition to the SPI (and, optionally, the protocol field). To: If an IPsec implementation supports multicast, then it MUST support multicast SAs using the following algorithm for mapping inbound IPsec datagrams to SAs. (Implementations that support only unicast traffic need not implement this demultiplexing algorithm.) Each entry in the Security Association Database (SAD) [KA97a] must indicate whether the SA lookup makes use of the source and destination IP addresses, in addition to the SPI. (For multicast SAs, the protocol field is not employed for SA lookups.) 2.1 Security Parameters Index (SPI), paragraph 3, sentence 7 From: For multicast methods that rely only on the destination address to specify a multicast group, only the second bit would be set to "1," implying the need to use the destination address plus the SPI (and, optionally the protocol) to determine the appropriate SA. To: For multicast methods that rely only on the destination address to specify a multicast group, only the second bit would be set to "1," implying the need to use the destination address plus the SPI to determine the appropriate SA. 3.2 Algorithms, Paragraph 1, sentences 1 and 2 From: The mandatory-to-implement algorithms are described in Section 5, "Conformance Requirements." Other algorithms MAY be supported. To: The mandatory-to-implement algorithms for use with ESP are described in a separate RFC, to facilitate updating the algorithm requirements independently from the protocol per se. Additional algorithms, beyond those mandated for ESP, MAY be supported. 3.4.2 Security Association Lookup, Paragraph 1, sentence 3 From: For multicast SAs, the destination address is also employed in the lookup (in addition to the SPI and, optionally the protocol), and the sender address also may be employed, as described in Section 2.1. To: If an implementation supports multicast traffic, the destination address is also employed in the lookup (in addition to the SPI), and the sender address also may be employed, as described in Section 2.1. Section 5. Conformance Requirements, Paragraph 1, sentence 1 From: Implementations that claim conformance or compliance with this specification MUST fully implement the ESP syntax and processing described here and MUST comply with all additional packet processing requirements levied by the Security Architecture document [KA98a]. If the key used.... To. Implementations that claim conformance or compliance with this specification MUST fully implement the ESP syntax and processing described here for unicast traffic, and MUST comply with all additional packet processing requirements levied by the Security Architecture document [KA98a]. Additionally, if an implementation claims to support multicast traffic, it MUST comply with the additional requirements specified for support of such traffic. If the key used.... 5. Conformance Requirements, Paragraph 1, last sentence From: A compliant ESP implementation MUST support the following mandatory-to-implement algorithms: - AES (with 128-bit keys) in CBC mode - HMAC with MD5 [MG98a] - HMAC with SHA-1 [MG98b] - NULL Encryption algorithm (RFC 2410) To: The mandatory-to-implement algorithms for use with ESP are described in a separate document, to facilitate updating the algorithm requirements independently from the protocol per se. Additional algorithms, beyond those mandated for ESP, MAY be supported. 7. Differences from RFC 2406, bullet 2 From: o SPI -- modified to specify a uniform algorithm for SAD lookup for unicast and multicast SAs, covering a wider range of multicast technologies. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with destination address, and optionally the source address, to select an SA. If the receiver (unicast) or the multicast controller (multicast) opted to use the security protocol (ESP) in selecting the SPI, then the security protocol is also used in the lookup. To: o SPI -- modified to specify a uniform algorithm for SAD lookup for unicast and multicast SAs, covering a wider range of multicast technologies. For unicast, the SPI may be used alone to select an SA, or may be combined with the protocol, at the option of the receiver. For multicast SAs, the SPI is combined with the destination address, and optionally the source address, to select an SA. 7. Differences from RFC 2406, new bullet Added bullet (This is now the next to last bullet.) o Moved references to mandatory algorithms to a separate document. From owner-ipsec@lists.tislabs.com Fri Apr 4 19:29:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h353TjJM021027; Fri, 4 Apr 2003 19:29:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA14765 Fri, 4 Apr 2003 22:01:20 -0500 (EST) Message-Id: <200304050304.h3534k023033@sydney.East.Sun.COM> Date: Fri, 4 Apr 2003 22:04:46 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: IKEv2 cookie question To: ipsec@lists.tislabs.com, umeth@sparta.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5XjSj8ykHN4KjbDYr9s3NA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, you're right. The N(COOKIE_REQUIRED) would have no data associated with it, but that would always be accompanied by N(COOKIE). Now that you're making me explain it, it sounds sort of silly, though certainly not "broken". Here are some alteratives. Anyone care either way, or are we just making sure the spec is accurate at this point? a) assign COOKIE a notify type which is informational, and don't consider it an "error". b) Put the actual cookie inside the N(COOKIE_REQUIRED) payload (so Bob wouldn't actually send an N(COOKIE)). So instead it's really Bob saying, "Send me THIS cookie". Radia From: Uri Meth To: ipsec@lists.tislabs.com Subject: Re: IKEv2 cookie question Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i USMail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x233 Fax: (410) 381-5559 Based on the addition of the COOKIE_REUQIRED type, and there being 2 notification payloads in the responder message, I still would like to make sure I understand one last point - the contents of N(COOKIE_REQUIRED) (the notification payload of type COOKIE_REQUIRED). The Notification_Data field of this payload, will be empty as there is nothing more to pass except to let the initiator know that a cookie is required. The real information that will be necessary to extract from the message is the computed valued which is contained in the Notification_Data field of the N(COOKIE) payload. Is all this correct? Thanx UM On Thu, Apr 03, 2003 at 06:13:56PM -0500, Radia Perlman - Boston Center for Networking wrote: > Uri is correct. (good catch!) > > The reason for having both N(COOKIE_REQUIRED) and N(COOKIE) > is that IKEv2 has high numbers for type codes for notifies > for "just information" vs low numbers for type codes of > notifies for "errors". Since Alice also sends a COOKIE > in the next message, then that would argue for making > the cookie notification payload a "just information" type. > But since Bob is explaining why he's refusing the connection > attempt, it would argue for being an error type when Bob sends it. > > So the spec does it by having two payloads...one an error (COOKIE_REQUIRED), > and the other (COOKIE) passing the cookie. > > Certainly there are lots of perfectly reasonable ways of > doing this (for instance, just removing the N(COOKIE_REQUIRED) > and not having it look like an "error", or having two type > codes for COOKIE, depending on which direction the COOKIE is > travelling). Nothing really wrong with how Charlie chose to > do it, other than as Uri points out, the spec is inconsistent. > > So probably the easiest change is to add a low-number notification > type for COOKIE_REQUIRED, e.g., > > COOKIE_REQUIRED 12 > > IKE_SA_INIT rejected because no cookie was included. > > > >>Is there any way to fix the spec to clear up this ambiguity? > err...yeah...I believe it's not too late at this point. Thanks, again. > > Radia > > > > > From: Uri Meth > > > In the MSEC group, there has been a proposal to potentially add cookies > to the GSAKMP protocol. Since IKE had already dealt with this issue I > looked into how you did cookies. I am very intrigued by your use of > cookies, but in reading through the IKEv2 spec I have some questions. > Either I do not understand your syntax, something is missing, or there > is some mis-information. Please help me clarify what is happening. > > In Section 2.6 - Cookies , you give the disection for you message > structure > using cookies: > > Initiator Responder > ----------- ----------- > HDR(A,0), SAi1, KEi, Ni --> > > <-- HDR(A,0), N(COOKIE_REQUIRED), > N(COOKIE) > > HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> > > > From this message I interpret that the reponder sends the initiator a > message with two (2) notification payloads, cookie_required and cookie. > The initiator then rebuilds the initial message with the cookie received > from the responder in the notification cookie payload. > > However, in Section 3.10.1 - Notify Message Types, you only have a value > for COOKIE and not for COOKIE_REQUIRED. > > All this leads me to believe that what you really meant to say is that > the responder sends a message with one (1) notification payload > containing the Cookie value. The initiator takes this cookie value from > the notification payload and sends it back to the responder in the > rebuilt initial message. > > So which definition is correct? Is there any way to fix the spec to > clear up this ambiguity? Thanx > > UM > -- > Uri Meth (410) 872 - 1515 x233 (voice) > SPARTA, Inc. (410) 872 - 8079 (fax) > 7075 Samuel Morse Drive umeth@sparta.com > Columbia, MD 21046 > -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 From owner-ipsec@lists.tislabs.com Sat Apr 5 10:25:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35IOxJM027818; Sat, 5 Apr 2003 10:25:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16564 Sat, 5 Apr 2003 12:45:21 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 05 Apr 2003 09:49:32 -0800 Subject: Re: IKEv2 cookie question From: Scott Fanning To: Radia Perlman - Boston Center for Networking , , Message-ID: In-Reply-To: <200304050304.h3534k023033@sydney.East.Sun.COM> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 4/4/03 7:04 PM, "Radia Perlman - Boston Center for Networking" wrote: I would like the N(COOKIE_REQUIRED) to contain the "requested cookie". Notify messages without expectations embedded in it, makes me want to send the N(WHO_CARES) message. :-) Any clarification of the draft is important and will facilitate interoperability and adoption. Of course, endless revisions has its own issues. I strongly suggest that everyone take a good read of the latest draft, and present as many points (including any ambiguities) that may cause interop issues. Scott > Yes, you're right. The N(COOKIE_REQUIRED) would have > no data associated with it, but that would always > be accompanied by N(COOKIE). > > Now that you're making me explain it, it sounds sort > of silly, though certainly not "broken". Here are > some alteratives. Anyone care either way, or are we > just making sure the spec is accurate at this point? > > a) assign COOKIE a notify type which is informational, > and don't consider it an "error". > b) Put the actual cookie inside the N(COOKIE_REQUIRED) > payload (so Bob wouldn't actually send an N(COOKIE)). > So instead it's really Bob saying, "Send me THIS cookie". > > Radia > > > From: Uri Meth > To: ipsec@lists.tislabs.com > Subject: Re: IKEv2 cookie question > Mime-Version: 1.0 > Content-Disposition: inline > User-Agent: Mutt/1.2.5.1i > USMail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 > Phone: (410) 381-9400 x233 > Fax: (410) 381-5559 > > Based on the addition of the COOKIE_REUQIRED type, and there being 2 > notification payloads in the responder message, I still would like to > make sure I understand one last point - the contents of > N(COOKIE_REQUIRED) (the notification payload of type COOKIE_REQUIRED). > > The Notification_Data field of this payload, will be empty as there is > nothing more to pass except to let the initiator know that a cookie is > required. The real information that will be necessary to extract from > the message is the computed valued which is contained in the > Notification_Data field of the N(COOKIE) payload. > > Is all this correct? Thanx > > UM > > On Thu, Apr 03, 2003 at 06:13:56PM -0500, Radia Perlman - Boston Center > for Networking wrote: >> Uri is correct. (good catch!) >> >> The reason for having both N(COOKIE_REQUIRED) and N(COOKIE) >> is that IKEv2 has high numbers for type codes for notifies >> for "just information" vs low numbers for type codes of >> notifies for "errors". Since Alice also sends a COOKIE >> in the next message, then that would argue for making >> the cookie notification payload a "just information" type. >> But since Bob is explaining why he's refusing the connection >> attempt, it would argue for being an error type when Bob sends it. >> >> So the spec does it by having two payloads...one an error > (COOKIE_REQUIRED), >> and the other (COOKIE) passing the cookie. >> >> Certainly there are lots of perfectly reasonable ways of >> doing this (for instance, just removing the N(COOKIE_REQUIRED) >> and not having it look like an "error", or having two type >> codes for COOKIE, depending on which direction the COOKIE is >> travelling). Nothing really wrong with how Charlie chose to >> do it, other than as Uri points out, the spec is inconsistent. >> >> So probably the easiest change is to add a low-number notification >> type for COOKIE_REQUIRED, e.g., >> >> COOKIE_REQUIRED 12 >> >> IKE_SA_INIT rejected because no cookie was included. >> >> >>>> Is there any way to fix the spec to clear up this ambiguity? >> err...yeah...I believe it's not too late at this point. Thanks, again. >> >> Radia >> >> >> >> >> From: Uri Meth >> >> >> In the MSEC group, there has been a proposal to potentially add > cookies >> to the GSAKMP protocol. Since IKE had already dealt with this > issue I >> looked into how you did cookies. I am very intrigued by your > use of >> cookies, but in reading through the IKEv2 spec I have some > questions. >> Either I do not understand your syntax, something is missing, or > there >> is some mis-information. Please help me clarify what is > happening. >> >> In Section 2.6 - Cookies , you give the disection for you > message >> structure >> using cookies: >> >> Initiator Responder >> ----------- ----------- >> HDR(A,0), SAi1, KEi, Ni --> >> >> <-- HDR(A,0), > N(COOKIE_REQUIRED), >> N(COOKIE) >> >> HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> >> >> >> From this message I interpret that the reponder sends the > initiator a >> message with two (2) notification payloads, cookie_required and > cookie. >> The initiator then rebuilds the initial message with the cookie > received >> from the responder in the notification cookie payload. >> >> However, in Section 3.10.1 - Notify Message Types, you only have > a value >> for COOKIE and not for COOKIE_REQUIRED. >> >> All this leads me to believe that what you really meant to say > is that >> the responder sends a message with one (1) notification payload >> containing the Cookie value. The initiator takes this cookie > value from >> the notification payload and sends it back to the responder in > the >> rebuilt initial message. >> >> So which definition is correct? Is there any way to fix the > spec to >> clear up this ambiguity? Thanx >> >> UM >> -- >> Uri Meth (410) 872 - 1515 x233 > (voice) >> SPARTA, Inc. (410) 872 - 8079 (fax) >> 7075 Samuel Morse Drive umeth@sparta.com >> Columbia, MD 21046 >> > > -- > Uri Meth (410) 872 - 1515 x233 (voice) > SPARTA, Inc. (410) 872 - 8079 (fax) > 7075 Samuel Morse Drive umeth@sparta.com > Columbia, MD 21046 > > From owner-ipsec@lists.tislabs.com Sat Apr 5 12:25:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35KPgJM001401; Sat, 5 Apr 2003 12:25:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16800 Sat, 5 Apr 2003 14:51:57 -0500 (EST) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sat, 5 Apr 2003 11:56:03 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: IPsec WG cc: "Wijnen, Bert (Bert)" Subject: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550137C1F4@nl0006exch001u.nl.lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IPsec folks, I've been commissioned to do the MIB doctor review for but before I spend a lot of time discussing the details I'd like to ask a very basic (and I think very important) question. If I correctly understand what I have read, the main content of this draft is a set of enumerated INTEGER TCs that represent the values of fields in IPsec-related protocol messages. However, in many of these TCs (all, in fact, except for IsakmpCertificateEncoding) the DESCRIPTION clause (or the underlying reference document) has a statement to the effect that certain ranges of values are "reserved for private use amongst cooperating systems." Such values do not presently appear as named numbers in the enumeration list, and my understanding is that they will never appear in the enumeration list since they are not subject to assignment by the IANA. The WG needs to be aware that (according to RFC 2578 Section 7.1.1) the only values allowed for objects defined with these enumerated INTEGER TCs are the named numbers that are actually present in the enumeration list. Thus, managed objects defined with these TCs cannot represent values in the ranges that are reserved for private use amongst cooperating systems. If it is intended that objects defined using these TCs be able to represent arbitrary values of the corresponding parameters, including the "private use" values, then a SYNTAX value other than enumerated INTEGER will be required -- for instance, Unsigned32 with a subrange, as is used in the definition of IkePrf. Of course, in that case there would be no need to have the IANA maintain these TCs: they could be defined once, in a WG-maintained document, with the value list in a conventional assigned number registry. I ask the WG to carefully consider whether an IANA-maintained MIB module is really desirable in view of the above-described limitation of enumerated INTEGER TCs. It would be good to get an answer before we spend a lot of time discussing detailed review comments. Regards, Mike Heard From uCRwpfeQc@academ.com Sun Apr 6 06:10:21 2003 Received: from 218.72.250.62 ([218.72.250.62]) by above.proper.com (8.12.9/8.11.6) with SMTP id h36DAGJM005347 for ; Sun, 6 Apr 2003 06:10:18 -0700 (PDT) Date: Sun, 6 Apr 2003 06:10:16 -0700 (PDT) X-Spit: rnaTPcjri1r7PgW2C8ccUOr--1629098517 Received: from 250.248.226.203 (HELO morpheus.cybersurf.net) (250.248.226.203) by bcad.com with ESMTP id for ; Wed, 5 Mar 2003 02:03:11 -0600 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Message-Id: <2.4.4.1510755765.OoUuHoM7@mail.csga.ca> To: "ietf-ipsec@vpnc.org" From: "Winifred Scarlett" Subject: ietf-ipsec@vpnc.org Don't wait for results Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="==ENpLHDqWtlII" --==ENpLHDqWtlII Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 Cgo8aHRtbD4KPGhlYWQ+PC9oZWFkPgo8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIj4KPGJyPgo8 Y2VudGVyPgo8IS0tMjA1NDk3ODgwMC0tPjwhLS1MYlVHa0dySWg1ZmlKN2JSLS0+CjxjZW50 ZXI+PGEgaHJlZj0iaHR0cDovL2FkdWx0d2VicGFzc2hvc3Rpbmcub3JnL3h4eGRhdGUiPjxp bWcgYm9yZGVyPTAgYWx0PSIiIHNyYz0iaHR0cDovL3h4eGRpcmVjdHNleC5uZXQveHh4ZGF0 ZS9nZDEuZ2lmIj48L2E+PC9jZW50ZXI+CjwhLS05NjE2NjcwMi0tPjwhLS1jRVVrLS0+Cjwv Ym9keT48L2h0bWw+Cgo= --==ENpLHDqWtlII-- From owner-ipsec@lists.tislabs.com Sun Apr 6 08:54:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h36FsPJM012768; Sun, 6 Apr 2003 08:54:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18744 Sun, 6 Apr 2003 11:04:32 -0400 (EDT) Message-Id: <200304061508.h36F8qof034934@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: draft-dupont-ikev2-addrmgmt-02.txt Date: Sun, 06 Apr 2003 17:08:52 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've just submitted a new version of the address management proposal (with peer address notifications copied from NAT-T (no more merged) and a peer address update payload (no more a notification) copied from the last version of the delete payload), I removed all the NAT-T stuff too. The next step will be to clean up the address management proposal and to integrate everything at the exception of the peer address update payload itself in the next IKEv2 drafts (the spec and the tutorial). Regards Francis.Dupont@enst-bretagne.fr PS: of course any help shall be wellcome! From owner-ipsec@lists.tislabs.com Mon Apr 7 06:34:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37DYhJM002648; Mon, 7 Apr 2003 06:34:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21086 Mon, 7 Apr 2003 08:47:59 -0400 (EDT) Message-Id: <200304071110.HAA14969@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-sctp-05.txt Date: Mon, 07 Apr 2003 07:10:01 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : On the Use of SCTP with IPsec Author(s) : S. Bellovin et al. Filename : draft-ietf-ipsec-sctp-05.txt Pages : 0 Date : 2003-4-4 This document describes functional requirements for IPsec [RFC2401] and IKE [RFC2409] to facilitate their use for securing SCTP [RFC2960] traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sctp-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-sctp-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-sctp-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-4120513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-sctp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-sctp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-4120513.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Apr 7 07:28:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37ESPJM005229; Mon, 7 Apr 2003 07:28:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21248 Mon, 7 Apr 2003 09:58:41 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <20030403165248.A15033@charlie.columbia.sparta.com> Subject: Re: IKEv2 cookie question To: umeth@sparta.com Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sun, 6 Apr 2003 22:37:08 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/07/2003 10:01:56 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, the spec is clearly broken. Section 2.6 says to include N(COOKIE_REQUIRED) but no such notify payload is defined. As you point out, there is really no need for two payloads - one saying that a cookie was required and the other saying what the cookie was. This oddness was a side effect of moving the cookie out of the SPI and into a Notify payload. It seems like the easiest way to fix it is to remove all references to N(COOKIE_REQUIRED). I like it when you can fix a bug by removing things. Any objections? --Charlie > In Section 2.6 - Cookies , you give the disection for you message structure > using cookies: > > Initiator Responder > ----------- ----------- > HDR(A,0), SAi1, KEi, Ni --> > > <-- HDR(A,0), N(COOKIE_REQUIRED), > N(COOKIE) > > HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> > > > From this message I interpret that the reponder sends the initiator a > message with two (2) notification payloads, cookie_required and cookie. > The initiator then rebuilds the initial message with the cookie received > from the responder in the notification cookie payload. > > However, in Section 3.10.1 - Notify Message Types, you only have a value > for COOKIE and not for COOKIE_REQUIRED. > > All this leads me to believe that what you really meant to say is that > the responder sends a message with one (1) notification payload > containing the Cookie value. The initiator takes this cookie value from > the notification payload and sends it back to the responder in the > rebuilt initial message. > > So which definition is correct? Is there any way to fix the spec to > clear up this ambiguity? Thanx From owner-ipsec@lists.tislabs.com Mon Apr 7 10:56:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37Hu0JM023473; Mon, 7 Apr 2003 10:56:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21885 Mon, 7 Apr 2003 13:13:36 -0400 (EDT) Message-ID: <3E91B3DD.A96E4A@creeksidenet.com> Date: Mon, 07 Apr 2003 13:22:37 -0400 From: jeff pickering X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: ikev2: missing payload value for eap Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In drfat-06, section 3.16 is missing statement similar to "The payload type for the EAP payload is 17". Section 3.17 should also be updated to indicate 17 (or whatever is chosen) is no longer reserved. Jeff From owner-ipsec@lists.tislabs.com Mon Apr 7 11:17:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37IHJJM028234; Mon, 7 Apr 2003 11:17:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21988 Mon, 7 Apr 2003 13:44:02 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 7 Apr 2003 10:48:24 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: IPsec WG cc: "Wijnen, Bert (Bert)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt In-Reply-To: <3E9188E2.907@sockeye.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 5 Apr 2003, C. M. Heard wrote: % The WG needs to be aware that (according to RFC 2578 Section 7.1.1) % the only values allowed for objects defined with these enumerated % INTEGER TCs are the named numbers that are actually present in the % enumeration list. Thus, managed objects defined with these TCs % cannot represent values in the ranges that are reserved for private % use amongst cooperating systems. If it is intended that objects % defined using these TCs be able to represent arbitrary values of the % corresponding parameters, including the "private use" values, then a % SYNTAX value other than enumerated INTEGER will be required -- for % instance, Unsigned32 with a subrange, as is used in the definition % of IkePrf. Of course, in that case there would be no need to have % the IANA maintain these TCs: they could be defined once, in a % WG-maintained document, with the value list in a conventional % assigned number registry. On Mon, 7 Apr 2003, John Shriver replied: > Let me be sure that I understand your intent. Because RFC 2578 Section > 7.1.1 says that the only legal values of an enumeration are those in a > list, and there may be numbers in the list from the user-reserved space > that may not be in the list, we should abandon any effort to provide an > enumeration for any of these number spaces in any MIB for IPsec? > > Instead, they should all be range-limited INTEGERS[?] More probably, range-limited Unsigned32 (like IkePrf). But yes, that's the idea, if the managed objects defined with these TCs are supposed to be able to represent all possible values of the corresponding parameter. > [A]nd there is no attempt at having software convert small > positive integers into strings that might make sense to a human, > and instead people have to look it up by hand? An enumerated INTEGER TC does not do quite that much. All that can be done with the parseable information in such a TC is to build a table that converts the values in the enumeration list into the corresponding enumeration labels. You don't get any of the descriptive text that is present in the ASN.1 comments. To be weighed against this benefit is the cost to the IANA of having to maintain both a conventional registry and a MIB module for the majority of the IPsec-related assigned numbers. My past experience with stuff that requires two (or more) versions of the truth to be manually synchronized suggests to me that this cost will be rather high. Note that some of the TCs (XyzExchangeType and XyzNotifyType) require synchronized updates in more than two places. > This strikes me as a disservice to the real customers, which are the > users of any IPsec MIBs. (RFC 2578 is not a customer.) The entire > purpose of this MIB was to eliminate those manual lookups. In retrospect, it might have been better if the SMI had adopted the ASN.1 rule that enumerations only specified distinguished values, and that the underlying type was allowed to have all INTEGER values (well, all in the range -2147483648..2147483647, since the SMI restricts INTEGER to that range). But that wasn't what was decided, and the current rule is the one we have to live with. > I was thinking that a customer using these MIBs who had a product using > a proprietary value would simply EDIT their copy of this MIB to include > the offending value. There's no "do not edit under penalty of law" tag > on the MIB. Although not sanctioned by the SMI, a customer could indeed perform such edits. However, they would have to be re-applied whenever the "official" version was updated with a new registered value, which is clearly undesirable. I think such edits should be discouraged. > Rather than abandon the enumerations, I would instead propose to reserve > one value in each and every enumeration, which would represent all > values which are "undefined" within the enumeration. The numeric value > of it would be 65536, which is out of the real protocol range for all > the numbers. > > Then MIB authors who need to reveal the user-reserved values can have a > second variable that reveals the raw INTEGER number. (What fun! But > I'm not writing that MIB.) That will work, since all of the items that have "private use" ranges don't include 65536 as a legitimate value. Again, however, the question must be asked whether the automatic generation of integer-to-enum-label tables is worth the cost of using two objects to represent one value. > Or, I can edit the MIB to give every enumeration a tag for every > reserved value. Like on IpsecDoiSecProtocolId, add privateUse249(249), > privateUse250(250), privateUse251(251), etc. But I can assure you that > many of the management agents out there would crash in flames if we do > that. In my experience, they are exceptionally fragile... I agree that this would not be a good idea, especially for the ones that have private use ranges of 61440-65535, 65001..65535, or 32768..65535. Frankly, I think that the benefits from the enum labels are not worth the costs in this application. The costs include both the burden on the IANA of having to maintain synchronized registries and the need to have extra MIB objects to represent the "private use" values. I think it would be better to use subranged Unsigned32 TCs in a WG-maintained MIB module, with the DESCRIPTION and REFERENCE clauses of those TCs pointing to the authoritative sources for the number assignments (namely the defining RFCs and the IANA registries). However, my role in this matter strictly advisory, and the decision is ultimately up to the IPsec WG (subject of course to IESG and IANA approval). Regards, Mike Heard From owner-ipsec@lists.tislabs.com Mon Apr 7 14:05:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37L5dJM010148; Mon, 7 Apr 2003 14:05:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22377 Mon, 7 Apr 2003 16:27:01 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Mon, 7 Apr 2003 16:30:48 -0400 To: Barbara Fraser , "Theodore Ts'o" From: Karen Seo Subject: RESEND -- new versions of IPsec AH and ESP specs Cc: ipsec@lists.tislabs.com, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, The IETF server/virus screen rejected the files, apparently because they were BINHEX'd. I've submitted them that way before, so I'm not sure what's changed. At any rate, I've re-submitted them encoded a different way. In doing so, I discovered I hadn't incremented the file version. So the correct drafts should be: - draft-ietf-ipsec-rfc2402bis-03.txt - draft-ietf-ipsec-esp-v3-05.txt Apologies for any confusion/delay, Karen From owner-ipsec@lists.tislabs.com Mon Apr 7 14:39:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37LdNJM015937; Mon, 7 Apr 2003 14:39:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22429 Mon, 7 Apr 2003 17:03:03 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 7 Apr 2003 14:06:37 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: IPsec WG cc: "Wijnen, Bert (Bert)" , IANA Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt In-Reply-To: <3E91CB29.4030706@sockeye.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ iana@iana.org included on the cc: list because this ] [ message discusses IANA considerations in the draft. ] On Mon, 7 Apr 2003, John Shriver wrote: > I would hope that the IANA would never try and keep two files > synchronized. As the I-D states, the itent was that the MIB would > become THE definitive document. If that is what is intended, then it needs to be clearly spelled out in the IANA Considerations section. In particular, it needs to be stated that the IANA-maintained MIB module will replace portions of the IANA ISAKMP Identifiers registry and the IANA IKE Attributes registry (see http://www.iana.org/assignments/isakmp-registry and http://www.iana.org/assignments/ipsec-registry respectively), and detailed instructions on how to do this re-organization must be provided. The only statement to this effect that is now present is in the second paragraph of the abstract: The MIB documented by this document will become a separate living document maintained by the IANA, and will be the document of record for these assignments. and I mis-interpreted this. I thought it was referring to the fact that the IANA-maintained MIB module (and not the RFC-to-be) would be definitive. BTW, the reason I said "portions of" the registries is that the following items in the IANA ISAKMP Identifiers registry don't have any counterpart in the proposed MIB module: IPSEC Security Association Attribute Class SA Life Type Group Description Key Length Key Rounds ECN Tunnel IPSEC Labeled Domain Identifier Likewise, the following attributes in the IANA IKE Attributes registry don't have any counterpart in the proposed MIB module: Attribute Class Life Type Key Length Field Size Group Order Some things would have to be added to the MIB module in order for it to replace the existing registries outright. > This is certainly what has happened with the ifType MIB, > although that was MIB-centric. Actually, it turns out that ifType values are listed both in the SMI Numbers registry and in the IANAifType-MIB. I believe, however, that this postdates the existence of the IANAifType-MIB: versions of the now-discontinued "Assigned Numbers" RFC that preceded the first version of the IANAifType-MIB in RFC 1573 did not list the ifType assignments. As far as I am aware, there was no IANA ifType registry before RFC 1573. > All programmers know that source-file synchronization is evil. Yes, I agree with that. Mike Heard From owner-ipsec@lists.tislabs.com Mon Apr 7 22:09:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3859UJM018789; Mon, 7 Apr 2003 22:09:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA23670 Tue, 8 Apr 2003 00:31:42 -0400 (EDT) Date: Tue, 8 Apr 2003 07:35:17 +0300 (IDT) From: Hugo Krawczyk To: Charlie_Kaufman@notesdev.ibm.com cc: IPsec WG Subject: Re: draft-ietf-ipsec-ikev2-06.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie, This note refers to the following request of yours: > > I have incorporated some of the -05 comments where I thought they would be > noncontroversial. People who submitted them SHOULD look at the new draft > and see whether I addressed their concerns adequately. I will continue to > go through those comments, but it wouldn't hurt if people whose comments > are not yet addressed forward a copy of them to me to make sure I don't > miss them. > I have seen that you took care of most of my latest comments -- thanks for that. There are a few that were not done even though you expressed in the list your intention to do them; I suppose these fall under the category of yet to be done. However, since some of these changes do modify the bits in the wire I wanted to make sure that you really intend to do them before it is too late (If for some reason you changed your mind please let us know). Here is a list of pending changes (and a couple that I spotted reading 06) (1) ERASE g^ir as an argument to prf+ in the two places this appears now: in section 2.14 (4th line of page 27) and section 2.17 (line 11 of page 29). As we discussed earlier, g^ir should be used solely for the derivation of SKEYSEED (for either IKE_SA or CHILD_SA) and need not be re-used in the derivation of KEYMAT. Doing the latter has no practical advantage while having the theoretical disadvantage of spoiling a proof of security of the key derivation based on general pseudo-random functions. Referring to this issue you said in your note from 3/6: > Actually, this change was made between -03 and -04. I have only a vague > recollection as to why. I remember a discussion on the list in early > December, but don't remember who the advocates for the change were and > can't find it now. I'm tempted to change it back based on Hugo's objection, > but would hate to have someone else who doesn't notice this note object in > -07. Would anyone care to express an opinion? I think everyone agrees that > the change has no practical impact on security either way. There were no objections on the list since you posted this so it seems that you can go forward with this (if not please explain why). Just to avoid any confusion: g^ir MUST be kept as an argument to prf (not prf+) in the computation of SKEYSEED (sections 2.14 and 2.18). (2) Issue of key length for the prf: Make sure that the users of ikev2 provide enough bits to key the prf. This is very simple and requires only the following two editorial changes: a- specify that the nonces (Ni and Nr) must be at least of half the length of the key for the negotiated prf (since Alice sends this value before she knows which prf is chosen by Bob, then she should send a nonce which is of length half the longest prf key that she includes in her offer). Note: since you already require the nonces to include at least 128 random bits then the above length requirement will usually not result in an actual increase of the length of the nonces. Also specify that if a nonce is longer than half the (maximal) length of the key accepted by the prf then for creating the key Ni|Nr (used in deriving SKEYSEED for the IKE_SA) only the least significant bytes of that nonce are used in this concatenation. b- specify that when pre-sharing a key for use in prf-based authentication (i.e., Shared Secret") this key SHOULD of the length of the key for the prf agreed for use by the parties. Note: here I would have preferred to say MUST instead of SHOULD, but I know that you want to allow the use of passwords in this mode. If you intended to do the above changes any way then you can ignore the following explanation; if not please read. Currently you have found a seemingly more "elegant" solution to the prf key length issue, namely, the following text in page 25 of ikev2-06: We assume that the prf function takes a variable length key and produces a fixed length output. When the key for the prf function has fixed length, its specification for use in IKEv2 must include a procedure for deriving its required fixed length key from a variable length key. This may be short and elegant but it actually creates a big problem for who wants to use non-HMAC prfs, in particular AES. Indeed, AES takes fixed keys only and it has no built-in mechanism to handle variable-length keys. Designing such a mechanism is a very non-trivial problem (as those subscribed to the cfrg list have witnessed recently). Therefore, your text above while seemingly simplifying the IKE specification actually requires to standarize something (variable key support for AES or general block ciphers) that can take long to get right technically and even longer to get ietf consensus. In contrast, the spedifications on the length of nonces and preshared key, suggested above, are simple to state, and transform the variable key headache into a non-issue. (3) The specification of AUTH in the case of prf-based authentication (pre-shared mode). On March 18 you wrote in a message to the list: > This is also related to prf functions with fixed length keys. I had > proposed that the AUTH payload be computed as: > > AUTH = prf(Shared Secret | "Key Pad for IKEv2", ) > > which won't work if the prf has a fixed size key. Hugo proposed the > alternative encoding: > > AuthSecret = prf( prf(Shared Secret, "Key Pad for IKEv2") , ) > > and using that encoding whether or not the prf takes a fixed size key > (presumably with Shared Secret padded or truncated as necessary to match > the fixed key size). > > I'm happy with that. Any objections? There were no objections on the list so I guess that the current text in draft 06 AUTH = prf(Shared Secret | "Key Pad for IKEv2", ) is a leftover from previous draft and will be changed to the above nested construct. (BTW, the above use of "AuthSecret" is a typo, it should be replaced with "AUTH"). Note that the above construct achieves your intention of avoiding the need to store passwords at the authentication server, as it allows the server (or gateway) to only store the result of the inner prf. The current specification (in 06) achieves the same but ONLY for HMAC. For AES (or other block ciphers) it puts you back into the "variable-length key issue". Moreover, having the key padded with "Key Pad for IKEv2" unnecessarily forces a weakening of the prf key (this is avoided by having this pad as the input to the prf. One last nit on this: the inner prf should be prf+ for the cases in which the output of the prf is shorter than the key (as with 3DES). Now to purely editorial issues in 06: (4) It seems to me that you should switch the order between sections 2.17 and 2.18. The reason is that the key derivation for CHILD_SAs (currently defined in 2.17) is dependent, in the case of CHILD_SAs created through re-keying, on keys (SK_d) derived during rekey and specified in 2.18. (5) Page 39: at the end of the paragraph o Message ID (4 octets) - Message identifier used to control retransmission of lost packets and matching of requests and responses. It is essential to the security of the protocol because it is used to prevent message replay attacks. add "during the establishment of CHILD_SA's." Also, while I am glad that you added this text clarifying the role of message id's against replay attacks, it seems to me that it does not belong here (where it is hidden among payload format definitions) but rather in section 2.2 (or even the security considerations if you prefer) Thanks for your attention... Hugo From owner-ipsec@lists.tislabs.com Tue Apr 8 03:26:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38AQDJM002029; Tue, 8 Apr 2003 03:26:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA24319 Tue, 8 Apr 2003 05:53:04 -0400 (EDT) Message-Id: <5.1.0.14.0.20030408150612.0256cec0@172.16.1.10> X-Sender: lokeshnb@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 08 Apr 2003 15:24:33 +0530 To: ipsec@lists.tislabs.com From: Lokesh Subject: Question on SA Bundle Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I have a question on Ipsec. SA's are bundled in SABundle. and there can be multiple SA Bundles existing linked together in a SPD entry. 1] under what conditions it is decided that a new SA created should be bundled in a New SABundle? not in a existing one? can anyone point me to literature on this or similar issue ? ( that is regarding SPD and SA Bundles) Thanks Lokesh From owner-ipsec@lists.tislabs.com Tue Apr 8 11:38:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38IbvJM007799; Tue, 8 Apr 2003 11:38:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25634 Tue, 8 Apr 2003 13:48:26 -0400 (EDT) Message-Id: <4.3.2.7.1.20030408104136.022cace0@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Apr 2003 10:53:37 -0700 To: Lokesh , ipsec@lists.tislabs.com From: Ramana Yarlagadda Subject: Re: Question on SA Bundle In-Reply-To: <5.1.0.14.0.20030408150612.0256cec0@172.16.1.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Lokesh At 03:24 PM 4/8/03 +0530, Lokesh wrote: >Hi all, >I have a question on Ipsec. >SA's are bundled in SABundle. and there can be multiple SA Bundles >existing linked together >in a SPD entry. > >1] under what conditions it is decided that a new SA created should be >bundled in a New SABundle? not in a existing one? The SA is negotiated (created) in two events: 1) where an SA doesn't exist for a flow, New SA. 2) the second case is because of an SA expiry timer. The first case is a simple case and there shouldn't be any issues with this. But in second case you might run into som problems like whether you should hold-on or delete the old SA ? And which one to use in case of IPSec processing. And for more information about this refer to rekeying isses draft. >can anyone point me to literature on this or similar issue ? ( that is >regarding SPD and SA Bundles) -cheers -ramana From owner-ipsec@lists.tislabs.com Tue Apr 8 13:35:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38KZaJM016073; Tue, 8 Apr 2003 13:35:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26173 Tue, 8 Apr 2003 16:02:50 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 8 Apr 2003 13:07:18 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: IPsec WG cc: "Wijnen, Bert (Bert)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt In-Reply-To: <3E91CB29.4030706@sockeye.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk John Shriver wrote: > C. M. Heard wrote: > John Shriver wrote: > > > Let me be sure that I understand your intent. Because RFC 2578 > > > Section 7.1.1 says that the only legal values of an enumeration > > > are those in a list, and there may be numbers in the list from > > > the user-reserved space that may not be in the list, we should > > > abandon any effort to provide an enumeration for any of these > > > number spaces in any MIB for IPsec? > > > > > > Instead, they should all be range-limited INTEGERS[?] [ ... ] > > > This strikes me as a disservice to the real customers, which are > > > the users of any IPsec MIBs. (RFC 2578 is not a customer.) The > > > entire purpose of this MIB was to eliminate those manual lookups. > > > > In retrospect, it might have been better if the SMI had adopted the > > ASN.1 rule that enumerations only specified distinguished values, > > and that the underlying type was allowed to have all INTEGER values > > (well, all in the range -2147483648..2147483647, since the SMI > > restricts INTEGER to that range). But that wasn't what was decided, > > and the current rule is the one we have to live with. [ ... ] > We discussed the "standards fudge" issue of the non-enumerated values > back [when this project was started], and people on the IPsec list > weren't offended by the problem. A common-sense standards bending > didn't bother them. The problem with bending the rules in this way is that it is confounds expectations that people have (based on what is in the standard) regarding what enumerated INTEGERs mean. I put this question to the other MIB Doctors and got these answers: On Mon, 7 Apr 2003, Randy Presuhn wrote: % What bothers me about this proposal is not so much the notion of % extending enumerations without adjusting the documentation, but % rather the semantic ambigiuities that will result due to the lack % of coordination of the enumeration assignments. For this kind of % un-coordinated private use, OBJECT IDENTIFIERs are really the way % to go. Otherwise, one has no way of knowing whether agent A's 42 % means the same thing as agent (or manager) B's. On Mon, 7 Apr 2003, Andy Bierman wrote: % I agree with Randy. If they are leaving enum values unspecified % so vendors can assign their own value, then this is a misuse of % enumerated INTEGER. If enums are really the appropriate data type, % and they know now that they want specific values defined, then % all enum values should be listed and documented. What the Randy's and Andy's comments are saying is that enumerated INTEGERs are the wrong data type for this application not because of an obscure technical violation of RFC 2578 but because this usage violates the semantics that are expected of enumerated INTEGERs. I tend to agree with that, and that's why I have suggested subranged Unsigned32 would be a more appropriate choice. > I don't have time to dig the archives... I looked in the ipsec archives back to 1998 and was not able to find any discussion of this specific issue (it is entirely possible that I missed something, in which case a pointer would be helpful). Thanks, Mike Heard From owner-ipsec@lists.tislabs.com Tue Apr 8 13:56:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38KuRJM016823; Tue, 8 Apr 2003 13:56:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26291 Tue, 8 Apr 2003 16:29:06 -0400 (EDT) To: housley@vigilsec.com, smb@research.att.com cc: byfraser@cisco.com, ipsec@lists.tislabs.com, ietf-secretariat@ietf.org Subject: Ready for IETF last call: draft-ietf-ipsec-ciph-aes-ctr-03.txt From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 08 Apr 2003 16:32:44 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Russ, Steve, The I-D draft-ietf-ipsec-ciph-aes-ctr-03.txt has been through working group last call, and with no comments against it, it is ready to go to IETF last call and for consideration by the IESG for Proposed Standard. Could you please start the process on this? Many thanks!! - Ted From owner-ipsec@lists.tislabs.com Tue Apr 8 13:56:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38KukJM016844; Tue, 8 Apr 2003 13:56:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26318 Tue, 8 Apr 2003 16:32:10 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Theodore Ts'o" Cc: housley@vigilsec.com, byfraser@cisco.com, ipsec@lists.tislabs.com, ietf-secretariat@ietf.org Subject: Re: Ready for IETF last call: draft-ietf-ipsec-ciph-aes-ctr-03.txt In-Reply-To: Your message of "Tue, 08 Apr 2003 16:32:44 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Apr 2003 16:35:47 -0400 Message-Id: <20030408203547.5CB007B4D@berkshire.research.att.com> X-Spam-Status: No, hits=-125.8 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_IN_WHITELIST autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , "Theodore Ts'o" writes: >Hi Russ, Steve, > > The I-D draft-ietf-ipsec-ciph-aes-ctr-03.txt has been through >working group last call, and with no comments against it, it is ready to >go to IETF last call and for consideration by the IESG for Proposed >Standard. > > Could you please start the process on this? Many thanks!! > > - Ted > Thanks. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) From owner-ipsec@lists.tislabs.com Tue Apr 8 14:02:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38L2bJM017053; Tue, 8 Apr 2003 14:02:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26340 Tue, 8 Apr 2003 16:36:09 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: WG LAST CALL: draft-ietf-ipsec-ciph-aes-ccm-02.txt From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 08 Apr 2003 16:34:19 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a working group last call for comments for the ipsec-ciph-aes-ccm internet draft, for progression to Proposed Standard. This last call will expire on April 15th. - Ted and Barbara From owner-ipsec@lists.tislabs.com Tue Apr 8 14:08:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38L8OJM017201; Tue, 8 Apr 2003 14:08:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26372 Tue, 8 Apr 2003 16:41:19 -0400 (EDT) To: Radia Perlman - Boston Center for Networking Cc: ipsec@lists.tislabs.com, umeth@sparta.com From: Derek Atkins Subject: Re: IKEv2 cookie question References: <200304050304.h3534k023033@sydney.East.Sun.COM> Date: 08 Apr 2003 16:44:37 -0400 In-Reply-To: <200304050304.h3534k023033@sydney.East.Sun.COM> Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia Perlman - Boston Center for Networking writes: > b) Put the actual cookie inside the N(COOKIE_REQUIRED) > payload (so Bob wouldn't actually send an N(COOKIE)). > So instead it's really Bob saying, "Send me THIS cookie". I like this idea. It's clear, consise, and unambiguous. > Radia -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Tue Apr 8 16:25:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38NP4JM024024; Tue, 8 Apr 2003 16:25:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA26830 Tue, 8 Apr 2003 18:56:57 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 8 Apr 2003 16:00:56 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: IPsec WG cc: "Wijnen, Bert (Bert)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt In-Reply-To: <3E933772.9080801@sockeye.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 8 Apr 2003, John Shriver wrote: > A more straightforward description is that I tried to forge a compromise > between multiple design goals: > > 1. Easy to [implement] on the product without pain. (This is why I > export exactly what the protocol negotiated, no remapping to any other > space). Subranged INTEGER/Integer32/Unsigned32 can accomplish this. > 2. Easy to use, in that the normally used values are displayed as an > enumeration, even on commonly available free SNMP implementations. Subranged INTEGER/Integer32/Unsigned32 cannot accomplish this. > 3. Avoid the never reaches full standard problem by having the TC MIB > managed by the IANA. Subranged INTEGER/Integer32/Unsigned32 can accomplish this. > I will warn that the IPsec implementors in this working group are VERY > harsh about any MIB proposals that intrude deeply into performance. > There have been very contentious discussions. They really aren't very > interested in SNMP in the first place, which is obvious by the very > minimal feedback all discussions of the MIBs have produced. They won't > bend very far to implement a MIB. > > An approach that doesn't meet goal 1 won't get implemented. Fair enough. > If strict RFC 2578 conformance is the only way that IPsec MIBs can be > published, I can assure you that goal 2 will be dropped in favor of goal > 1. Having to map every sort of protocol number into a Object Identifier > (Andy's approach) is going to be quite unpopular, even if approved by > the working group, I doubt it would get the "implement it" vote. Well, here is the advice from another MIB Doctor: On Tue, 8 Apr 2003, David T. Perkins wrote: % Sometimes it is not appropriate or worth the cost of putting things % in a MIB module that work better as information that augments the % MIB module. In this case, I would define the object type with % data type "Unsigned32", and specify in the DESCRIPTION clause % the semantics of the ranges. In the REFERENCE clause, I would % put the information (and if available, a URL) so that some one % could track down the current assignments. % % That's my $.02 worth of advice. % % PS Hint: See the definition of TC SnmpSecurityModel. That is essentially what I suggested earlier. If you care to look, SnmpSecurityModel is defined in the SNMP-FRAMEWORK-MIB, which in turn is part of RFC 3411 (ftp://ftp.isi.edu/in-notes/rfc3411.txt). It's the model I had in mind. I don't think that a shift to this approach would have much (if any) impact on the MIB modules that use the TCs defined in . It would comply with the SMI, and it would avoid the need to supplement/change the IPsec-related IANA registries. And you could include the titles and URLs of those registries in the relevant TC DESCRIPTION clauses. As I said before, I don't have the power (nor do I wish) to force you to do anything ... I only give advice. But, that's my advice. Thanks, Mike P.S. I can certainly sympathize with your being unhappy at having this suggestion arrive so late in the process ... your first I-D, if I correctly understood what I saw in the IPsec mailing list archives, appeared in February 1999. I can only apologize and say that you have a legitimate complaint about that. -- cmh From owner-ipsec@lists.tislabs.com Tue Apr 8 16:25:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38NPHJM024070; Tue, 8 Apr 2003 16:25:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA26815 Tue, 8 Apr 2003 18:52:56 -0400 (EDT) Date: Wed, 9 Apr 2003 01:56:47 +0300 (IDT) From: Hugo Krawczyk To: IPsec WG Subject: RE: Do ipsec vendors care about privacy? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Someone asked me (off list) why i did not include the issue of protecting the user's identity (in the remote access scenario) in my list of yet-to-be done issues that I sent earlier to Charlie. I have two answers: (1) I only included in that list issues that were previously discussed and we reached agreement (or close to agreement) with Charlie. Identity protection for the user (initiator) in the EAP exchange was never agreed by Charlie (he only said that he felt "genuinely conflicted about this one"). (2) From the latest thread on this issue (under the above subject) it was clear that very few explicitly supported doing the changes required to provide user identity in the case of remote access, even though the cost of these changes was very moderate (*) and affected only the EAP exchange of ikev2 (without any modification required to the normal authentication modes). While this result disappoints me it seems to clearly reflect the desire of this WG (as much as any discussion in this list can reflect such virtual desire). And since I directed this thread particularly to ipsec vendors I guess this outcome of the discussion is acceptable to them (several of these vendors said that user's identity protection in the remote access scenario is important to them, but no one really said it was important enough to justify even the small complexity these changes required). Hugo *) about moderate cost: we had two main solutions (that only changed the EAP exchange of ikev2) - leave everything as now and move IDi to message 5. Here the cost is an added round trip since the responder will not have the user's identity until message 5. - move the responder's authentication to message 2. Here the cost is the loss of the "You Tarzan, Me Jane" functionality, some increased implementation complexity (by deviating from the order of authentication in the main ikev2 protocol, and by requiring a signature on parts -rather than all- of message 2). It has also been argued that this ordering increases the exposure to DoS attacks (due to the signature performed by R in message 2); this does not convince me especially that in the current protocol one can already mount serious DoS attacks against an ike server, especially via DDoS (which is the "preferred" form for attackers to avoid traceability -- and against which even the anti-DoS cookie has very limited effect). In other words, the added signature computation makes DoS attack not significantly more attractive or effective than they already are (note also that state creation and expensive DH computation are already forced in the protocol on the responder before it authenticates the initiator). From owner-ipsec@lists.tislabs.com Wed Apr 9 03:41:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39AfqJM015482; Wed, 9 Apr 2003 03:41:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA28267 Wed, 9 Apr 2003 06:08:06 -0400 (EDT) Message-ID: <3E93F27F.1010403@cefriel.it> Date: Wed, 09 Apr 2003 12:14:23 +0200 From: Antonio Forzieri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Do ipsec vendors care about privacy? References: In-Reply-To: X-Enigmail-Version: 0.74.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2003 10:13:55.0120 (UTC) FILETIME=[BA180300:01C2FE80] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk wrote: [SNIP] > While this result disappoints me it seems to clearly reflect the desire of > this WG (as much as any discussion in this list can reflect such virtual > desire). And since I directed this thread particularly to ipsec vendors I > guess this outcome of the discussion is acceptable to them (several of > these vendors said that user's identity protection in the remote access > scenario is important to them, but no one really said it was important > enough to justify even the small complexity these changes required). > Hugo It disappoints me too. I think that we have to ask to ourselves what price we can pay to obtain IDi protection. > *) about moderate cost: we had two main solutions (that only changed the > EAP exchange of ikev2) > > - leave everything as now and move IDi to message 5. > Here the cost is an added round trip since the responder will > not have the user's identity until message 5. This solution makes IKEv2 handshake 4RTT long (IKEv1 was 4,5RTT long with MM and 3RTT long with AM), even if with some trick (EAPC) we can make it 3RTT long when using some EAP methods (MD5 and GTC). From IKEv2 draft (Appendix A): 4) To decrease IKE's latency in the common case... Is 1RTT a good price for IDi protection? > - move the responder's authentication to message 2. > Here the cost is the loss of the "You Tarzan, Me Jane" functionality, > some increased implementation complexity (by deviating from the order > of authentication in the main ikev2 protocol, and by requiring a signature > on parts -rather than all- of message 2). This is a general solution for the problem, however it changes IKEv2 much more. The idea of moving IDr and AUTH payload to message 2, which didn't convice me in the past, may be is better than the first solution. What I have in mind (and maybe what Hugo has in mind) is something like this: Jane Tarzan -------- ---------- HDR, SAi1, KEi, Ni, IDr, --> ^^^ ||| "You tarzan" <-- HDR, SAr1, KEr, Nr, IDr, [CERT,] [CERTREQ,] PREAUTH PREAUTH = SIG{R}(KEr) PREAUTH = HMAC(PSS,KEr) HDR, SK {IDi, EAPC, SAi2, TSi, TSr} --> <-- HDR, SK {EAP} HDR, SK {EAP, [COMP_AUTH], CP(CFG_REQUEST)} --> <-- HDR, SK {EAP, [COMP_AUTH], AUTH, CP(CFG_REPLY) SAr2, TSi, TSr} > It has also been argued that > this ordering increases the exposure to DoS attacks (due to the signature > performed by R in message 2); this does not convince me especially that > in the current protocol one can already mount serious DoS attacks > against an ike server, especially via DDoS (which is the "preferred" > form for attackers to avoid traceability -- and against which even > the anti-DoS cookie has very limited effect). In other words, > the added signature computation makes DoS attack not significantly more > attractive or effective than they already are (note also that state > creation and expensive DH computation are already forced in the protocol > on the responder before it authenticates the initiator). Agreed. As JFKi proposed in the past we can use a FIFO queue in which we put PREAUTH, and we can generate a PREAUTH i.e. each 30s. This should be useful expecially with digital signatures, while with PSS i guess that it can be done also "on-the-fly" (HMAC). I agree with Hugo that these changes doesn't open IKEv2 to DoS attack more than IKEv2 already is; this mainly because the responder has to calculate SKEYSEED and {SK_d, SK_ai, SK_ar, SK_ei, SK_er} before it authenticates the initiator, so an attacker can mount a DDoS - Memory/CPU Exhaustion -. But... Is this a good price for IDi protection? -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ------------------------------------------------ From owner-ipsec@lists.tislabs.com Wed Apr 9 06:53:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39DrXJM026599; Wed, 9 Apr 2003 06:53:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28682 Wed, 9 Apr 2003 09:21:32 -0400 (EDT) Message-Id: <200304091118.HAA21707@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-v3-05.txt Date: Wed, 09 Apr 2003 07:18:24 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent Filename : draft-ietf-ipsec-esp-v3-05.txt Pages : 42 Date : 2003-4-8 This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and Ipv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document is based upon RFC 2406 (November 1998). Section 7 provides a brief review of the differences between this document and RFC 2406. Comments should be sent to Stephen Kent (kent@bbn.com). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-v3-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-v3-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-8141923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v3-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v3-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-8141923.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Apr 9 06:53:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39DrcJM026611; Wed, 9 Apr 2003 06:53:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28678 Wed, 9 Apr 2003 09:21:27 -0400 (EDT) Message-Id: <200304091118.HAA21691@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-rfc2402bis-03.txt Date: Wed, 09 Apr 2003 07:18:19 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Authentication Header Author(s) : S. Kent Filename : draft-ietf-ipsec-rfc2402bis-03.txt Pages : 31 Date : 2003-4-8 This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document is based upon RFC 2402 (November 1998) [KA98c]. Section 7 provides a brief review of the differences between this document and RFC 2402. Comments should be sent to Stephen Kent (kent@bbn.com). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-rfc2402bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-8141913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2402bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-8141913.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Apr 9 06:54:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39Ds0JM026636; Wed, 9 Apr 2003 06:54:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28727 Wed, 9 Apr 2003 09:25:32 -0400 (EDT) Message-ID: <20030408085244.38057.qmail@web21408.mail.yahoo.com> Date: Tue, 8 Apr 2003 01:52:44 -0700 (PDT) From: "S. Shankar" Subject: whether IKE v1 (RFC2409) supports negotiation of unidirectional policy selectors To: dharkins@cisco.com Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have a querry regarding the 'meaning of unidirectional policy/SA' and IKE capability to negotiate such policies . suppose the setup is like this :- Net1======SG1 ------------ SG2 ========Net2 IKE deamon is running at SG1 and SG2. Does the Property of an SA being Uni-Directional allows the existence of the following scenarios (A) Inbound and outbound ipsec policies where SA protocols and algorithm attributes are different in each direction Policy Database: Peer 1 Peer2 Inbound ESP Tunnel(3DES) AH Tunnel(HMAC-MD5) Outbound AH Tunnel(HMAC-MD5) ESP Tunnel(3DES) Thus no matter who initiates a connection, whenever Peer1 sends data to Peer2, AH Tunnel mode will be used and when Peer 2 sends data to Peer 1, ESP Tunnel mode will be used. Also if IKE is used for SA exchange, 4 SAs will be created at each Peer, two for AH Tunnel mode and two for ESP Tunnel Mode. Please correct me if I am wrong. (B) Inbound and outbound policies are different where only in outbound direction ipsec is applied and inbound direction the packets are allowed in plain text ? Can IKE negtiate such unidirectional policies so that only outbound SA as are setup at SG1? Is there any linkage between IKE role (INITIATOR /Responder) and policy direction ? regards sanjay __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com From owner-ipsec@lists.tislabs.com Wed Apr 9 06:54:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39DsKJM026659; Wed, 9 Apr 2003 06:54:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28681 Wed, 9 Apr 2003 09:21:28 -0400 (EDT) Message-Id: <200304091118.HAA21726@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-sctp-06.txt Date: Wed, 09 Apr 2003 07:18:29 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : On the Use of SCTP with IPsec Author(s) : S. Bellovin et al. Filename : draft-ietf-ipsec-sctp-06.txt Pages : 0 Date : 2003-4-8 This document describes functional requirements for IPsec [RFC2401] and IKE [RFC2409] to facilitate their use for securing SCTP [RFC2960] traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sctp-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-sctp-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-sctp-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-8141933.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-sctp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-sctp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-8141933.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Apr 9 06:54:31 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39DsUJM026677; Wed, 9 Apr 2003 06:54:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28664 Wed, 9 Apr 2003 09:20:26 -0400 (EDT) Message-ID: <3E939F0E.9010306@roc.co.in> Date: Wed, 09 Apr 2003 09:48:22 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lokesh CC: ipsec@lists.tislabs.com Subject: Re: Question on SA Bundle References: <5.1.0.14.0.20030408150612.0256cec0@172.16.1.10> Content-Type: multipart/alternative; boundary="------------010104080207090200030604" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------010104080207090200030604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi , I don't think there is public literature on this other than IPSEC architecture document. Note that, SPD defines the security protocols such as ESP, AH. In a given SPD policy, you can have both ESP and AH together. This results into two SAs. Typically, IPSEC informs IKE to get the keys for both of them together. once IKE gets the keys, it can inform IPSEC packet processing to create the SA bundle with two SAs. Since, IKE negotiates both together, if one SA life time expires, other SAs in the SA Bundle can be removed. That means either all SAs in the SA bundle exist or none exist -Ravi Lokesh wrote: > Hi all, > I have a question on Ipsec. > SA's are bundled in SABundle. and there can be multiple SA Bundles > existing linked together > in a SPD entry. > > 1] under what conditions it is decided that a new SA created should > be bundled in a New SABundle? not in a existing one? > > can anyone point me to literature on this or similar issue ? ( that is > regarding SPD and SA Bundles) > Thanks > Lokesh > > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------010104080207090200030604 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi ,
I don't think there is public literature on this other than IPSEC architecture
document. Note that, SPD defines the security protocols such as ESP, AH.
In a given SPD policy, you can have both ESP and AH together. This results
into two SAs. Typically, IPSEC informs IKE to get the keys for both of them
together. once IKE gets the keys, it can inform IPSEC packet processing to create
the SA bundle with two SAs.

  Since, IKE negotiates both together, if one SA life time expires, other SAs in 
the SA Bundle can be removed. That means either all SAs in the SA bundle exist
or none exist
-Ravi


Lokesh wrote:
Hi all,
I have a question on Ipsec.
SA's are bundled in SABundle. and there can be multiple SA Bundles existing linked together
in a SPD entry.

1]  under what conditions it is decided that a new SA created should be bundled in a New SABundle? not in a existing one?

can anyone point me to literature on this or similar issue ? ( that is regarding SPD and SA Bundles)
Thanks
Lokesh



--
signature

The views presented in this mail are completely mine. The company is not responsible for whatsoever.
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page



--------------010104080207090200030604-- From owner-ipsec@lists.tislabs.com Wed Apr 9 06:54:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39DstJM026702; Wed, 9 Apr 2003 06:54:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28730 Wed, 9 Apr 2003 09:25:32 -0400 (EDT) Message-Id: <5.1.0.14.0.20030408104652.00a37ec0@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 08 Apr 2003 10:46:54 -0400 To: Charlie_Kaufman@notesdev.ibm.com From: David Jablon Subject: Re: draft-ietf-ipsec-ikev2-06.txt Cc: IPsec WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with recommendation 2(b) with a further suggestion. At 07:35 AM 4/8/03 +0300, Hugo Krawczyk wrote: >(2) Issue of key length for the prf: Make sure that the users of ikev2 >provide enough bits to key the prf. >This is very simple and requires only the following two editorial changes: > > a- [ ... ] > b- specify that when pre-sharing a key for use in prf-based authentication > (i.e., Shared Secret") this key SHOULD [ be ] of the length of the key for the > prf agreed for use by the parties I recommend adding "and this key SHOULD NOT be derived solely from a password or other data that has less randomness than a truly random key of the appropriate length." > Note: here I would have preferred to say MUST instead of SHOULD, > but I know that you want to allow the use of passwords in this mode. I too prefer "MUST", and I prefer "MUST NOT" in the addition. If this text is meant to allow the shared secret key to be a password, or to be derived solely from a password, it is insufficient to specify merely the length of the shared secret. If not, then MUST and MUST NOT seem more appropriate. In any case, the text should at least encourage implementations that encourage use of a shared secret that has sufficient randomness, which, in the case of a password, typically requires that the password be a good amount longer than an equivalent key. Regarding: > We assume that the prf > function takes a variable length key and produces a fixed length > output. When the key for the prf function has fixed length, its > specification for use in IKEv2 must include a procedure for deriving > its required fixed length key from a variable length key. > >This may be short and elegant but it actually creates a big problem >for who wants to use non-HMAC prfs, in particular AES. >Indeed, AES takes fixed keys only and it has no built-in mechanism to handle >variable-length keys. Designing such a mechanism is a very non-trivial >problem (as those subscribed to the cfrg list have witnessed recently). >Therefore, your text above while seemingly simplifying the IKE specification >actually requires to standarize something (variable key support for AES or >general block ciphers) that can take long to get right technically and even >longer to get ietf consensus. In contrast, the spedifications on the length >of nonces and preshared key, suggested above, are simple to state, and >transform the variable key headache into a non-issue. It seems like a tradeoff must be made here. A prf that takes variable length input might be seen as useful to accept passphrases that are a good amount longer than equivalent shared secret keys. I think the suggested (amended) text only makes the headache disappear when shared secrets are keys, and not things like passphrases. -- David From owner-ipsec@lists.tislabs.com Wed Apr 9 06:55:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39Dt0JM026710; Wed, 9 Apr 2003 06:55:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28688 Wed, 9 Apr 2003 09:22:26 -0400 (EDT) Message-ID: <3E91BFCA.6050302@bell-labs.com> Date: Mon, 07 Apr 2003 14:13:30 -0400 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: IKEv2 cookie question References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie_Kaufman@notesdev.ibm.com wrote: > Yes, the spec is clearly broken. Section 2.6 says to include > N(COOKIE_REQUIRED) but no such notify payload is defined..... > It seems like the easiest way to fix it is to remove all > references to N(COOKIE_REQUIRED). I support this solution. > I like it when you can fix a bug by removing things. > Any objections? :-) From owner-ipsec@lists.tislabs.com Wed Apr 9 06:55:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39Dt4JM026724; Wed, 9 Apr 2003 06:55:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28700 Wed, 9 Apr 2003 09:23:28 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501484572@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: John Shriver , "C. M. Heard" Cc: IPsec WG , "Wijnen, Bert (Bert)" Subject: RE: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt Date: Mon, 7 Apr 2003 21:47:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >>Or, I can edit the MIB to give every enumeration a tag for every > >>reserved value. Like on IpsecDoiSecProtocolId, add privateUse249(249), > >>privateUse250(250), privateUse251(251), etc. But I can assure you that > >>many of the management agents out there would crash in flames if we do > >>that. In my experience, they are exceptionally fragile... > > Well... for those TCs where the values are only 249-255 (i.e. 6 labels), I can ahrdly see why people would have a problem with that. > > > > I agree that this would not be a good idea, especially for the ones > > that have private use ranges of 61440-65535, 65001..65535, or > > 32768..65535. > > For those it will indeed be more of an issue. Now... for all of the ones where you talk about values around 32K or 64K, I only se a very few (the biggest one has 30 or so) currently assigned values. Do you expect to need thousands (or even hundreds) or private code points? What if we were to all limit them to 6 private code points? All of a sudden it would be much more acceptable to list them as privateUse249 etc, would it not? Trying to find a good compromise here that would make everyone happy. Bert From owner-ipsec@lists.tislabs.com Wed Apr 9 06:55:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39DtXJM026755; Wed, 9 Apr 2003 06:55:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28699 Wed, 9 Apr 2003 09:23:28 -0400 (EDT) Message-ID: <3E91CB29.4030706@sockeye.com> Date: Mon, 07 Apr 2003 15:02:01 -0400 From: John Shriver Organization: Sockeye Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "C. M. Heard" CC: IPsec WG , "Wijnen, Bert (Bert)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt References: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk C. M. Heard wrote: > On Sat, 5 Apr 2003, C. M. Heard wrote: > % The WG needs to be aware that (according to RFC 2578 Section 7.1.1) > % the only values allowed for objects defined with these enumerated > % INTEGER TCs are the named numbers that are actually present in the > % enumeration list. Thus, managed objects defined with these TCs > % cannot represent values in the ranges that are reserved for private > % use amongst cooperating systems. If it is intended that objects > % defined using these TCs be able to represent arbitrary values of the > % corresponding parameters, including the "private use" values, then a > % SYNTAX value other than enumerated INTEGER will be required -- for > % instance, Unsigned32 with a subrange, as is used in the definition > % of IkePrf. Of course, in that case there would be no need to have > % the IANA maintain these TCs: they could be defined once, in a > % WG-maintained document, with the value list in a conventional > % assigned number registry. > > On Mon, 7 Apr 2003, John Shriver replied: > >>Let me be sure that I understand your intent. Because RFC 2578 Section >>7.1.1 says that the only legal values of an enumeration are those in a >>list, and there may be numbers in the list from the user-reserved space >>that may not be in the list, we should abandon any effort to provide an >>enumeration for any of these number spaces in any MIB for IPsec? >> >>Instead, they should all be range-limited INTEGERS[?] > > > More probably, range-limited Unsigned32 (like IkePrf). But yes, that's > the idea, if the managed objects defined with these TCs are supposed to > be able to represent all possible values of the corresponding parameter. > > >>[A]nd there is no attempt at having software convert small >>positive integers into strings that might make sense to a human, >>and instead people have to look it up by hand? > > > An enumerated INTEGER TC does not do quite that much. All that can be > done with the parseable information in such a TC is to build a table > that converts the values in the enumeration list into the corresponding > enumeration labels. You don't get any of the descriptive text that is > present in the ASN.1 comments. As a user, I have found the enumeration labels much more useful than a raw number. Few agents present the ASN.1 comments in a very accessible manner. (Well, I never used any of the fancy $500,000 SNMP management systems.) > > To be weighed against this benefit is the cost to the IANA of having to > maintain both a conventional registry and a MIB module for the majority > of the IPsec-related assigned numbers. My past experience with stuff > that requires two (or more) versions of the truth to be manually > synchronized suggests to me that this cost will be rather high. Note > that some of the TCs (XyzExchangeType and XyzNotifyType) require > synchronized updates in more than two places. I would hope that the IANA would never try and keep two files synchronized. As the I-D states, the itent was that the MIB would become THE definitive document. This is certainly what has happened with the ifType MIB, although that was MIB-centric. All programmers know that source-file synchronization is evil. > > >>This strikes me as a disservice to the real customers, which are the >>users of any IPsec MIBs. (RFC 2578 is not a customer.) The entire >>purpose of this MIB was to eliminate those manual lookups. > > > In retrospect, it might have been better if the SMI had adopted the > ASN.1 rule that enumerations only specified distinguished values, and > that the underlying type was allowed to have all INTEGER values (well, > all in the range -2147483648..2147483647, since the SMI restricts > INTEGER to that range). But that wasn't what was decided, and the > current rule is the one we have to live with. I think that the current set of MIBs are not absolutely pure in adherence to the standards. > > >>I was thinking that a customer using these MIBs who had a product using >>a proprietary value would simply EDIT their copy of this MIB to include >>the offending value. There's no "do not edit under penalty of law" tag >>on the MIB. > > > Although not sanctioned by the SMI, a customer could indeed perform such > edits. However, they would have to be re-applied whenever the "official" > version was updated with a new registered value, which is clearly > undesirable. I think such edits should be discouraged. So should private use numbers be discouraged. > > >>Rather than abandon the enumerations, I would instead propose to reserve >>one value in each and every enumeration, which would represent all >>values which are "undefined" within the enumeration. The numeric value >>of it would be 65536, which is out of the real protocol range for all >>the numbers. >> >>Then MIB authors who need to reveal the user-reserved values can have a >>second variable that reveals the raw INTEGER number. (What fun! But >>I'm not writing that MIB.) > > > That will work, since all of the items that have "private use" ranges > don't include 65536 as a legitimate value. Again, however, the question > must be asked whether the automatic generation of integer-to-enum-label > tables is worth the cost of using two objects to represent one value. This was somewhat of a tongue-in-cheek suggestion. I doubt that most MIB authors would go to the effort. We'd just lose the information. (Or vendors would ignore the 65536, and put in the real value.) > > >>Or, I can edit the MIB to give every enumeration a tag for every >>reserved value. Like on IpsecDoiSecProtocolId, add privateUse249(249), >>privateUse250(250), privateUse251(251), etc. But I can assure you that >>many of the management agents out there would crash in flames if we do >>that. In my experience, they are exceptionally fragile... > > > I agree that this would not be a good idea, especially for the ones > that have private use ranges of 61440-65535, 65001..65535, or > 32768..65535. > > Frankly, I think that the benefits from the enum labels are not worth > the costs in this application. The costs include both the burden on > the IANA of having to maintain synchronized registries and the need > to have extra MIB objects to represent the "private use" values. I > think it would be better to use subranged Unsigned32 TCs in a > WG-maintained MIB module, with the DESCRIPTION and REFERENCE clauses > of those TCs pointing to the authoritative sources for the number > assignments (namely the defining RFCs and the IANA registries). > However, my role in this matter strictly advisory, and the decision > is ultimately up to the IPsec WG (subject of course to IESG and IANA > approval). Well, I started this project 4 years ago because I thought that the enumeration values really would make IPsec MIBs easier to use. We discussed the "standards fudge" issue of the non-enumerated values back then, and people on the IPsec list weren't offended by the problem. A common-sense standards bending didn't bother them. I don't have time to dig the archives... > > Regards, > > Mike Heard From owner-ipsec@lists.tislabs.com Wed Apr 9 06:56:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39Du4JM026792; Wed, 9 Apr 2003 06:56:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28658 Wed, 9 Apr 2003 09:19:26 -0400 (EDT) Message-Id: <4.3.2.7.2.20030408181513.0258f548@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Apr 2003 18:18:41 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: March 2003 IETF WG Minutes Cc: byfraser@cisco.com, tytso@mit.edu Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_24647130==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_24647130==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Here are the minutes from the working group meeting last month. Please send any corrections to me by April 11 so that we can submit them by the April 14 due date. Special thanks to Jesse for taking such detailed notes during the meeting. Barb ===================================== IPsec Working Group Minutes March 2003 IETF, San Francisco, CA Recorded by: Jesse Walker 1. Agenda bashing Agenda accepted without change. 2. A word from the ADs Russ Housley: Let's get it done. Oscillating on mail list. If it is in document, don't change it unless it is breaking something. 3. Draft status Barbara Fraser: modp group completed last call, RFC editor queue aes xcbc-mac completed last call, waiting for IESG aes-cbc completed last call, waiting for AD writeup sctp completed, kicked back from IESG, but they had wrong version; being rereviewed ESP, 2402bis esn ready for last call nat traversal ready for last call MIB documents ready for last call, but can't find them Dead Peer Detection document ready for last call IKEv2 coming to closure? IKEv2 tutorial 4. Update on ESP, AH, 2401 Steve Kent: ESP & AH changes: revised identification text to better accommodate multicast; clarified anti-replay requirements for multicast; moved discussion of when to use tunnel and transport mode to 2401bis Q: Remove mandatory algorithm references from AH & ESP? No response. SA identification: unicast, SPI is sufficient. Multicast: should support demuxing based on SPI & dest addr, optionally use source addr too. Now SAD flags to cover unicast and multicast: SPI only, SPI + destination addr, SPI + dest addr + src addr Q: What about protocol field in multicast case? Anti-replay: transmitter always increments; receiver can ignore it. Receiver should tell transmitter to ignore seq counter wrap-around if not going to perform anti-replay check. 2401bis: reconciling with IKEv2 selector, relaxing specs on when to use tunnel v. transport; add forwarding/routing lookup prior to SPD lookup. Q: remove mandatory algorithm references? Comment: Forwarding lookup also must return next hop address. Q: Ready for last call? Comment: If aligning 2401bis with IKEv2, does this mean it won't work with IKEv1? Answer: There are new SPD entries can't negotiate with IKEv1. Comment: That is a real issue. Since adding lots of valuable things, it might behoove us to find a way to construct an IKEv1 profile. Answer: it's ESP/AH that are ready to move forward, not 2401bis. 5. High Level Interop There was a miscommunication between the working group chairs. This topic should not have been on the agenda. 6. Backend Config Payload handling Greg Lebovitz/Darren Dukes (Darren presents): Use backend server to assign IP address. IRAC Config Problem -- IPsec remote access client needs private IP address before creating child SAs. How? Config Payload -- allow config payload to do this. Put config payload in IKE-AUTH exchange messages 3 and 4. Can backend with your favorite server. On-IRAS Pools -- not scalable but work for small deployment Off-IRAS Pools -- offload onto backend server; scales better: use DHCP, RADIUS or other backend server Requirements: be able to use DHCP, RADIUS and LDAP to get addresses. Question: Not suggesting changes to IKEv2? Answer: No, augments IKEv2 using IKEv2 mechanisms. 7. IKE DHCP encapsulation Michael Richardson: Requirements: no new namespaces, provide client with info it needs; minimize # of exchanges; interfaces to existing infrastructure; preserves end-to-end security of DHCP; permit independent DHCP evolution. Three methods: DHCP-over-IPsec; ModeCFG over IKE; proposed DHCP over IKE DHCP-over IPsec: product of IPSRA; easy for bump-in-stack, all-in-one gateway; leverages existing DHCP server ModeCFG: occurs in IKE msg 3, uses custom payload; if you need DHCP info, do it over IPsec; easy to interface to RADIUS/COPS/DHCP Why bother? DHCP the defacto standard; don't reinvent DHCP-over-IKE v. over IPsec: creating 0/0 tunnel is hard when crypto offloaded; client systems without virtual i/fs cannot do this easily; may have to leave 0/0 SA around for renewals DHCP-over-IKE v. ModeCFG: same as DHCP-over-IKE, except format bits; ModeCFG needs an IKE 1.5 exchange; DHCP-over-IKE preserves client-server security; extensible; plugs into RADIUS/COPS with mini-DHCP server/proxy; talks to real DHCP server with no glue 8. IKEv2 issues Ted Ts'o: Posted open issues last call to determine how far away from getting IKEv2 out the door. Time to shoot the engineers and ship the product: if not broken, don't fix; some recently introduced problems should be remanded to an IKEv2 extensions WG; otherwise will suffer scope creep What's left: AH and ESPbis; 2401bis; then we can shut down! Want to finish this year. Issues recently resolved: Secure legacy authentication; cipher suites document needed--Jeff Schiller has volunteered; Hugo's key derivation objections; suites v. a la carte; Charlie's question about IKE suite #5. Issues recently discussed (no closure): Multiple tunnels for QoS; multiple tunnels for outsourced VPNs; mobility peer address management; kill me-Tarzan-you-Jane; revised identity; DHCP v. config payload. Outsourced VPNs: is this important to handle now? Solutions exist that require no changes to the draft Mobility peer addr mgmt: support for changing IP addresses during SA lifetime. Important now? assertion: move this into separate WG. Comment: Defect in current draft about IP address. Can move this to another WG. Charlie: if clarifications to existing text, please send suggested text and section changes apply to. Comment: Combine NAT traversal, mobility? Ted: Don't see how the two are related. Comment (Mark Duffy): Include VPN ID in IKEv2. Within PPP have ways to discover identities of VPN members. VPN ID will facilitate this within IPsec. Comment: Suites v. a la carte: no idea what to do to support legacy combinations that aren't in a defined suite. Can't use IKEv2 with these. Want to auto-upgrade configuration, but can't. Response: It will have to be allowed to use both suites and a la carte. We will leave IKEv1 customers as IKEv1 until they can upgrade. Comment (Dan Harkins): Will have to double suites because no way to indicate PFS. Ted: Don't understand. Comment: If we go with suites, consider what other WGs have called out as mandatory to implement. Comment (Charlie Kaufman): You can identify suite you want with vendor ID if single vendor; if multiple vendors want this, then they can ask for this to be added to suites document. Diffie-Hellman group is part of the suite. Comment: Let's propose suite for every combination possible in IKEv1. Comment (Paul Hoffman): Everyone in IKEv1 has GUI that lets them pick what they want. No consistent defaults. People are really using DES, because it is mandatory to implement in IKEv1. Upgrade cannot be direct, because we won't support DES going forward. Comment: Need more active discussion on peer addresses than just a few comments, or we won't handle the problem. Comment (Radia Perlman): Curious whether there is passion behind suites? Charlie: Only losing side shows up. Ted: 80% of room in Atlanta wanted suites. Charlie: heard requirement to negotiate any combination in IKEv1. Russ: Charlie's story: two bales of hay and a donkey. Donkeys are not too dumb not to decide which to eat from. Comment: WG list came to consensus with a la carte suites. VPNID is just another name, and we don't need to do anything about it. Just agree upon a name; just use them. Comment: (Paul Hoffman) 80% people speaking did not support suites, but the vote was 80%. Developers more evenly split on a la carte. Comment: v1 has a la carte, and it ain't broke Comment: What happened to discussion about GUIs? Charlie: Asked a la carte party which a la carte they want. The question of "ands" and "ors" has to be addressed. Changing is tiresome. There is always consensus we can make it better Uri: main reason to have a la carte is it is simpler. main reason to have suites is it is analyzable. This is the main reason to select a la carte. Comment: In the protocol define as a la carte but draft 3 suites. This gives benefits of both. 3 is the right number for interoperability testing. Charlie: Can do this; a la carte text is escrowed. Ted: We don't want to debate this one. Current draft: 5; some form of a la carte: 25; some form of a la carte in v2 '02 draft v v1 encoding scheme: unanimous in favor of v2 '02. Ted: we need to lock this decision in stone. Ted: Want consensus that we won't do QoS, outsourced VPN, mobility support in a new WG. Everyone agrees. 9. Kill off me-Tarzan-you-Jane: argument for: initiator id sufficient to demux multiple VPNs. Comment: But this is not a problem for VPNs. It is a problem for end-to-end use. Don't know what it means to remove it. Comment: Right. Keep me-Tarzan-you-Jane, because useful outside of VPN. Comment: But do we need two different payloads to do same thing? What we need to kill off is optional ID payload. Comment: No. The way the initiator wants to refer to responder identity might not be a raw key. Better to use identity name space rather than key name space. Need to keep identity across key roll-over. Comment: Can't use CERTREQ with anything other than PKIX signing certs. Comment: But then why do we have these other types? Comment: Other types need to be specified; no semantics for them. Comment: Can express remote identity by certificate you want to receive. You will get that certificate. We will always do this, so always pass certificate chains. We won't get the performance optimization we thought. We need a bit saying whether the ID payload refers to requestor or responder. Requirement to specify remote end is a non-negotiable requirement. CERTREQ is for getting certs. This is premature optimization. Charlie: There is confusion. Me-Tarzan-You-Jane solves one problem, but people try to solve other problems, but doesn't work there, so want to remove it. If you don't use it to solve the wrong problem, it is fine and shouldn't be used. Comment (Derek Atkins): Keep what's there. Comment (Dan Harkins): Payload is not non-critical. It is a mandatory option. The problem it solves is never stated. Ted: How many believe current language be kept? Removed? Don't care? Vote was to keep it. If you want it clarified, send text to Charlie. 10. Revised identity Is there anything left to do? Paul Hoffman: Charlie clarified when to send cert. Only open issue is to define what identity means. Do we want to clarify this? Comment: Tarzan-Jane discussion arose because of no identity notion. Comment: We don't know how to build certificates for IKE. We can't change PKIX. Does ID payload contents need to match something in CERT payload? Can solve this problem with one sentence. Need to make this explicit to close this issue. Charlie: Devil is in details. Yes they have to match, but we don't know what matching means. Ted: In Kerberos, you specify name, ticket, and access control check. This problem is never addressed in Kerberos. Similarly in SSH. Because of Cert structure, people think they don't have to check access control list but rather only check some magical field in cert. Interop problems arise from this. Draft haven't done this. Paul: Can't decide this in IKEv2 timeframe. Let's defer it. Comment: Don't want to go through same as last 4 years. Comment: There are implementations that check ACL. Name is just a hint to find right key. People are looking for way to contact random machine and make decisions. Steve Kent: Agree with Paul; too complicated to get resolved. There is an ACL; it is the SPD. Problem people run into is we haven't nailed down SPD syntax well enough to remove these problems. Intent was precisely to establish entries in form that cert will map to SPD entries. This is a 2401bis problem Comment: Two issues: access policy, which is user's decision. Interoperability problems because of configuration. Not trying to solve these problems which is protocol interoperability. What we need to insure is protocol interoperability: do you have to match something in cert to something in ID payload or not. Comment: Try: "after you have authenticated the dude on the other end, you MUST decide whether this matches the access control criteria on your end." Comment: Deal with this in 2401bis. Short term solution is to say that what goes in ID v CERT payload is a local matter for now. It need not match. Comment: SO we will put in sentence that ID payload is for policy lookup and does not need to match anything in CERT payload. Both fields may be used for access control decisions, but need not be correlated. 2-1 in favor. Steve Kent: Don't think this clarifies anything, other than allows a vendor to claim compliance. It doesn't solve the problem. Ted: alternate proposal? Paul Hoffman: Do this on the list. What implementers claim their implementations do doesn't match debug log. Comment: We have opened can of worms best closed on list. 11. DHCP v. CFG payload Summary: Both solutions are technically workable. IKEv2-05 allows server to refuse CFG request and uses fallback to 3456bis. DHCP encapsulation within IKE recent submission. DHCP encapsulation might be suitable compromise, but not fleshed out. If consensus in WG to pursue this new idea, give them limited time, then decide to fallback to IKEv2-05. If people want 3456bis, give people short time to produce text, otherwise fall back to IKEv2-05 CFG payload. 5 or 6 happy with current, 3 or 4 unhappy. Comment: growth of DHCP indicates configuration is a hard problem; let someone solve it. That speaks to just reusing DHCP. Don't reinvent the wheel; just use DHCP. Pursue this with a reasonable timeout with fallback. Comment: CFG payload has fallback mechanism built in for implementations that want to do something else. Keep CFG payload as is to allow DHCP or whatever else. Comment: Getting into trouble with IPv6. Already have several, creating yet another one. Comment: DHCP INFORM gives options not given by CFG payload. This would satisfy problems. Yeah; we do need to think more about v6. Comment: Makes sense to give DHCP 3 weeks to flesh out document. Comment: DHCP is still evolving. CFG payload would not allow use of DHCP end-to-end security. In many cases DHCP options influence address assignment, so need this information before CFG payload. Better to restrict ourselves to one way. Comment: Alternative scenario. Authentication might influence address assignment. Push to restrict this to bootstrap and not generalize it. DHCP is not interoperable in terms of options. Comment: Not clear how DHCP will work with RADIUS or LDP; CFG option superior for this. Comment: Security Gateway acts as proxy for client; it is responsible for authentication. Comment: But this is not end-to-end. Comment: In DHCP-over-IKE, Server is DHCP relay, not a proxy. There are proposals to carry EAP within DHCP, too. While server does have to interpret DHCP bits, we don't want it to modify them. Ted: Seems to be a number of people speaking in favor of allowing DHCP-over-IKE 3 weeks. Strong interest in pursuing this? Comment: in 3 weeks we will compare. Need a few days specifying what scenarios have to be addressed. Comment: More problems being raised now that there is a proposal. IKEv1 was successful because (1) there was a freeware implementation as a starting point and (2) we did interoperability testing before going to RFC. We are not ready to go to RFC, because we have neither of these. The nature of the market is people will believe there is interoperability because it is an RFC. Need to have something more baked. Need to have a bakeoff first. Need to seriously consider doing so before going to RFC. Ted: Problem space WG says we should go to proposed standard sooner. From process viewpoint, we need some way to prevent flip-flop, so implementers can implementers. Comment: Flip-flop occurs because we don't understand problem. Comment: We haven't started IKEv2 implementation. It would be good to have a discussion about this to express opinion about draft. Ted: Let's close on DHCP first before talking about this. Sense of room to try DHCP-within-IKE for 3 weeks and fallback to CFG payload if this doesn't pan out. Comment: There are a lot of ModeCFG in IKEv1. CFG payload is near to this, so there will have to be new code and understanding. Straw vote: CFG payload, DHCP-within-IKE with fallback, something else: 10-14-0. Too close to call; take it to the list. Comment: Let's have straw vote in 3 weeks. Ted: Michael Richardson is the stuckee. We want to get draft ready for WG last call by April 15. Goal to publish this as an RFC before Austria IETF. Issue is whether baking occurs for draft standard or proposed standard. We need to have draft locked down, however. Comment: what happens with 2401bis? Do we want to divorce IKEv2 from 2401bis? are there linkages? Ted: Should we publish IKEv2 and 2401bis simultaneous or in serial. Comment: They should be "simultaneous" Ted: That's what we did with IKEv1, but caused problems because there were 12 docs. Comment: The hairball is not as large this time. Not convinced we have thought through problems we have solved. Comment: Sympathize, but we should try the IETF thing. This is a better goal. Comment: Companies are under travel restrictions. we should make bakeoff affordable and easy to get to. --=====================_24647130==_.ALT Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by edison.cisco.com id SAA05858 Here are the minutes from the working group meeting last month. Please send any corrections to me by April 11 so that we can submit them by the April 14 due date. Special thanks to Jesse for taking such detailed notes during the meeting.

Barb
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IPsec Working Group Minutes
March 2003 IETF, San Francisco, CA
Recorded by: Jesse Walker

1. Agenda bashing

Agenda accepted without change.

2. A word from the ADs

Russ Housley: Let's get it done. Oscillating on mail list. If it is in
document, don't change  it unless it is breaking something.

3. Draft status

Barbara Fraser:

modp group completed last call, RFC editor queue

aes xcbc-mac completed last call, waiting for IESG
aes-cbc completed last call, waiting for AD writeup
sctp completed, kicked back from IESG, but they had wrong version; being
rereviewed
ESP, 2402bis esn ready for last call

nat traversal ready for last call
MIB documents ready for last call, but can't find them

Dead Peer Detection document ready for last call

IKEv2 coming to closure?
IKEv2 tutorial

4. Update on ESP, AH, 2401

Steve Kent:

ESP & AH changes: revised identification text to better accommodate
multicast; clarified  anti-replay requirements for multicast; moved
discussion of when to use tunnel and transport  mode to=20 2401bis

Q: Remove mandatory algorithm references from AH & ESP? No response.

SA identification: unicast, SPI is sufficient. Multicast: should support
demuxing based on SPI  & dest addr, optionally use source addr too. Now SAD
flags to cover unicast and multicast: SPI  only, SPI + destination addr, SPI
+ dest addr + src addr

Q: What about protocol field in multicast case?

Anti-replay: transmitter always increments; receiver can ignore it. Receiver
should tell  transmitter to ignore seq counter wrap-around if not going to
perform anti-replay check.

2401bis: reconciling with IKEv2 selector, relaxing specs on when to use
tunnel v. transport;  add forwarding/routing lookup prior to SPD lookup.

Q: remove mandatory algorithm references?

Comment: Forwarding lookup also must return next hop address.

Q: Ready for last call?

Comment: If aligning 2401bis with IKEv2, does this mean it won't work with
IKEv1? Answer:  There are new SPD entries can't negotiate with IKEv1.
Comment: That is a real issue. Since  adding lots of valuable things, it
might behoove us to find a way to construct an IKEv1  profile. Answer: it's
ESP/AH that are ready to move forward, not 2401bis.

5. High Level Interop

There was a miscommunication between the working group chairs. This topic should not have been on the agenda.

6. Backend Config Payload  handling

Greg Lebovitz/Darren Dukes (Darren presents):

Use backend server to assign IP address.

IRAC Config Problem -- IPsec remote access client needs private IP address
before creating  child SAs. How?

Config Payload -- allow config payload to do this. Put config payload in
IKE-AUTH exchange  messages 3 and 4. Can backend with your favorite server.

On-IRAS Pools -- not scalable but work for small deployment

Off-IRAS Pools -- offload onto backend server; scales better: use DHCP,
RADIUS or other  backend server

Requirements: be able to use DHCP, RADIUS and LDAP to get=20 addresses.

Question: Not suggesting changes to IKEv2? Answer: No, augments IKEv2 using
IKEv2 mechanisms.

7. IKE DHCP encapsulation

Michael Richardson:

Requirements: no new namespaces, provide client with info it needs; minimize
# of exchanges;  interfaces to existing infrastructure; preserves end-to-end
security of DHCP; permit independent  DHCP evolution.

Three methods: DHCP-over-IPsec; ModeCFG over IKE; proposed DHCP over IKE

DHCP-over IPsec: product of IPSRA; easy for bump-in-stack, all-in-one
gateway; leverages  existing DHCP server

ModeCFG: occurs in IKE msg 3, uses custom payload; if you need DHCP info, do
it over IPsec;  easy to interface to RADIUS/COPS/DHCP

Why bother? DHCP the defacto standard; don't reinvent

DHCP-over-IKE v. over IPsec: creating 0/0 tunnel is hard when=20 crypto
offloaded; client systems  without virtual i/fs cannot do this easily; may
have to leave 0/0 SA around for renewals

DHCP-over-IKE v. ModeCFG: same as DHCP-over-IKE, except format bits; ModeCFG
needs an IKE 1.5  exchange; DHCP-over-IKE preserves client-server security;
extensible; plugs into RADIUS/COPS  with mini-DHCP server/proxy; talks to
real DHCP server with no glue

8. IKEv2 issues

Ted Ts'o:

Posted open issues last call to determine how far away from getting IKEv2
out the door.

Time to shoot the engineers and ship the product: if not broken, don't fix;
some recently  introduced problems should be remanded to an IKEv2 extensions
WG; otherwise will suffer scope  creep

What's left: AH and ESPbis; 2401bis; then we can shut down! Want to finish
this year.

Issues recently resolved: Secure legacy authentication; cipher suites
document needed--Jeff  Schiller has volunteered; Hugo's key derivation
objections; suites v. a la carte; Charlie=92s  question about IKE suite #5.

Issues recently discussed (no closure): Multiple tunnels for QoS; multiple
tunnels for  outsourced VPNs; mobility peer address management; kill
me-Tarzan-you-Jane; revised identity;  DHCP v. config payload.

Outsourced VPNs: is this important to handle now? Solutions exist that
require no changes to  the draft

Mobility peer addr mgmt: support for changing IP addresses during=20 SA
lifetime. Important now?  assertion: move this into separate WG.

Comment: Defect in current draft about IP address. Can move this to another
WG. Charlie: if  clarifications to existing text, please send suggested text
and section changes apply to.

Comment: Combine NAT traversal, mobility? Ted: Don't see how the two are
related.

Comment (Mark Duffy): Include VPN ID in IKEv2. Within PPP have ways to
discover identities of  VPN members. VPN ID will facilitate this within
IPsec.

Comment: Suites v. a la carte: no idea what to do to support legacy
combinations that aren't  in a defined suite. Can't use IKEv2 with these.
Want to auto-upgrade configuration, but can't.  Response: It will have to be
allowed to use both suites and a la carte. We will leave IKEv1  customers as
IKEv1 until they can upgrade.

Comment (Dan Harkins): Will have to double suites because no way to indicate
PFS. Ted: Don't  understand.

Comment: If we go with suites, consider what other WGs have called out as
mandatory to  implement.

Comment (Charlie Kaufman): You can identify suite you want with vendor ID if
single vendor; if  multiple vendors want this, then they can ask for this to
be added to suites document.  Diffie-Hellman group is part of the suite.

Comment: Let's propose suite for every combination possible in IKEv1.

Comment (Paul Hoffman): Everyone in IKEv1 has GUI that lets them pick what
they want. No  consistent defaults. People are really using DES, because it
is mandatory to implement in  IKEv1. Upgrade cannot be direct, because we
won't support DES going forward.

Comment: Need more active discussion on peer addresses than just a few
comments, or we won't  handle the problem.

Comment (Radia Perlman): Curious whether there is passion behind suites?
Charlie: Only losing  side shows up. Ted: 80% of room in Atlanta wanted
suites. Charlie: heard requirement to  negotiate any combination in IKEv1.
Russ: Charlie's story: two bales of hay and a donkey.  Donkeys are not too
dumb not to decide which to eat from.

Comment: WG list came to consensus with a la carte suites. VPNID is just
another name, and we  don't need to do anything about it. Just agree upon a
name; just use them.

Comment: (Paul Hoffman) 80% people speaking did not support suites, but the
vote was 80%.  Developers more evenly split on a la carte.

Comment: v1 has a la carte, and it ain't broke

Comment: What happened to discussion about GUIs?

Charlie: Asked a la carte party which a la carte they want. The question of
"ands" and "ors"  has to be addressed. Changing is tiresome. There is always
consensus we can make it better

Uri: main reason to have a la carte is it is simpler. main reason to have
suites is it is  analyzable. This is the main reason to select a la carte.

Comment: In the protocol define as a la carte but draft 3 suites. This gives
benefits of both.  3 is the right number for interoperability testing.

Charlie: Can do this; a la carte text is escrowed.

Ted: We don't want to debate this one. Current draft: 5; some form of a la
carte: 25; some  form of a la carte in v2 '02 draft v v1 encoding scheme:
unanimous in favor of v2 '02.

Ted: we need to lock this decision in stone.

Ted: Want consensus that we won't do QoS, outsourced VPN, mobility support
in a new WG.  Everyone agrees.

9. Kill off me-Tarzan-you-Jane:

argument for: initiator id sufficient to demux multiple VPNs.

Comment: But this is not a problem for VPNs. It is a problem for end-to-end
use. Don't know  what it means to remove it.

Comment: Right. Keep me-Tarzan-you-Jane, because useful outside of VPN.

Comment: But do we need two different payloads to do same thing? What we
need to kill off is  optional ID payload.

Comment: No. The way the initiator wants to refer to responder identity
might not be a raw  key. Better to use identity name space rather than key
name space. Need to keep identity  across key roll-over.

Comment: Can't use CERTREQ with anything other than PKIX signing certs.

Comment: But then why do we have these other types?

Comment: Other types need to be specified; no semantics for them.

Comment: Can express remote identity by certificate you want to receive. You
will get that  certificate. We will always do this, so always pass
certificate chains. We won't get the  performance optimization we thought.
We need a bit saying whether the ID payload refers to  requestor or
responder. Requirement to specify remote end is a non-negotiable
requirement.  CERTREQ is for getting certs. This is premature optimization.

Charlie: There is confusion. Me-Tarzan-You-Jane solves one problem, but
people try to solve  other problems, but doesn't work there, so want to
remove it. If you don't use it to solve the  wrong problem, it is fine and
shouldn't be used.

Comment (Derek Atkins): Keep what's there.

Comment (Dan Harkins): Payload is not non-critical. It is a mandatory
option. The problem it  solves is never stated.

Ted: How many believe current language be kept? Removed? Don't care? Vote
was to keep it. If  you want it clarified, send text to Charlie.

10. Revised identity

Is there anything left to do?

Paul Hoffman: Charlie clarified when to send cert. Only open issue is to
define what identity  means. Do we want to clarify this?

Comment: Tarzan-Jane discussion arose because of no identity=20 notion.

Comment: We don't know how to build certificates for IKE. We can't change
PKIX. Does ID  payload contents need to match something in CERT payload? Can
solve this problem with one  sentence. Need to make this explicit to close
this issue.

Charlie: Devil is in details. Yes they have to match, but we don't know what
matching means.

Ted: In Kerberos, you specify name, ticket, and access control check. This
problem is never  addressed in Kerberos. Similarly in SSH. Because of Cert
structure, people think they don't  have to check access control list but
rather only check some magical field in cert. Interop  problems arise from
this. Draft haven't done this.

Paul: Can't decide this in IKEv2 timeframe. Let's defer it.

Comment: Don't want to go through same as last 4 years.

Comment: There are implementations that check ACL. Name is just a hint to
find right key.  People are looking for way to contact random machine and
make decisions.

Steve Kent: Agree with Paul; too complicated to get resolved. There is an
ACL; it is the SPD.  Problem people run into is we haven't nailed down SPD
syntax well enough to remove these  problems. Intent was precisely to
establish entries in form that cert will map to SPD entries.  This is a
2401bis problem

Comment: Two issues: access policy, which is user's decision.
Interoperability problems  because of configuration. Not trying to solve
these problems which is protocol  interoperability. What we need to insure
is protocol interoperability: do you have to match  something in cert to
something in ID payload or not.

Comment: Try: "after you have authenticated the dude on the other end, you
MUST decide whether  this matches the access control criteria on your end."

Comment: Deal with this in 2401bis. Short term solution is to say that what
goes in ID v CERT  payload is a local matter for now. It need not match.

Comment: SO we will put in sentence that ID payload is for policy lookup and
does not need to  match anything in CERT payload. Both fields may be used
for access control decisions, but need  not be correlated. 2-1 in favor.

Steve Kent: Don't think this clarifies anything, other than allows a vendor
to claim  compliance. It doesn't solve the problem.

Ted: alternate proposal?

Paul Hoffman: Do this on the list. What implementers claim their
implementations do doesn't  match debug log.

Comment: We have opened can of worms best closed on list.

11. DHCP v. CFG payload

Summary: Both solutions are technically workable. IKEv2-05 allows server to
refuse CFG request  and uses fallback to 3456bis. DHCP encapsulation within
IKE recent submission.

DHCP encapsulation might be suitable compromise, but not fleshed out. If
consensus in WG to  pursue this new idea, give them limited time, then
decide to fallback to IKEv2-05. If people  want 3456bis, give people short
time to produce text, otherwise fall back to IKEv2-05 CFG  payload. 5 or 6
happy with current, 3 or 4 unhappy.

Comment: growth of DHCP indicates configuration is a hard problem; let
someone solve it. That  speaks to just reusing DHCP. Don't reinvent the
wheel; just use DHCP. Pursue this with a  reasonable timeout with fallback.

Comment: CFG payload has fallback mechanism built in for implementations
that want to do  something else. Keep CFG payload as is to allow DHCP or
whatever else.

Comment: Getting into trouble with IPv6. Already have several, creating yet
another one.

Comment: DHCP INFORM gives options not given by CFG payload. This would
satisfy problems.  Yeah; we do need to think more about v6.

Comment: Makes sense to give DHCP 3 weeks to flesh out document.

Comment: DHCP is still evolving. CFG payload would not allow use of DHCP
end-to-end security.  In many cases DHCP options influence address
assignment, so need this information before CFG  payload. Better to restrict
ourselves to one way.

Comment: Alternative scenario. Authentication might influence address
assignment. Push to  restrict this to bootstrap and not generalize it. DHCP
is not interoperable in terms of  options.

Comment: Not clear how DHCP will work with RADIUS or LDP; CFG=20 option
superior for this.

Comment: Security Gateway acts as proxy for client; it is responsible for
authentication.

Comment: But this is not end-to-end.

Comment: In DHCP-over-IKE, Server is DHCP relay, not a proxy. There are
proposals to carry EAP  within DHCP, too. While server does have to
interpret DHCP bits, we don't want it to modify  them.

Ted: Seems to be a number of people speaking in favor of allowing
DHCP-over-IKE 3 weeks.  Strong interest in pursuing this?

Comment: in 3 weeks we will compare. Need a few days specifying=20 what
scenarios have to be  addressed.

Comment: More problems being raised now that there is a proposal. IKEv1 was
successful because  (1) there was a freeware implementation as a starting
point and (2) we did interoperability  testing before going to RFC. We are
not ready to go to RFC, because we have neither of these.  The nature of the
market is people will believe there is interoperability because it is an
RFC. Need to have something more baked. Need to have a bakeoff first. Need
to seriously  consider doing so before going to RFC.

Ted: Problem space WG says we should go to proposed standard sooner. From
process viewpoint,  we need some way to prevent flip-flop, so implementers
can implementers.

Comment: Flip-flop occurs because we don't understand problem.

Comment: We haven't started IKEv2 implementation. It would be good to have a
discussion about  this to express opinion about draft.

Ted: Let's close on DHCP first before talking about this. Sense of room to
try DHCP-within-IKE  for 3 weeks and fallback to CFG payload if this doesn't
pan out.

Comment: There are a lot of ModeCFG in IKEv1. CFG payload is near to this,
so there will have  to be new code and understanding.

Straw vote: CFG payload, DHCP-within-IKE with fallback, something else:
10-14-0. Too close to  call; take it to the list.

Comment: Let's have straw vote in 3 weeks.

Ted: Michael Richardson is the stuckee. We want to get draft ready for WG
last call by April  15. Goal to publish this as an RFC before Austria IETF.
Issue is whether baking occurs for  draft standard or proposed standard. We
need to have draft locked down, however.

Comment: what happens with 2401bis? Do we want to divorce IKEv2=20 from
2401bis? are there  linkages?

Ted: Should we publish IKEv2 and 2401bis simultaneous or in serial.

Comment: They should be "simultaneous"

Ted: That's what we did with IKEv1, but caused problems because there were
12 docs.

Comment: The hairball is not as large this time. Not convinced we have
thought through  problems we have solved.

Comment: Sympathize, but we should try the IETF thing. This is a better
goal.

Comment: Companies are under travel restrictions. we should make bakeoff
affordable and easy  to get to.


 --=====================_24647130==_.ALT-- From owner-ipsec@lists.tislabs.com Wed Apr 9 06:56:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39DuhJM026817; Wed, 9 Apr 2003 06:56:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28825 Wed, 9 Apr 2003 09:29:32 -0400 (EDT) Message-ID: <3E93400C.4030105@sockeye.com> Date: Tue, 08 Apr 2003 17:33:00 -0400 From: John Shriver Organization: Sockeye Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: John Shriver , "C. M. Heard" , IPsec WG , "Russ Housley (E-mail)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt References: <7D5D48D2CAA3D84C813F5B154F43B15501599E48@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Wijnen, Bert (Bert) wrote: > John,.... > pls calm down. I think Mike is trying to do due dilligence and try > to explain what the issues are that he sees. He then also tries to > understand the issues from your side. Next step is to come up with > a good solution. > > The way you respond, it sounds as if the securty folk think > "shoot the MIB doctors, we know what we want and how we want it done". > > What if we NM protocol developers would say: "shoot the Security Geeks, > we know what we want and we know how we want it done". > > Thanks, > Bert > Understood. I'm trying to be calm, if pragmatic. The point I'm making in the last response is that some of the MIB Doctors are missing the context of how and why these TC's are done this way. If the MIBs that Tim and I wrote were progressing along with the TC MIB, this would be clearer. But we've had to abandon that effort for a variety of reasons, so the TC MIB is proceeding without any local context, to meet the needs of other MIB projects that need these TCs. This makes it harder to understand them. There was no intent to produce something ugly. Just something practical. I'm NOT very up on the MIB projects that are planning to use the TC MIB. Perhaps the new MIBs don't need to document "on the wire" protocol values. If that's the case, we can simply strike all mention of the private use values. Are any of those MIB authors out there reading this conversation? Could you speak up on that topic? From owner-ipsec@lists.tislabs.com Wed Apr 9 06:58:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39DwMJM026856; Wed, 9 Apr 2003 06:58:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28808 Wed, 9 Apr 2003 09:28:37 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501599E48@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: John Shriver , "C. M. Heard" Cc: IPsec WG , "Wijnen, Bert (Bert)" , "Russ Housley (E-mail)" Subject: RE: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt Date: Tue, 8 Apr 2003 23:05:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk John,.... pls calm down. I think Mike is trying to do due dilligence and try to explain what the issues are that he sees. He then also tries to understand the issues from your side. Next step is to come up with a good solution. The way you respond, it sounds as if the securty folk think "shoot the MIB doctors, we know what we want and how we want it done". What if we NM protocol developers would say: "shoot the Security Geeks, we know what we want and we know how we want it done". Thanks, Bert > -----Original Message----- > From: John Shriver [mailto:jshriver+ietf@sockeye.com] > Sent: dinsdag 8 april 2003 22:56 > To: C. M. Heard > Cc: IPsec WG; Wijnen, Bert (Bert) > Subject: Re: Important question about > draft-ietf-ipsec-doi-tc-mib-07.txt > > > C. M. Heard wrote: > > John Shriver wrote: > > > >>C. M. Heard wrote: > >>John Shriver wrote: > >> > >>>>Let me be sure that I understand your intent. Because RFC 2578 > >>>>Section 7.1.1 says that the only legal values of an enumeration > >>>>are those in a list, and there may be numbers in the list from > >>>>the user-reserved space that may not be in the list, we should > >>>>abandon any effort to provide an enumeration for any of these > >>>>number spaces in any MIB for IPsec? > >>>> > >>>>Instead, they should all be range-limited INTEGERS[?] > >>> > > [ ... ] > > > >>>>This strikes me as a disservice to the real customers, which are > >>>>the users of any IPsec MIBs. (RFC 2578 is not a customer.) The > >>>>entire purpose of this MIB was to eliminate those manual lookups. > >>> > >>>In retrospect, it might have been better if the SMI had adopted the > >>>ASN.1 rule that enumerations only specified distinguished values, > >>>and that the underlying type was allowed to have all INTEGER values > >>>(well, all in the range -2147483648..2147483647, since the SMI > >>>restricts INTEGER to that range). But that wasn't what > was decided, > >>>and the current rule is the one we have to live with. > >> > > [ ... ] > > > >>We discussed the "standards fudge" issue of the > non-enumerated values > >>back [when this project was started], and people on the IPsec list > >>weren't offended by the problem. A common-sense standards bending > >>didn't bother them. > > > > > > The problem with bending the rules in this way is that it is > > confounds expectations that people have (based on what is in > > the standard) regarding what enumerated INTEGERs mean. I put > > this question to the other MIB Doctors and got these answers: > > > > On Mon, 7 Apr 2003, Randy Presuhn wrote: > > % What bothers me about this proposal is not so much the notion of > > % extending enumerations without adjusting the documentation, but > > % rather the semantic ambigiuities that will result due to the lack > > % of coordination of the enumeration assignments. For this kind of > > % un-coordinated private use, OBJECT IDENTIFIERs are really the way > > % to go. Otherwise, one has no way of knowing whether agent A's 42 > > % means the same thing as agent (or manager) B's. > > This applies EQUALLY to the ISAKMP/IKE protocol definitions. > Implementation A's 64411 is indistinguishable from Implementation B's > 64411. Even if they mean totally different things. (Most > are used in > cases where Implementation A can tell if it is talking to one of it's > own species.) > > We are trying to design MIBs, and TCs, that can document the actual > behavior of the protocol. If the protocol is a bit screwy, > that's life. > (Let's just say that ISAKMP/IKE does not comform to RFC > 2578, at least > in spirit.) > > > > > On Mon, 7 Apr 2003, Andy Bierman wrote: > > % I agree with Randy. If they are leaving enum values unspecified > > % so vendors can assign their own value, then this is a misuse of > > % enumerated INTEGER. If enums are really the appropriate > data type, > > % and they know now that they want specific values defined, then > > % all enum values should be listed and documented. > > The vendors are not assigning the numbers for the purpose of > the MIB, as > noted above, they are assigning it for the purpose of the > protocol. I > would never have proposed this approach if these TCs were not VERY > tightly coupled to the protocol. > > (There was a place in the real MIBs that were once part of > this effort > where I did use Object Identifiers for cross referencing. See > saOakleyGroup in the long-expired > draft-ietf-ipsec-ike-monitor-mib-02.txt.) > > > > > What the Randy's and Andy's comments are saying is that enumerated > > INTEGERs are the wrong data type for this application not because of > > an obscure technical violation of RFC 2578 but because this usage > > violates the semantics that are expected of enumerated INTEGERs. I > > tend to agree with that, and that's why I have suggested subranged > > Unsigned32 would be a more appropriate choice. > > A more straightforward description is that I tried to forge a > compromise > between multiple design goals: > > 1. Easy to impelement on the product without pain. (This is why I > export exactly what the protocol negotiated, no remapping to > any other > space). > > 2. Easy to use, in that the normally used values are displayed as an > enumeration, even on commonly available free SNMP implementations. > > 3. Avoid the never reaches full standard problem by having the TC MIB > managed by the IANA. > > > I will warn that the IPsec implementors in this working group > are VERY > harsh about any MIB proposals that intrude deeply into performance. > There have been very contentious discussions. They really > aren't very > interested in SNMP in the first place, which is obvious by the very > minimal feedback all discussions of the MIBs have produced. > They won't > bend very far to implement a MIB. > > An approach that doesn't meet goal 1 won't get implemented. > > If strict RFC 2578 conformance is the only way that IPsec MIBs can be > published, I can assure you that goal 2 will be dropped in > favor of goal > 1. Having to map every sort of protocol number into a Object > Identifier > (Andy's approach) is going to be quite unpopular, even if approved by > the working group, I doubt it would get the "implement it" vote. > > > Thanks, > > > > Mike Heard > > > From owner-ipsec@lists.tislabs.com Wed Apr 9 06:58:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39DwcJM026868; Wed, 9 Apr 2003 06:58:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28803 Wed, 9 Apr 2003 09:28:31 -0400 (EDT) Message-ID: <3E933772.9080801@sockeye.com> Date: Tue, 08 Apr 2003 16:56:18 -0400 From: John Shriver Organization: Sockeye Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "C. M. Heard" CC: IPsec WG , "Wijnen, Bert (Bert)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt References: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk C. M. Heard wrote: > John Shriver wrote: > >>C. M. Heard wrote: >>John Shriver wrote: >> >>>>Let me be sure that I understand your intent. Because RFC 2578 >>>>Section 7.1.1 says that the only legal values of an enumeration >>>>are those in a list, and there may be numbers in the list from >>>>the user-reserved space that may not be in the list, we should >>>>abandon any effort to provide an enumeration for any of these >>>>number spaces in any MIB for IPsec? >>>> >>>>Instead, they should all be range-limited INTEGERS[?] >>> > [ ... ] > >>>>This strikes me as a disservice to the real customers, which are >>>>the users of any IPsec MIBs. (RFC 2578 is not a customer.) The >>>>entire purpose of this MIB was to eliminate those manual lookups. >>> >>>In retrospect, it might have been better if the SMI had adopted the >>>ASN.1 rule that enumerations only specified distinguished values, >>>and that the underlying type was allowed to have all INTEGER values >>>(well, all in the range -2147483648..2147483647, since the SMI >>>restricts INTEGER to that range). But that wasn't what was decided, >>>and the current rule is the one we have to live with. >> > [ ... ] > >>We discussed the "standards fudge" issue of the non-enumerated values >>back [when this project was started], and people on the IPsec list >>weren't offended by the problem. A common-sense standards bending >>didn't bother them. > > > The problem with bending the rules in this way is that it is > confounds expectations that people have (based on what is in > the standard) regarding what enumerated INTEGERs mean. I put > this question to the other MIB Doctors and got these answers: > > On Mon, 7 Apr 2003, Randy Presuhn wrote: > % What bothers me about this proposal is not so much the notion of > % extending enumerations without adjusting the documentation, but > % rather the semantic ambigiuities that will result due to the lack > % of coordination of the enumeration assignments. For this kind of > % un-coordinated private use, OBJECT IDENTIFIERs are really the way > % to go. Otherwise, one has no way of knowing whether agent A's 42 > % means the same thing as agent (or manager) B's. This applies EQUALLY to the ISAKMP/IKE protocol definitions. Implementation A's 64411 is indistinguishable from Implementation B's 64411. Even if they mean totally different things. (Most are used in cases where Implementation A can tell if it is talking to one of it's own species.) We are trying to design MIBs, and TCs, that can document the actual behavior of the protocol. If the protocol is a bit screwy, that's life. (Let's just say that ISAKMP/IKE does not comform to RFC 2578, at least in spirit.) > > On Mon, 7 Apr 2003, Andy Bierman wrote: > % I agree with Randy. If they are leaving enum values unspecified > % so vendors can assign their own value, then this is a misuse of > % enumerated INTEGER. If enums are really the appropriate data type, > % and they know now that they want specific values defined, then > % all enum values should be listed and documented. The vendors are not assigning the numbers for the purpose of the MIB, as noted above, they are assigning it for the purpose of the protocol. I would never have proposed this approach if these TCs were not VERY tightly coupled to the protocol. (There was a place in the real MIBs that were once part of this effort where I did use Object Identifiers for cross referencing. See saOakleyGroup in the long-expired draft-ietf-ipsec-ike-monitor-mib-02.txt.) > > What the Randy's and Andy's comments are saying is that enumerated > INTEGERs are the wrong data type for this application not because of > an obscure technical violation of RFC 2578 but because this usage > violates the semantics that are expected of enumerated INTEGERs. I > tend to agree with that, and that's why I have suggested subranged > Unsigned32 would be a more appropriate choice. A more straightforward description is that I tried to forge a compromise between multiple design goals: 1. Easy to impelement on the product without pain. (This is why I export exactly what the protocol negotiated, no remapping to any other space). 2. Easy to use, in that the normally used values are displayed as an enumeration, even on commonly available free SNMP implementations. 3. Avoid the never reaches full standard problem by having the TC MIB managed by the IANA. I will warn that the IPsec implementors in this working group are VERY harsh about any MIB proposals that intrude deeply into performance. There have been very contentious discussions. They really aren't very interested in SNMP in the first place, which is obvious by the very minimal feedback all discussions of the MIBs have produced. They won't bend very far to implement a MIB. An approach that doesn't meet goal 1 won't get implemented. If strict RFC 2578 conformance is the only way that IPsec MIBs can be published, I can assure you that goal 2 will be dropped in favor of goal 1. Having to map every sort of protocol number into a Object Identifier (Andy's approach) is going to be quite unpopular, even if approved by the working group, I doubt it would get the "implement it" vote. > Thanks, > > Mike Heard From gmichael1f48cdsl@msn.com Wed Apr 9 07:16:27 2003 Received: from hotmail.com (bay3-dav71.bay3.hotmail.com [65.54.169.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39EGQJM028768; Wed, 9 Apr 2003 07:16:26 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 9 Apr 2003 07:16:22 -0700 Received: from 80.110.62.232 by bay3-dav71.bay3.hotmail.com with DAV; Wed, 09 Apr 2003 14:16:22 +0000 X-Originating-IP: [80.110.62.232] X-Originating-Email: [gmichael1f48cdsl@msn.com] Subject: Come Join In And Earn Lots Of Hard Cash! mSOW02 To: "Sender Fiala" From: "Schnoor Pistelli" Importance: Normal Organization: GUgl7KeRCa08j8awXMwd1Cu3Trsi X-Accept-Language: en X-Comment: 0M X-Originating-Ip: [4.394.279.293] Content-Type: multipart/alternative; boundary="1vQP3kgoRAe4XO0RF1qqL457ra1TyMc1jt80P3O8vpE7u1tmBl332823fGUgl7KeRCa08" Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 09 Apr 2003 14:16:22.0751 (UTC) FILETIME=[992856F0:01C2FEA2] Date: 9 Apr 2003 07:16:22 -0700 --1vQP3kgoRAe4XO0RF1qqL457ra1TyMc1jt80P3O8vpE7u1tmBl332823fGUgl7KeRCa08 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="US-ASCII"
*** GAMBLE WITH $310 FOR FREE ***
And Win Huge!

Click Here To Get Started

Why step out of the house when you can score large right now!

Recieve a credit of $310 by downloading our
Casino software for free!

Click Here To Get Started
No more mail? click
--1vQP3kgoRAe4XO0RF1qqL457ra1TyMc1jt80P3O8vpE7u1tmBl332823fGUgl7KeRCa08-- From owner-ipsec@lists.tislabs.com Wed Apr 9 10:34:31 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39HYTJM010669; Wed, 9 Apr 2003 10:34:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00539 Wed, 9 Apr 2003 12:50:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <5.1.0.14.0.20030408104652.00a37ec0@pop.theworld.com> References: <5.1.0.14.0.20030408104652.00a37ec0@pop.theworld.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 9 Apr 2003 09:47:21 -0700 To: David Jablon , Charlie_Kaufman@notesdev.ibm.com From: Paul Hoffman / VPNC Subject: Re: draft-ietf-ipsec-ikev2-06.txt Cc: IPsec WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:46 AM -0400 4/8/03, David Jablon wrote: >I too prefer "MUST", and I prefer "MUST NOT" in the addition. Could you explain the technical reason for that? If someone uses a password instead of a sufficiently-random shared secret, will the PRF break? We have no way of testing if someone has used a password vs. a shared secret. If we say MUST and MUST NOT, we are saying that implementations must somehow test for this. SHOULD and SHOULD NOT (with the appropriate wording about the problems of passwords) seems more realistic, but if there truly is a technical problem with using a password in a PRF as Hugo has described, then we should know about it. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Apr 9 13:32:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39KWEJM021820; Wed, 9 Apr 2003 13:32:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01232 Wed, 9 Apr 2003 15:47:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.1.0.14.0.20030408150612.0256cec0@172.16.1.10> References: <5.1.0.14.0.20030408150612.0256cec0@172.16.1.10> Date: Wed, 9 Apr 2003 15:43:30 -0400 To: Lokesh From: Stephen Kent Subject: Re: Question on SA Bundle Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:24 PM +0530 4/8/03, Lokesh wrote: >Hi all, >I have a question on Ipsec. >SA's are bundled in SABundle. and there can be multiple SA Bundles >existing linked together >in a SPD entry. > >1] under what conditions it is decided that a new SA created should >be bundled in a New SABundle? not in a existing one? > >can anyone point me to literature on this or similar issue ? ( that >is regarding SPD and SA Bundles) >Thanks >Lokesh Lokesh, When writing 2401 we thought it might be possible to provide the ability to link together a number of SAs into a bundle, similar to what you describe in #1 above. However, in reality, IKE v1 was not able to negotiate a general notion of bundling, specifically a way to link new SAs to existing SAs. Thus, in practice the only bundles that occur arise when one negotiates both AH and ESP in a single IKE negotiaiton. As we revise 2401, I anticipate clarifying this, and essentially doing away with the notion of bundles. I have not see a strong need for them in list discussions, nor does IKE v2 have support for adding SAs to a bundle. If folks think this is not the right path for 2401bis, let me know. Steve From owner-ipsec@lists.tislabs.com Wed Apr 9 14:45:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39LjTJM023627; Wed, 9 Apr 2003 14:45:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01455 Wed, 9 Apr 2003 17:10:22 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: IKE V2 Open Issues From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Wed, 09 Apr 2003 17:14:46 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk After the San Francisco IETF meeting, we left with a couple of issues that were settled at the meeting, and which need to be confirmed on the list. Those issues are: 1. Revisiting the decision reached in Atlanta concerning suites vs. ala carte negotiation to use an ala carte style negotiation 2. Keeping the Me Tarzan, You Jane feature 3. Identity handling (although the conensus on this issue was somewhat rough. Please see the expanded discussion in a follow on message.) I will be sending out separate messages for each of these issues to make it easier to manage the thread of discussion on these items. Left open at San Francisco was the disposition of Configuration Payload versus DHCP over IKE. Tero has last week posted to the list three documents which document DHCP over IKE. We invite people to read these documents and to comment on them. Finally, there has also been a number of new (or re-opened) issues that have bubbled up on the list since the San Francisco. These are: 1) Hugo's proposal to change legacy authentication to protect the initiator's identity against active attacks. After looking at the discussion, Barbara and I have concluded that the impacts of moving around various protocol elements introduces numerous additional complexities which will be hard to address at this late date. Russ with his AD hat on set as the bar, "if the changes are the least bit onerous, then this should not be done". We believe these changes meet that test. 2) Tero's proposal for a new source-address-changed notification payload. We proposed in San Francisco that issues regarding address management be considered out of scope, and deferred to another working group. Tero's proposal is short and self-contained, hopefully non-controversial. If so, it seems reasonable to the wg chairs that it be included in ikev2. If there are any questions or debate over this item, however, we feel it should be defered to another working group. 3) Uri's AES PRF proposal. The cryptographers are arguing amongst themselves; we don't want to get involved. We suggest that the Crypto group in the IRTF review it, and if they give us their blessing we can standardize it in a separate standalone document. 4) Michael Richardson's proposal to define separate payload numbers for IDi and IDr. Seems simple enough, and not controversial; let's just do it. 5) Lack of definition of the COOKIE_REQUIRED notify payload. Charlie's suggestion to delete the COOKIE_REQUIRED payload and simply to use the COOKIE payload is simple, and non-controversial. After reviewing the open issues, we believe that we are really close to finishing IKEv2. We had originally targetted WG last call for April 15th. That's only a week away, but if we can come to closure quickly on the DHCP/IKE vs. CP issue, we belive we should be able to close the other issues in time to meet that deadline. Ted and Barbara From owner-ipsec@lists.tislabs.com Wed Apr 9 14:45:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39LjYJM023630; Wed, 9 Apr 2003 14:45:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01477 Wed, 9 Apr 2003 17:11:26 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Confirm decision to keep Me Tarzan, You Jane From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Wed, 09 Apr 2003 17:15:48 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At the San Jose IETF, the IPSEC working group came to consensus (confirmed by a straw poll) to keep the Me Tarzan, You Jane feature in IKEv2. This message is to confirm on the list. Anyone who feels that the sense of the room in San Francisco does not correspond to working group consensus, or that face-to-face meeting failed to consider some critical technical issue is hereby invited to speak up now. From owner-ipsec@lists.tislabs.com Wed Apr 9 14:45:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39LjXJM023629; Wed, 9 Apr 2003 14:45:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01511 Wed, 9 Apr 2003 17:15:22 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Wed, 09 Apr 2003 17:19:17 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Last week on Thursday, Tero Kevinen has submitted three drafts (*) that define DHCP over IKE. Comments to these documents are solicted, and thoughts about whether this approach is superior or inferior to the currently specified Configuration payload in ikev2-06 are hereby solicited. (*) Tero, go ahead and submit them as IPSEC wg I-D's --- Barbara and I will approve them as working group documents. From owner-ipsec@lists.tislabs.com Wed Apr 9 14:45:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39LjWJM023628; Wed, 9 Apr 2003 14:45:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01486 Wed, 9 Apr 2003 17:14:22 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Confirm decision on identity handling. From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Wed, 09 Apr 2003 17:18:10 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At the San Jose IETF, the IPSEC working group came to a rough consensus (confirmed by a straw poll) to solve an interoperability problem as follows: (quoting from the minutes) >Comment: Deal with this in 2401bis. Short term solution is to say that what >goes in ID v CERT payload is a local matter for now. It need not match. > >Comment: SO we will put in sentence that ID payload is for policy lookup and >does not need to match anything in CERT payload. Both fields may be used >for access control decisions, but need not be correlated. 2-1 in favor. The consensus was relatively rough, and there was a desire expressed by some to continue the discussion on the list. In order to move the discussion forward, we propose the following addition to section 3.5 of the ikev2-06 as meeting the spirit of the consensus which was developed in San Francisco. Append to the first paragraph, which begins: The Identification Payload, denoted ID in this memo, allows peers to assert an identify to one another. The ID Payload names the identity to be authenticated with the AUTH payload. .. the following text: ... This identity is used for policy lookup, but does not necessarily have to match anything in the CERT payload; both fields may be used by an implementation to perform access control decisions. Discussion: The implication of this change, as was discussed in San Francisco, is that it gives freedom to implementations to make more sophisticated access control policies, where the responder might use the identity in the ID payload to look up an access control list, and match the subject name in the certificate against that ACL, for example. This can be advantageous in that do not need to dictate the form of the subject names in the certificate, which could promote the reuse of certificates across multiple applications. The downside is that the initiator must now allow the configuration of two pieces of information; there is an additional configuration "knob" which must be set correct in order for two peers to successfully ocmmunicate. There are other alternatives, which have been discussed in the past. Two self-consistent and workable alternatives are presented here: 2) Require that that IPSEC strictly define the types of X.509 certificate subject names that would be accepted, and precisely define the matching rules of the identity payload. This in effect would predefine the access control policies in the system. One mechanism for doing so can be found in section 3.2 of draft-ietf-ipsec-pki-profile-02.txt. 3) Specify that the ID payload must not be sent and/or is ignored when using certificates to authenticate. In this case, the Certificate subject name is used to lookup the policy information associated with the SA instead of the contents identity payload. (This is essentially very similar to a proposla contained in Paul Hoffman's revised-identity I-D.) These alternatives have tradeoffs: to differing degress, they essentially limit flexibility in the choice of certificate names and the name (identity) used to look up policy information. In the first case, the choice of the name found in certificate is limited to something which passes the matching rule defined in the pki-profile I-D when the subject name or the subject alt name is matched against the contents of the identity payload. In the second case, the name used to look up the SA policy is constrained to be exactly the subject name in the certificate, or perhaps the certificate itself. The latter alternative in particular may impact some implementations significantly, by changing the key used to look up and manage SA policy information. Decision path: At the San Francisco meeting, there was clear (but rough) consensus to explicitly specify that the contents of the ID payload do not have to match the contents of the CERT payload, and which will require that initiators have sufficient configuration controls to set both the ID and Cert payloads. Proposed text which implements this rough conensus has been included in this messange. Since the straw poll indicated that of the people in the room at San Francisco, that people were 2-1 in favor of this choice, and this chice should be considered the privileged or "default" choice. However, especially given the roughness of the consensus there, this decision must be confirmed on the mailing list. People who believe that one of the above alternatives, or some other alternative, should be adopted instead, are encouraged to speak up. From owner-ipsec@lists.tislabs.com Wed Apr 9 14:45:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39LjmJM023675; Wed, 9 Apr 2003 14:45:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01471 Wed, 9 Apr 2003 17:11:22 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Confirm Suites v. a la carte decision. From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Wed, 09 Apr 2003 17:15:20 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At the San Jose IETF, the IPSEC working group came to consensus (confirmed by a straw poll) to switch back to using an ala carte mechanism for negotiating SA parameters. This message is to confirm on the list. Anyone who feels that the sense of the room in San Francisco does not correspond to working group consensus, or that face-to-face meeting failed to consider some critical technical issue is hereby invited to speak up now. - Ted and Barbara From owner-ipsec@lists.tislabs.com Wed Apr 9 15:06:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39M66JM024685; Wed, 9 Apr 2003 15:06:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01592 Wed, 9 Apr 2003 17:37:34 -0400 (EDT) Date: Thu, 10 Apr 2003 00:41:44 +0300 Message-Id: <200304092141.h39LfiEd016315@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com CC: lokeshnb@intotoinc.com, ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Wed, 9 Apr 2003 15:43:30 -0400) Subject: Re: Question on SA Bundle References: <5.1.0.14.0.20030408150612.0256cec0@172.16.1.10> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Stephen Kent > If folks think this is not the right path for 2401bis, let me know. In my understanding "bundle" is loose concept, e.g. in a policy I could specify selector1 -> apply SA1(AH), apply SA2(ESP), apply SA2(ESP) selector2 -> apply SA2(ESP) Bundle is just a set of IPSEC transformations (and SA's) that are specified to be applied to a packet that maches a particular selector. The same component SA can be used in different "bundles". That's about all that "bundle" means to me. Unfortunately, IKEv1 thinks/requires more strict "bundle" concept. It cannot negotiate individual SA's belonging to same "bundle" separately, or share SA's between bundles. Key management should negotiate SA's individually. Speaking of bundles, I just currently trying examine how to get IPSEC to work with MIPv6. Assume you have mobile node (MN) and correspondent node (CN), home agent (HA). Assume CN is some service that requires IPSEC to be used. Thus I have a policy remote=CN -> use CN-SA works just fine, as long as MN is at home, with packets IP: dst=CN src=MN-home IPSEC(CN-SA) Payload Now, when MN moves away from home, one possibility is tunneling the packets via home agent. However, MN - HA path must also be protected by IPSEC. Thus the required packet leaving from MN must look IP: dst=HA src=MN-care IPSEC(HA-SA) IP: dst=CN src=MN-home IPSEC(CN-SA) Payload It just happens that I can generate above packet using existing IPSEC implementation by writing a policy (because it allows pretty random combination of IPSEC transforms) away-from-home and remote=CN -> use CN-SA, use HA-SA (tunnel=HA) at-home and remote=CN -> use CN-SA However, there is no hope for IKEv1 or IKEv2 to handle this. Manual keys work. (system will ask the two SA's with two separate ACQUIRE requests using PFKEYv2). I've been fairly happy with 2401 as is. I hope the flexibility that it allowed is not reduced too much to make things like in above non-standard. From owner-ipsec@lists.tislabs.com Wed Apr 9 16:08:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39N8HJM028002; Wed, 9 Apr 2003 16:08:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01883 Wed, 9 Apr 2003 18:36:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Wed, 9 Apr 2003 18:34:03 -0400 To: Markku Savela From: Stephen Kent Subject: Re: Question on SA Bundle Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markku, > > From: Stephen Kent > >> If folks think this is not the right path for 2401bis, let me know. > >In my understanding "bundle" is loose concept, e.g. in a policy I >could specify > > selector1 -> apply SA1(AH), apply SA2(ESP), apply SA2(ESP) > selector2 -> apply SA2(ESP) > >Bundle is just a set of IPSEC transformations (and SA's) that are >specified to be applied to a packet that maches a particular >selector. The same component SA can be used in different "bundles". I don't think the term bundle is all that vague. It is intended to specify how multiple IPsec protocols are to be applied to a single traffic flow, as defined by a single set of selectors. >That's about all that "bundle" means to me. Unfortunately, IKEv1 >thinks/requires more strict "bundle" concept. It cannot negotiate >individual SA's belonging to same "bundle" separately, or share SA's >between bundles. Yes, that's what I said. >Key management should negotiate SA's individually. In general I agree, but if we do that, and if we want to be able to support bundles, then we need to add complexity to IKE to be able to specify how multiple SAs relate to one another. In the general case, that seems to be messy, which is why I believe we probably ought not try to support this going forward, consistent with our overall attempt to simplify IPsec. >Speaking of bundles, I just currently trying examine how to get IPSEC >to work with MIPv6. > >Assume you have mobile node (MN) and correspondent node (CN), home >agent (HA). Assume CN is some service that requires IPSEC to be >used. Thus I have a policy > > remote=CN -> use CN-SA > >works just fine, as long as MN is at home, with packets > > IP: dst=CN > src=MN-home > IPSEC(CN-SA) > Payload > >Now, when MN moves away from home, one possibility is tunneling the >packets via home agent. However, MN - HA path must also be protected >by IPSEC. Thus the required packet leaving from MN must look > > IP: dst=HA > src=MN-care > IPSEC(HA-SA) > IP: dst=CN > src=MN-home > IPSEC(CN-SA) > Payload > >It just happens that I can generate above packet using existing IPSEC >implementation by writing a policy (because it allows pretty random >combination of IPSEC transforms) > > away-from-home and remote=CN -> use CN-SA, use HA-SA (tunnel=HA) > at-home and remote=CN -> use CN-SA > >However, there is no hope for IKEv1 or IKEv2 to handle this. Manual >keys work. (system will ask the two SA's with two separate ACQUIRE >requests using PFKEYv2). > >I've been fairly happy with 2401 as is. I hope the flexibility that it >allowed is not reduced too much to make things like in above >non-standard. Flexibility is good, except to the extent that it introduces complexity. I don't think flexibility is good if it serves primarily to allow non-interoperable implementations to claim conformance with a "flexible" standard. We have to be careful in that regard. Steve From owner-ipsec@lists.tislabs.com Wed Apr 9 16:42:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39NgEJM029454; Wed, 9 Apr 2003 16:42:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02088 Wed, 9 Apr 2003 19:15:06 -0400 (EDT) Date: Thu, 10 Apr 2003 02:19:05 +0300 (IDT) From: Hugo Krawczyk To: Paul Hoffman / VPNC cc: IPsec WG Subject: Re: draft-ietf-ipsec-ikev2-06.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 9 Apr 2003, Paul Hoffman / VPNC wrote: > At 10:46 AM -0400 4/8/03, David Jablon wrote: > >I too prefer "MUST", and I prefer "MUST NOT" in the addition. > > Could you explain the technical reason for that? If someone uses a > password instead of a sufficiently-random shared secret, will the PRF > break? > > We have no way of testing if someone has used a password vs. a shared > secret. If we say MUST and MUST NOT, we are saying that > implementations must somehow test for this. SHOULD and SHOULD NOT > (with the appropriate wording about the problems of passwords) seems > more realistic, but if there truly is a technical problem with using > a password in a PRF as Hugo has described, then we should know about > it. Let's answer this serious question with the following real life dialogue. Doctor: I have some bad news and some very bad news. Patient: Well, might as well give me the bad news first. Doctor: The lab called with your test results. They said you have 24 hours to live. Patient: 24 HOURS! That's terrible!! WHAT could be WORSE? What's the very bad news? Doctor: I've been trying to reach you since yesterday. In our case the bad news is that the prf's strength is now at most as the entropy of the password (typically < 32 bits). The weakness here is obvious: brute force attacks in 2^32 operations. The worse news is that some prf's may interact particularly bad with short keys. Think, for example, of an application using 3keys-3DES as the prf and a specification (as suggested in this list) to pad with 0s to the whole key length. If the key is given as an 8-character password then this is at best (even if the password is totally random) equivalent to single DES, against which you can use a "conventional" single-DES cracker. The worst news is that the exchange is open to off-line dictionary attacks no matter how you derive the key from the password (as long as this derivation does not use additional secret keys). In particular, this is the case when you use HMAC with a password. Hugo > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Wed Apr 9 16:45:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39Nj3JM029787; Wed, 9 Apr 2003 16:45:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02082 Wed, 9 Apr 2003 19:14:07 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <5.1.0.14.0.20030409151544.04582a30@pop.theworld.com> References: <5.1.0.14.0.20030408104652.00a37ec0@pop.theworld.com> <5.1.0.14.0.20030408104652.00a37ec0@pop.theworld.com> <5.1.0.14.0.20030409151544.04582a30@pop.theworld.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 9 Apr 2003 16:17:44 -0700 To: David Jablon , Charlie_Kaufman@notesdev.ibm.com From: Paul Hoffman / VPNC Subject: Re: draft-ietf-ipsec-ikev2-06.txt Cc: IPsec WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:57 PM -0400 4/9/03, David Jablon wrote: >I don't really want to debate the point of whether the text should *allow* for >the use of weakened Shared Secret keys. It sounds like you do. RFC 2119 has very specific definitions for SHOULD, SHOULD NOT, MUST, and MUST NOT. Saying "MUST NOT" has very different semantics than "SHOULD NOT do this because it is weak". I assume you are not proposing that we remove the normative reference to RFC 2119. If you are, that's a very different topic... > But it seems like the implications >need to be more clearly stated, and whether an implementation must allow >for full-strength keys is not addressed in the SHOULD version. > >Here's the proposed text in question: > >2(b)+: > "When pre-sharing a key for use in prf-based authentication > (i.e., Shared Secret") this key {SHOULD | MUST} be of the length > of the key for the prf agreed for use by the parties, and this key > {SHOULD NOT | MUST NOT} be derived solely from a password > or other data that has less randomness than a truly random key > of the appropriate length." > >At 09:47 AM 4/9/03 -0700, Paul Hoffman / VPNC wrote: >>At 10:46 AM -0400 4/8/03, David Jablon wrote: >>>I too prefer "MUST", and I prefer "MUST NOT" in the addition. >> >>Could you explain the technical reason for that? If someone uses a >>password instead of a sufficiently-random shared secret, will the >>PRF break? > >I think that's the wrong question, or at least I don't understand >how insufficiently random input can "break" a PRF. I don't either, that's why I asked. "MUST NOT" would indicate that it would break something, "SHOULD NOT" would indicate that the the something would work but probably not the way one would want. >But your first question forces me to elaborate my concern over the >SHOULD version. Using "SHOULD", the security of an implementation >may certainly be broken. And any relevant security proofs or arguments >that assume that keys are random will certainly not apply. I have never read a security proof, but if they rely on user-selected things like preshared keys to have a particularly amount of randomness, then they are not based on reality. No matter what you tell them, users will sometimes choose passwords or even non-password preshared secrets with less than 112/128 bits of randomness. They just will. We are designing IKEv2 for Internet users, not for people who write security proofs. Having said that, I obviously support telling users as well as we can what they should do to make their systems secure in the way that the security proof says it is. But that is quite different than mandating that IKEv2 systems have to check the randomness of the preshared key. >The text in draft 06 states that human-chosen password-derived >keys are insecure in this context but it doesn't fully explain why. We should obviously fix that. >(See proposed change below.) >Naively replacing key bytes with password bytes results in a >skewed distribution. Depending on how the password is chosen, >an N-byte password may have as little as 10% to 20% of the >randomness of an N-byte key. Just having the high bit of each >ASCII password byte set to zero guarantees at least a 12.5% loss. > >A good technical reason for saying MUST instead of SHOULD in 2(b)+ >is that SHOULD permits implementations that restrict ALL keys to >insecure length and/or insufficient randomness. That is not what RFC 2119 says for the difference between SHOULD and MUST. If you want us to redefine the words in RFC 2119, we can, but you can't both normatively reference RFC 2119 and use the argument above. > >We have no way of testing if someone has used a password vs. a >shared secret. ... > >Now that you mention it, there are surely some easy ways to detect >common causes for insufficient randomness. But I wasn't proposing >such a requirement. By using "MUST", you are. > >... If we say MUST and MUST NOT, we are saying that >implementations must somehow test for this. ... > >No. I don't think so. At least I didn't intend to. >It does (and should) say something about the design of the mechanism >for shared secret key entry, and for shared key selection (if any) --- >namely that they should not force or encourage the use of weakened keys. > >>... SHOULD and SHOULD NOT (with the appropriate wording about the >>problems of passwords) seems more realistic, but if there truly is >>a technical problem with using a password in a PRF as Hugo has >>described, then we should know about it. > >If we didn't know how passwords are different than keys, >and how our security assumptions require truly random keys, >then we should now. > >A little more wordsmithing would seem to be needed to fix the >technical problem with the SHOULD version of 2(b)+. >Even if weak keys are supported, it seems good to at least >require that implementations MUST *permit* the use of >full-strength keys, Ah, much better! There is an interoperability reason why they MUST: some systems designed for people who can't enter passwords if they tried will have preshared secrets that are long. > and { MUST | SHOULD } *encourage* the >use of full-strength keys. Now you are talking about the user interface, which most definitely is out of scope for this protocol document. If you want to write an implementation guide for IKEv2, this would obviously be appropriate there. >Also, one sentence in draft 06 should be expanded to better >distinguish the insecure practice from various other secure ways >of deriving shared secrets from combinations of passwords and keys. >Here's a suggested expansion: > > "Note that it is a common but [[ typically ]] insecure >practice to have a > shared key derived [[ solely ]] from a user chosen password[[, > without incorporating another source of randomness ]]." I would leave out the "typically": you simply don't see passwords with 112 or 128 bits of randomness. I don't agree with the final clause because we can't mandate that IKEv2 systems change the password on the user. Instead, you could say "In order to get preshared secrets with a sufficient amount of randomness, users typically need those preshared secrets supplied by systems that compute them." --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Apr 9 17:24:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A0OMJM004002; Wed, 9 Apr 2003 17:24:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02251 Wed, 9 Apr 2003 19:51:36 -0400 (EDT) Date: Thu, 10 Apr 2003 02:55:18 +0300 (IDT) From: Hugo Krawczyk To: "Theodore Ts'o" cc: IPsec WG Subject: Re: IKE V2 Open Issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > 1) Hugo's proposal to change legacy authentication to protect the > initiator's identity against active attacks. After looking at the > discussion, Barbara and I have concluded that the impacts of moving > around various protocol elements introduces numerous additional > complexities which will be hard to address at this late date. Russ > with his AD hat on set as the bar, "if the changes are the least bit > onerous, then this should not be done". We believe these changes meet > that test. objection! the above presentation of the complexity incurred by the changes needed to suport user's identity privacy (against active attackers) is inaccurate and misleading. The required changes are purely local to the EAP extension of ikev2 and do not touch global elements in the protocol nor they impact performance or any other aspect of an application/implementation not running the EAP extension (for example, if all we do is to move IDi to 5th message). Why misrepresents the facts when you have a much better reason to back your decision? As I wrote in a mesage yesterday, the right decision is indeed NOT to make these changes since (unfortunately) there were not enough supporters for them (in spite of these changes being non-onerous). > > 3) Uri's AES PRF proposal. The cryptographers are arguing amongst > themselves; we don't want to get involved. We suggest that the Crypto > group in the IRTF review it, and if they give us their blessing we can > standardize it in a separate standalone document. > The only part of the spec that raises any issues with providing a sufficiently long key to the prf is when using passwords as preshared keys. I respect the intent of Charlie not to outlaw the use of passwords in the protocol (especially that as Paul pointed out an implementation cannot verify the entropy of a key). Yet, let's not leave the protocol unspecified (e.g. when using prf's based on block ciphers) just because we cannot prevent this (bad) use by applications. The solution is (as I wrote in a note to charlie a few days ago): (1) require nonces to be long enough (at least half the length of the prf key) (2) require the preshared key to be of the length of the prf key. In particular, This is trivial to comply by the sharers (is there such a word?) of a pre-shared key as this pre-sharing is done off-line. In case of a password, the people responsible for this wrong use, should at least be able to convert the password (either if shorter or longer) into a string of the prf-key length (e.g., by hashing). Remember, that we are not talking here about legacy systems that have automated interface constraints. Legacy authentication is given a beautiful solution (up to user's id privacy of course :) in the EAP extension of ikev2! Hugo From owner-ipsec@lists.tislabs.com Wed Apr 9 18:25:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A1PIJM005849; Wed, 9 Apr 2003 18:25:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02604 Wed, 9 Apr 2003 20:49:23 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 9 Apr 2003 17:53:10 -0700 To: "Theodore Ts'o" , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Confirm decision on identity handling. Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 5:18 PM -0400 4/9/03, Theodore Ts'o wrote: >At the San Jose IETF, the IPSEC working group came to a rough >consensus (confirmed by a straw poll) to solve an interoperability >problem as follows: (quoting from the minutes) > >>Comment: Deal with this in 2401bis. Short term solution is to say that what >>goes in ID v CERT payload is a local matter for now. It need not match. >> >>Comment: SO we will put in sentence that ID payload is for policy lookup and >>does not need to match anything in CERT payload. Both fields may be used >>for access control decisions, but need not be correlated. 2-1 in favor. > >The consensus was relatively rough, and there was a desire expressed >by some to continue the discussion on the list. > >In order to move the discussion forward, we propose the following >addition to section 3.5 of the ikev2-06 as meeting the spirit of the >consensus which was developed in San Francisco. Append to the first >paragraph, which begins: > > The Identification Payload, denoted ID in this memo, allows peers to > assert an identify to one another. The ID Payload names the identity > to be authenticated with the AUTH payload. > >.. the following text: > > ... This identity is used for policy lookup, but does not > necessarily have to match anything in the CERT payload; both fields > may be used by an implementation to perform access control > decisions. The proposed addition is close, but doesn't match what many people were asking for in the San Francisco meeting, namely to let the use of the ID payload be a local option for the receiver. If you want to follow what those people asked for, the proposed addition must say "This identity may be used for ...". The sentence to which the new material is appended ("The ID Payload names the identity to be authenticated with the AUTH payload.") is now not correct. You can't authenticate something with a certificate that doesn't necessarily contain it. We are better off with just the first sentence and a revision of the one proposed here by Ted: The Identification Payload, denoted ID in this memo, allows peers to assert an identify to one another. This identity may be used for policy lookup, but does not necessarily have to match anything in the CERT payload; both fields may be used by an implementation to perform access control decisions. >The implication of this change, as was discussed in San Francisco, is >that it gives freedom to implementations to make more sophisticated >access control policies, where the responder might use the identity in >the ID payload to look up an access control list, and match the >subject name in the certificate against that ACL, for example. This >can be advantageous in that do not need to dictate the form of the >subject names in the certificate, which could promote the reuse of >certificates across multiple applications. The downside is that the >initiator must now allow the configuration of two pieces of >information; there is an additional configuration "knob" which must be >set correct in order for two peers to successfully ocmmunicate. No, there isn't. Sensible implementations will ignore the ID payload altogether and simply look for identities out of the certificate. That means there is one *less* knob to manage for the sender. The sending application can simply pick any identifier from the cert and send it in the ID payload. >There are other alternatives, which have been discussed in the past. >Two self-consistent and workable alternatives are presented here: > >2) Require that that IPSEC strictly define the types of X.509 >certificate subject names that would be accepted, and precisely define >the matching rules of the identity payload. This in effect would >predefine the access control policies in the system. One mechanism >for doing so can be found in section 3.2 of >draft-ietf-ipsec-pki-profile-02.txt. To say that the document "precisely defines the matching rules" is quite a stretch. It ignores commonly-used Subject OIDs, and gives conflicting SHOULD NOTs. >3) Specify that the ID payload must not be sent and/or is ignored when >using certificates to authenticate. In this case, the Certificate >subject name is used to lookup the policy information associated with >the SA instead of the contents identity payload. (This is essentially >very similar to a proposla contained in Paul Hoffman's >revised-identity I-D.) Not true. The draft explicitly did not say what to do with the identities in the certificate. The receiving system might take the Subject, or one or more of the SubjectAltNames, or might ignore the identities altogether and simply say "if the cert is valid and from a trusted root, I'll use it as the identifier, or other possible options. >These alternatives have tradeoffs: to differing degress, they >essentially limit flexibility in the choice of certificate names and >the name (identity) used to look up policy information. In the first >case, the choice of the name found in certificate is limited to >something which passes the matching rule defined in the pki-profile >I-D when the subject name or the subject alt name is matched against >the contents of the identity payload. In the second case, the name >used to look up the SA policy is constrained to be exactly the subject >name in the certificate, or perhaps the certificate itself. That is not true about the revised identity proposal. The name in the SA policy could be a certificate ID, a public key ID, a name from the SubjectAltName, or a combination. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Apr 10 04:38:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ABcDJM004732; Thu, 10 Apr 2003 04:38:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA03811 Thu, 10 Apr 2003 05:00:46 -0400 (EDT) Message-Id: <200304100905.h3A953of052008@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: Confirm Suites v. a la carte decision. In-reply-to: Your message of Wed, 09 Apr 2003 17:15:20 EDT. Date: Thu, 10 Apr 2003 11:05:03 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: At the San Jose IETF, the IPSEC working group came to consensus (confirmed by a straw poll) to switch back to using an ala carte ^^^ => is this not "a la" in place of "ala" (note: this comes from the French expression "a` la carte")? Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Apr 10 04:51:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ABpvJM005318; Thu, 10 Apr 2003 04:51:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA03838 Thu, 10 Apr 2003 05:18:45 -0400 (EDT) Message-Id: <200304100922.h3A9Mjof052062@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: IKE V2 Open Issues In-reply-to: Your message of Wed, 09 Apr 2003 17:14:46 EDT. Date: Thu, 10 Apr 2003 11:22:45 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: 2) Tero's proposal for a new source-address-changed notification payload. => note there is an older proposal. IMHO as the peer address can be changed using rekeying, there is no immediate need for a new payload (but if it can be done in time there is no need to wait). Unfortunately there is an immediate need to protect peer addresses, I propose to introduce two notifications modelled after NAT detection which will be included into all messages when NAT traversal is not active (a very simple way to solve the issue). We proposed in San Francisco that issues regarding address management be considered out of scope, and deferred to another working group. Tero's proposal is short and self-contained, hopefully non-controversial. If so, it seems reasonable to the wg chairs that it be included in ikev2. If there are any questions or debate over this item, however, we feel it should be defered to another working group. => Tero's and my proposals provide roughly the same thing. IMHO it will be more useful to use our free time to fix the NAT traversal text in the current draft (Tero sent some text but it was not included). 5) Lack of definition of the COOKIE_REQUIRED notify payload. Charlie's suggestion to delete the COOKIE_REQUIRED payload and simply to use the COOKIE payload is simple, and non-controversial. => I agree this is the simplest way to fix it! Thanks Francis.Dupont@enst-bretagne.fr PS: I'll send for Friday morning a complete set of little details to fix in the current draft. I believe the only controversial one could be about NAT traversal. From owner-ipsec@lists.tislabs.com Thu Apr 10 06:53:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ADrGJM013289; Thu, 10 Apr 2003 06:53:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04513 Thu, 10 Apr 2003 09:25:18 -0400 (EDT) Message-Id: <5.1.0.14.0.20030409151544.04582a30@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 09 Apr 2003 16:57:33 -0400 To: Paul Hoffman / VPNC , Charlie_Kaufman@notesdev.ibm.com From: David Jablon Subject: Re: draft-ietf-ipsec-ikev2-06.txt Cc: IPsec WG In-Reply-To: References: <5.1.0.14.0.20030408104652.00a37ec0@pop.theworld.com> <5.1.0.14.0.20030408104652.00a37ec0@pop.theworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, I don't really want to debate the point of whether the text should *allow* for the use of weakened Shared Secret keys. But it seems like the implications need to be more clearly stated, and whether an implementation must allow for full-strength keys is not addressed in the SHOULD version. Here's the proposed text in question: 2(b)+: "When pre-sharing a key for use in prf-based authentication (i.e., Shared Secret") this key {SHOULD | MUST} be of the length of the key for the prf agreed for use by the parties, and this key {SHOULD NOT | MUST NOT} be derived solely from a password or other data that has less randomness than a truly random key of the appropriate length." At 09:47 AM 4/9/03 -0700, Paul Hoffman / VPNC wrote: >At 10:46 AM -0400 4/8/03, David Jablon wrote: >>I too prefer "MUST", and I prefer "MUST NOT" in the addition. > >Could you explain the technical reason for that? If someone uses a password instead of a sufficiently-random shared secret, will the PRF break? I think that's the wrong question, or at least I don't understand how insufficiently random input can "break" a PRF. But your first question forces me to elaborate my concern over the SHOULD version. Using "SHOULD", the security of an implementation may certainly be broken. And any relevant security proofs or arguments that assume that keys are random will certainly not apply. The text in draft 06 states that human-chosen password-derived keys are insecure in this context but it doesn't fully explain why. (See proposed change below.) Naively replacing key bytes with password bytes results in a skewed distribution. Depending on how the password is chosen, an N-byte password may have as little as 10% to 20% of the randomness of an N-byte key. Just having the high bit of each ASCII password byte set to zero guarantees at least a 12.5% loss. A good technical reason for saying MUST instead of SHOULD in 2(b)+ is that SHOULD permits implementations that restrict ALL keys to insecure length and/or insufficient randomness. >We have no way of testing if someone has used a password vs. a shared secret. ... Now that you mention it, there are surely some easy ways to detect common causes for insufficient randomness. But I wasn't proposing such a requirement. >... If we say MUST and MUST NOT, we are saying that implementations must somehow test for this. ... No. I don't think so. At least I didn't intend to. It does (and should) say something about the design of the mechanism for shared secret key entry, and for shared key selection (if any) --- namely that they should not force or encourage the use of weakened keys. >... SHOULD and SHOULD NOT (with the appropriate wording about the problems of passwords) seems more realistic, but if there truly is a technical problem with using a password in a PRF as Hugo has described, then we should know about it. If we didn't know how passwords are different than keys, and how our security assumptions require truly random keys, then we should now. A little more wordsmithing would seem to be needed to fix the technical problem with the SHOULD version of 2(b)+. Even if weak keys are supported, it seems good to at least require that implementations MUST *permit* the use of full-strength keys, and { MUST | SHOULD } *encourage* the use of full-strength keys. Also, one sentence in draft 06 should be expanded to better distinguish the insecure practice from various other secure ways of deriving shared secrets from combinations of passwords and keys. Here's a suggested expansion: "Note that it is a common but [[ typically ]] insecure practice to have a shared key derived [[ solely ]] from a user chosen password[[, without incorporating another source of randomness ]]." -- David From owner-ipsec@lists.tislabs.com Thu Apr 10 06:53:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ADrfJM013310; Thu, 10 Apr 2003 06:53:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04466 Thu, 10 Apr 2003 09:21:13 -0400 (EDT) Message-ID: <3E94AF56.5080103@creeksidenet.com> Date: Wed, 09 Apr 2003 19:40:06 -0400 From: "jpickering@creeksidenet.com" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: "Theodore Ts'o" CC: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: Content-Type: multipart/alternative; boundary="------------030808090909000208060903" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------030808090909000208060903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I agree with the additional text, however, I would like to point out that such text in no way precludes an implementation (most likely down the road when(??) personal certs are ubiquitous) from insisting that id payload and cert ID match. The point is that there must be a mapping between ID in the payload and a public key to use for auth. The spec explicitly has not and should not put limits on how this mapping is performed. Jeff Theodore Ts'o wrote: > At the San Jose IETF, the IPSEC working group came to a rough > consensus (confirmed by a straw poll) to solve an interoperability > problem as follows: (quoting from the minutes) > >> Comment: Deal with this in 2401bis. Short term solution is to say that what >> goes in ID v CERT payload is a local matter for now. It need not match. >> >> Comment: SO we will put in sentence that ID payload is for policy lookup and >> does not need to match anything in CERT payload. Both fields may be used >> for access control decisions, but need not be correlated. 2-1 in favor. > > > The consensus was relatively rough, and there was a desire expressed > by some to continue the discussion on the list. > > In order to move the discussion forward, we propose the following > addition to section 3.5 of the ikev2-06 as meeting the spirit of the > consensus which was developed in San Francisco. Append to the first > paragraph, which begins: > > The Identification Payload, denoted ID in this memo, allows peers to > assert an identify to one another. The ID Payload names the identity > to be authenticated with the AUTH payload. > > ... the following text: > > ... This identity is used for policy lookup, but does not > necessarily have to match anything in the CERT payload; both fields > may be used by an implementation to perform access control > decisions. > > Discussion: > > The implication of this change, as was discussed in San Francisco, is > that it gives freedom to implementations to make more sophisticated > access control policies, where the responder might use the identity in > the ID payload to look up an access control list, and match the > subject name in the certificate against that ACL, for example. This > can be advantageous in that do not need to dictate the form of the > subject names in the certificate, which could promote the reuse of > certificates across multiple applications. The downside is that the > initiator must now allow the configuration of two pieces of > information; there is an additional configuration "knob" which must be > set correct in order for two peers to successfully ocmmunicate. > > There are other alternatives, which have been discussed in the past. > Two self-consistent and workable alternatives are presented here: > > 2) Require that that IPSEC strictly define the types of X.509 > certificate subject names that would be accepted, and precisely define > the matching rules of the identity payload. This in effect would > predefine the access control policies in the system. One mechanism > for doing so can be found in section 3.2 of > draft-ietf-ipsec-pki-profile-02.txt. > > 3) Specify that the ID payload must not be sent and/or is ignored when > using certificates to authenticate. In this case, the Certificate > subject name is used to lookup the policy information associated with > the SA instead of the contents identity payload. (This is essentially > very similar to a proposla contained in Paul Hoffman's > revised-identity I-D.) > > These alternatives have tradeoffs: to differing degress, they > essentially limit flexibility in the choice of certificate names and > the name (identity) used to look up policy information. In the first > case, the choice of the name found in certificate is limited to > something which passes the matching rule defined in the pki-profile > I-D when the subject name or the subject alt name is matched against > the contents of the identity payload. In the second case, the name > used to look up the SA policy is constrained to be exactly the subject > name in the certificate, or perhaps the certificate itself. > > The latter alternative in particular may impact some implementations > significantly, by changing the key used to look up and manage SA > policy information. > > Decision path: > > At the San Francisco meeting, there was clear (but rough) consensus to > explicitly specify that the contents of the ID payload do not have to > match the contents of the CERT payload, and which will require that > initiators have sufficient configuration controls to set both the ID and > Cert payloads. Proposed text which implements this rough conensus has > been included in this messange. > > Since the straw poll indicated that of the people in the room at San > Francisco, that people were 2-1 in favor of this choice, and this > chice should be considered the privileged or "default" choice. > However, especially given the roughness of the consensus there, this > decision must be confirmed on the mailing list. People who believe > that one of the above alternatives, or some other alternative, should > be adopted instead, are encouraged to speak up. > > > > --------------030808090909000208060903 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

I agree with the additional text, however, I would like to point out that such text in no
way precludes an implementation (most likely down the road when(??) personal certs
are ubiquitous) from insisting that id payload and cert ID match. The point is that there
must be a mapping between ID in the payload and a public key to use for auth. The spec
explicitly has not and should not put limits on how this mapping is performed.

Jeff

Theodore Ts'o wrote:
At the San Jose IETF, the IPSEC working group came to a rough
consensus (confirmed by a straw poll) to solve an interoperability
problem as follows:  (quoting from the minutes)

Comment: Deal with this in 2401bis. Short term solution is to say that what
goes in ID v CERT  payload is a local matter for now. It need not match.

Comment: SO we will put in sentence that ID payload is for policy lookup and
does not need to  match anything in CERT payload. Both fields may be used
for access control decisions, but need not be correlated. 2-1 in favor.

The consensus was relatively rough, and there was a desire expressed
by some to continue the discussion on the list.  

In order to move the discussion forward, we propose the following
addition to section 3.5 of the ikev2-06 as meeting the spirit of the
consensus which was developed in San Francisco.  Append to the first
paragraph, which begins:

   The Identification Payload, denoted ID in this memo, allows peers to
   assert an identify to one another. The ID Payload names the identity
   to be authenticated with the AUTH payload.

... the following text:

   ... This identity is used for policy lookup, but does not
   necessarily have to match anything in the CERT payload; both fields
   may be used by an implementation to perform access control
   decisions.

Discussion:

The implication of this change, as was discussed in San Francisco, is
that it gives freedom to implementati!
 ons to make more sophisticated
access control policies, where the responder might use the identity in
the ID payload to look up an access control list, and match the
subject name in the certificate against that ACL, for example.  This
can be advantageous in that do not need to dictate the form of the
subject names in the certificate, which could promote the reuse of
certificates across multiple applications.  The downside is that the
initiator must now allow the configuration of two pieces of
information; there is an additional configuration "knob" which must be
set correct in order for two peers to successfully ocmmunicate.

There are other alternatives, which have been discussed in the past.
Two self-consistent and workable alternatives are presented here: 

2) Require that that IPSEC strictly define the types of X.509
certificate subject names that would be accepted, and precisely define
the matching rules of the identity p!
 ayload.  This in effect would
predefine the access control policies
 in the system.  One mechanism
for doing so can be found in section 3.2 of
draft-ietf-ipsec-pki-profile-02.txt.   

3) Specify that the ID payload must not be sent and/or is ignored when
using certificates to authenticate.  In this case, the Certificate
subject name is used to lookup the policy information associated with
the SA instead of the contents identity payload.  (This is essentially
very similar to a proposla contained in Paul Hoffman's
revised-identity I-D.)  

These alternatives have tradeoffs: to differing degress, they
essentially limit flexibility in the choice of certificate names and
the name (identity) used to look up policy information.  In the first
case, the choice of the name found in certificate is limited to
something which passes the matching rule defined in the pki-profile
I-D when the subject name or the subject alt name is matched against
the contents of the identity payload.  In the second case, t!
 he name
used to look up the SA policy is constrained to be exactly the subject
name in the certificate, or perhaps the certificate itself.

The latter alternative in particular may impact some implementations
significantly, by changing the key used to look up and manage SA
policy information.  

Decision path:

At the San Francisco meeting, there was clear (but rough) consensus to
explicitly specify that the contents of the ID payload do not have to
match the contents of the CERT payload, and which will require that
initiators have sufficient configuration controls to set both the ID and
Cert payloads.  Proposed text which implements this rough conensus has
been included in this messange.

Since the straw poll indicated that of the people in the room at San
Francisco, that people were 2-1 in favor of this choice, and this
chice should be considered the privileged or "default" choice.
However, especially given the r!
 oughness of the consensus there, this
decision must be confirmed on
 the mailing list.  People who believe
that one of the above alternatives, or some other alternative, should
be adopted instead, are encouraged to speak up.





--------------030808090909000208060903-- From owner-ipsec@lists.tislabs.com Thu Apr 10 06:53:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ADrfJM013311; Thu, 10 Apr 2003 06:53:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04459 Thu, 10 Apr 2003 09:20:16 -0400 (EDT) Message-Id: <4.3.2.7.2.20030409114742.02bb8698@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Apr 2003 11:50:43 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: Re: March 2003 IETF WG Minutes Cc: byfraser@cisco.com, tytso@mit.edu In-Reply-To: <4.3.2.7.2.20030408181513.0258f548@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_523612==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_523612==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed It appears there are two different deadlines for submission to the proceedings on the IETF web site. I saw the April 14th date but there is an earlier one, April 11. I plan to submit the minutes before the April 11 deadline so please get any corrections to me in the next couple of days. thanks, Barb At 06:18 PM 4/8/2003, Barbara Fraser wrote: >Here are the minutes from the working group meeting last month. Please >send any corrections to me by April 11 so that we can submit them by the >April 14 due date. Special thanks to Jesse for taking such detailed notes >during the meeting. > >Barb >===================================== >IPsec Working Group Minutes >March 2003 IETF, San Francisco, CA >Recorded by: Jesse Walker > >1. Agenda bashing > >Agenda accepted without change. > >2. A word from the ADs > >Russ Housley: Let's get it done. Oscillating on mail list. If it is in >document, don't change it unless it is breaking something. > >3. Draft status > >Barbara Fraser: > >modp group completed last call, RFC editor queue > >aes xcbc-mac completed last call, waiting for IESG >aes-cbc completed last call, waiting for AD writeup >sctp completed, kicked back from IESG, but they had wrong version; being >rereviewed >ESP, 2402bis esn ready for last call > >nat traversal ready for last call >MIB documents ready for last call, but can't find them > >Dead Peer Detection document ready for last call > >IKEv2 coming to closure? >IKEv2 tutorial > >4. Update on ESP, AH, 2401 > >Steve Kent: > >ESP & AH changes: revised identification text to better accommodate >multicast; clarified anti-replay requirements for multicast; moved >discussion of when to use tunnel and transport mode to 2401bis > >Q: Remove mandatory algorithm references from AH & ESP? No response. > >SA identification: unicast, SPI is sufficient. Multicast: should support >demuxing based on SPI & dest addr, optionally use source addr too. Now SAD >flags to cover unicast and multicast: SPI only, SPI + destination addr, SPI >+ dest addr + src addr > >Q: What about protocol field in multicast case? > >Anti-replay: transmitter always increments; receiver can ignore it. Receiver >should tell transmitter to ignore seq counter wrap-around if not going to >perform anti-replay check. > >2401bis: reconciling with IKEv2 selector, relaxing specs on when to use >tunnel v. transport; add forwarding/routing lookup prior to SPD lookup. > >Q: remove mandatory algorithm references? > >Comment: Forwarding lookup also must return next hop address. > >Q: Ready for last call? > >Comment: If aligning 2401bis with IKEv2, does this mean it won't work with >IKEv1? Answer: There are new SPD entries can't negotiate with IKEv1. >Comment: That is a real issue. Since adding lots of valuable things, it >might behoove us to find a way to construct an IKEv1 profile. Answer: it's >ESP/AH that are ready to move forward, not 2401bis. > >5. High Level Interop > >There was a miscommunication between the working group chairs. This topic >should not have been on the agenda. > >6. Backend Config Payload handling > >Greg Lebovitz/Darren Dukes (Darren presents): > >Use backend server to assign IP address. > >IRAC Config Problem -- IPsec remote access client needs private IP address >before creating child SAs. How? > >Config Payload -- allow config payload to do this. Put config payload in >IKE-AUTH exchange messages 3 and 4. Can backend with your favorite server. > >On-IRAS Pools -- not scalable but work for small deployment > >Off-IRAS Pools -- offload onto backend server; scales better: use DHCP, >RADIUS or other backend server > >Requirements: be able to use DHCP, RADIUS and LDAP to get addresses. > >Question: Not suggesting changes to IKEv2? Answer: No, augments IKEv2 using >IKEv2 mechanisms. > >7. IKE DHCP encapsulation > >Michael Richardson: > >Requirements: no new namespaces, provide client with info it needs; minimize ># of exchanges; interfaces to existing infrastructure; preserves end-to-end >security of DHCP; permit independent DHCP evolution. > >Three methods: DHCP-over-IPsec; ModeCFG over IKE; proposed DHCP over IKE > >DHCP-over IPsec: product of IPSRA; easy for bump-in-stack, all-in-one >gateway; leverages existing DHCP server > >ModeCFG: occurs in IKE msg 3, uses custom payload; if you need DHCP info, do >it over IPsec; easy to interface to RADIUS/COPS/DHCP > >Why bother? DHCP the defacto standard; don't reinvent > >DHCP-over-IKE v. over IPsec: creating 0/0 tunnel is hard when crypto >offloaded; client systems without virtual i/fs cannot do this easily; may >have to leave 0/0 SA around for renewals > >DHCP-over-IKE v. ModeCFG: same as DHCP-over-IKE, except format bits; ModeCFG >needs an IKE 1.5 exchange; DHCP-over-IKE preserves client-server security; >extensible; plugs into RADIUS/COPS with mini-DHCP server/proxy; talks to >real DHCP server with no glue > >8. IKEv2 issues > >Ted Ts'o: > >Posted open issues last call to determine how far away from getting IKEv2 >out the door. > >Time to shoot the engineers and ship the product: if not broken, don't fix; >some recently introduced problems should be remanded to an IKEv2 extensions >WG; otherwise will suffer scope creep > >What's left: AH and ESPbis; 2401bis; then we can shut down! Want to finish >this year. > >Issues recently resolved: Secure legacy authentication; cipher suites >document needed--Jeff Schiller has volunteered; Hugo's key derivation >objections; suites v. a la carte; Charlie's question about IKE suite #5. > >Issues recently discussed (no closure): Multiple tunnels for QoS; multiple >tunnels for outsourced VPNs; mobility peer address management; kill >me-Tarzan-you-Jane; revised identity; DHCP v. config payload. > >Outsourced VPNs: is this important to handle now? Solutions exist that >require no changes to the draft > >Mobility peer addr mgmt: support for changing IP addresses during SA >lifetime. Important now? assertion: move this into separate WG. > >Comment: Defect in current draft about IP address. Can move this to another >WG. Charlie: if clarifications to existing text, please send suggested text >and section changes apply to. > >Comment: Combine NAT traversal, mobility? Ted: Don't see how the two are >related. > >Comment (Mark Duffy): Include VPN ID in IKEv2. Within PPP have ways to >discover identities of VPN members. VPN ID will facilitate this within >IPsec. > >Comment: Suites v. a la carte: no idea what to do to support legacy >combinations that aren't in a defined suite. Can't use IKEv2 with these. >Want to auto-upgrade configuration, but can't. Response: It will have to be >allowed to use both suites and a la carte. We will leave IKEv1 customers as >IKEv1 until they can upgrade. > >Comment (Dan Harkins): Will have to double suites because no way to indicate >PFS. Ted: Don't understand. > >Comment: If we go with suites, consider what other WGs have called out as >mandatory to implement. > >Comment (Charlie Kaufman): You can identify suite you want with vendor ID if >single vendor; if multiple vendors want this, then they can ask for this to >be added to suites document. Diffie-Hellman group is part of the suite. > >Comment: Let's propose suite for every combination possible in IKEv1. > >Comment (Paul Hoffman): Everyone in IKEv1 has GUI that lets them pick what >they want. No consistent defaults. People are really using DES, because it >is mandatory to implement in IKEv1. Upgrade cannot be direct, because we >won't support DES going forward. > >Comment: Need more active discussion on peer addresses than just a few >comments, or we won't handle the problem. > >Comment (Radia Perlman): Curious whether there is passion behind suites? >Charlie: Only losing side shows up. Ted: 80% of room in Atlanta wanted >suites. Charlie: heard requirement to negotiate any combination in IKEv1. >Russ: Charlie's story: two bales of hay and a donkey. Donkeys are not too >dumb not to decide which to eat from. > >Comment: WG list came to consensus with a la carte suites. VPNID is just >another name, and we don't need to do anything about it. Just agree upon a >name; just use them. > >Comment: (Paul Hoffman) 80% people speaking did not support suites, but the >vote was 80%. Developers more evenly split on a la carte. > >Comment: v1 has a la carte, and it ain't broke > >Comment: What happened to discussion about GUIs? > >Charlie: Asked a la carte party which a la carte they want. The question of >"ands" and "ors" has to be addressed. Changing is tiresome. There is always >consensus we can make it better > >Uri: main reason to have a la carte is it is simpler. main reason to have >suites is it is analyzable. This is the main reason to select a la carte. > >Comment: In the protocol define as a la carte but draft 3 suites. This gives >benefits of both. 3 is the right number for interoperability testing. > >Charlie: Can do this; a la carte text is escrowed. > >Ted: We don't want to debate this one. Current draft: 5; some form of a la >carte: 25; some form of a la carte in v2 '02 draft v v1 encoding scheme: >unanimous in favor of v2 '02. > >Ted: we need to lock this decision in stone. > >Ted: Want consensus that we won't do QoS, outsourced VPN, mobility support >in a new WG. Everyone agrees. > >9. Kill off me-Tarzan-you-Jane: > >argument for: initiator id sufficient to demux multiple VPNs. > >Comment: But this is not a problem for VPNs. It is a problem for end-to-end >use. Don't know what it means to remove it. > >Comment: Right. Keep me-Tarzan-you-Jane, because useful outside of VPN. > >Comment: But do we need two different payloads to do same thing? What we >need to kill off is optional ID payload. > >Comment: No. The way the initiator wants to refer to responder identity >might not be a raw key. Better to use identity name space rather than key >name space. Need to keep identity across key roll-over. > >Comment: Can't use CERTREQ with anything other than PKIX signing certs. > >Comment: But then why do we have these other types? > >Comment: Other types need to be specified; no semantics for them. > >Comment: Can express remote identity by certificate you want to receive. You >will get that certificate. We will always do this, so always pass >certificate chains. We won't get the performance optimization we thought. >We need a bit saying whether the ID payload refers to requestor or >responder. Requirement to specify remote end is a non-negotiable >requirement. CERTREQ is for getting certs. This is premature optimization. > >Charlie: There is confusion. Me-Tarzan-You-Jane solves one problem, but >people try to solve other problems, but doesn't work there, so want to >remove it. If you don't use it to solve the wrong problem, it is fine and >shouldn't be used. > >Comment (Derek Atkins): Keep what's there. > >Comment (Dan Harkins): Payload is not non-critical. It is a mandatory >option. The problem it solves is never stated. > >Ted: How many believe current language be kept? Removed? Don't care? Vote >was to keep it. If you want it clarified, send text to Charlie. > >10. Revised identity > >Is there anything left to do? > >Paul Hoffman: Charlie clarified when to send cert. Only open issue is to >define what identity means. Do we want to clarify this? > >Comment: Tarzan-Jane discussion arose because of no identity notion. > >Comment: We don't know how to build certificates for IKE. We can't change >PKIX. Does ID payload contents need to match something in CERT payload? Can >solve this problem with one sentence. Need to make this explicit to close >this issue. > >Charlie: Devil is in details. Yes they have to match, but we don't know what >matching means. > >Ted: In Kerberos, you specify name, ticket, and access control check. This >problem is never addressed in Kerberos. Similarly in SSH. Because of Cert >structure, people think they don't have to check access control list but >rather only check some magical field in cert. Interop problems arise from >this. Draft haven't done this. > >Paul: Can't decide this in IKEv2 timeframe. Let's defer it. > >Comment: Don't want to go through same as last 4 years. > >Comment: There are implementations that check ACL. Name is just a hint to >find right key. People are looking for way to contact random machine and >make decisions. > >Steve Kent: Agree with Paul; too complicated to get resolved. There is an >ACL; it is the SPD. Problem people run into is we haven't nailed down SPD >syntax well enough to remove these problems. Intent was precisely to >establish entries in form that cert will map to SPD entries. This is a >2401bis problem > >Comment: Two issues: access policy, which is user's decision. >Interoperability problems because of configuration. Not trying to solve >these problems which is protocol interoperability. What we need to insure >is protocol interoperability: do you have to match something in cert to >something in ID payload or not. > >Comment: Try: "after you have authenticated the dude on the other end, you >MUST decide whether this matches the access control criteria on your end." > >Comment: Deal with this in 2401bis. Short term solution is to say that what >goes in ID v CERT payload is a local matter for now. It need not match. > >Comment: SO we will put in sentence that ID payload is for policy lookup and >does not need to match anything in CERT payload. Both fields may be used >for access control decisions, but need not be correlated. 2-1 in favor. > >Steve Kent: Don't think this clarifies anything, other than allows a vendor >to claim compliance. It doesn't solve the problem. > >Ted: alternate proposal? > >Paul Hoffman: Do this on the list. What implementers claim their >implementations do doesn't match debug log. > >Comment: We have opened can of worms best closed on list. > >11. DHCP v. CFG payload > >Summary: Both solutions are technically workable. IKEv2-05 allows server to >refuse CFG request and uses fallback to 3456bis. DHCP encapsulation within >IKE recent submission. > >DHCP encapsulation might be suitable compromise, but not fleshed out. If >consensus in WG to pursue this new idea, give them limited time, then >decide to fallback to IKEv2-05. If people want 3456bis, give people short >time to produce text, otherwise fall back to IKEv2-05 CFG payload. 5 or 6 >happy with current, 3 or 4 unhappy. > >Comment: growth of DHCP indicates configuration is a hard problem; let >someone solve it. That speaks to just reusing DHCP. Don't reinvent the >wheel; just use DHCP. Pursue this with a reasonable timeout with fallback. > >Comment: CFG payload has fallback mechanism built in for implementations >that want to do something else. Keep CFG payload as is to allow DHCP or >whatever else. > >Comment: Getting into trouble with IPv6. Already have several, creating yet >another one. > >Comment: DHCP INFORM gives options not given by CFG payload. This would >satisfy problems. Yeah; we do need to think more about v6. > >Comment: Makes sense to give DHCP 3 weeks to flesh out document. > >Comment: DHCP is still evolving. CFG payload would not allow use of DHCP >end-to-end security. In many cases DHCP options influence address >assignment, so need this information before CFG payload. Better to restrict >ourselves to one way. > >Comment: Alternative scenario. Authentication might influence address >assignment. Push to restrict this to bootstrap and not generalize it. DHCP >is not interoperable in terms of options. > >Comment: Not clear how DHCP will work with RADIUS or LDP; CFG option >superior for this. > >Comment: Security Gateway acts as proxy for client; it is responsible for >authentication. > >Comment: But this is not end-to-end. > >Comment: In DHCP-over-IKE, Server is DHCP relay, not a proxy. There are >proposals to carry EAP within DHCP, too. While server does have to >interpret DHCP bits, we don't want it to modify them. > >Ted: Seems to be a number of people speaking in favor of allowing >DHCP-over-IKE 3 weeks. Strong interest in pursuing this? > >Comment: in 3 weeks we will compare. Need a few days specifying what >scenarios have to be addressed. > >Comment: More problems being raised now that there is a proposal. IKEv1 was >successful because (1) there was a freeware implementation as a starting >point and (2) we did interoperability testing before going to RFC. We are >not ready to go to RFC, because we have neither of these. The nature of the >market is people will believe there is interoperability because it is an >RFC. Need to have something more baked. Need to have a bakeoff first. Need >to seriously consider doing so before going to RFC. > >Ted: Problem space WG says we should go to proposed standard sooner. From >process viewpoint, we need some way to prevent flip-flop, so implementers >can implementers. > >Comment: Flip-flop occurs because we don't understand problem. > >Comment: We haven't started IKEv2 implementation. It would be good to have a >discussion about this to express opinion about draft. > >Ted: Let's close on DHCP first before talking about this. Sense of room to >try DHCP-within-IKE for 3 weeks and fallback to CFG payload if this doesn't >pan out. > >Comment: There are a lot of ModeCFG in IKEv1. CFG payload is near to this, >so there will have to be new code and understanding. > >Straw vote: CFG payload, DHCP-within-IKE with fallback, something else: >10-14-0. Too close to call; take it to the list. > >Comment: Let's have straw vote in 3 weeks. > >Ted: Michael Richardson is the stuckee. We want to get draft ready for WG >last call by April 15. Goal to publish this as an RFC before Austria IETF. >Issue is whether baking occurs for draft standard or proposed standard. We >need to have draft locked down, however. > >Comment: what happens with 2401bis? Do we want to divorce IKEv2 from >2401bis? are there linkages? > >Ted: Should we publish IKEv2 and 2401bis simultaneous or in serial. > >Comment: They should be "simultaneous" > >Ted: That's what we did with IKEv1, but caused problems because there were >12 docs. > >Comment: The hairball is not as large this time. Not convinced we have >thought through problems we have solved. > >Comment: Sympathize, but we should try the IETF thing. This is a better >goal. > >Comment: Companies are under travel restrictions. we should make bakeoff >affordable and easy to get to. > --=====================_523612==_.ALT Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by edison.cisco.com id LAA29354 It appears there are two different deadlines for submissio= n to the proceedings on the IETF web site. I saw the April 14th date but there is an earlier one,  April 11. I plan to submit the minutes before the April 11 deadline so please get any corrections to me in the next couple of days.

thanks,
Barb

At 06:18 PM 4/8/2003, Barbara Fraser wrote:
Here are the minutes from the working group meeting last month. Please send any corrections to me by April 11 so that we can submit them by the April 14 due date. Special thanks to Jesse for taking such detailed notes during the meeting.

Barb
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IPsec Working Group Minutes
March 2003 IETF, San Francisco, CA
Recorded by: Jesse Walker

1. Agenda bashing

Agenda accepted without change.

2. A word from the ADs

Russ Housley: Let's get it done. Oscillating on mail list. If it is in
document, don't change  it unless it is breaking something.

3. Draft status

Barbara Fraser:

modp group completed last call, RFC editor queue

aes xcbc-mac completed last call, waiting for IESG
aes-cbc completed last call, waiting for AD writeup
sctp completed, kicked back from IESG, but they had wrong version; being
rereviewed
ESP, 2402bis esn ready for last call

nat traversal ready for last call
MIB documents ready for last call, but can't find them

Dead Peer Detection document ready for last call

IKEv2 coming to closure?
IKEv2 tutorial

4. Update on ESP, AH, 2401

Steve Kent:

ESP & AH changes: revised identification text to better accommodate
multicast; clarified  anti-replay requirements for multicast; moved
discussion of when to use tunnel and transport  mode to=20 2401bis

Q: Remove mandatory algorithm references from AH & ESP? No response.

SA identification: unicast, SPI is sufficient. Multicast: should support
demuxing based on SPI  & dest addr, optionally use source addr too. Now SAD
flags to cover unicast and multicast: SPI  only, SPI + destination addr, SPI
+ dest addr + src addr

Q: What about protocol field in multicast case?

Anti-replay: transmitter always increments; receiver can ignore it. Receiver
should tell  transmitter to ignore seq counter wrap-around if not going to
perform anti-replay check.

2401bis: reconciling with IKEv2 selector, relaxing specs on when to use
tunnel v. transport;  add forwarding/routing lookup prior to SPD lookup.

Q: remove mandatory algorithm references?

Comment: Forwarding lookup also must return next hop address.

Q: Ready for last call?

Comment: If aligning 2401bis with IKEv2, does this mean it won't work with
IKEv1? Answer:  There are new SPD entries can't negotiate with IKEv1.
Comment: That is a real issue. Since  adding lots of valuable things, it
might behoove us to find a way to construct an IKEv1  profile. Answer: it's
ESP/AH that are ready to move forward, not 2401bis.

5. High Level Interop

There was a miscommunication between the working group chairs. This topic should not have been on the agenda.

6. Backend Config Payload  handling

Greg Lebovitz/Darren Dukes (Darren presents):

Use backend server to assign IP address.

IRAC Config Problem -- IPsec remote access client needs private IP address
before creating  child SAs. How?

Config Payload -- allow config payload to do this. Put config payload in
IKE-AUTH exchange  messages 3 and 4. Can backend with your favorite server.

On-IRAS Pools -- not scalable but work for small deployment

Off-IRAS Pools -- offload onto backend server; scales better: use DHCP,
RADIUS or other  backend server

Requirements: be able to use DHCP, RADIUS and LDAP to get=20 addresses.

Question: Not suggesting changes to IKEv2? Answer: No, augments IKEv2 using
IKEv2 mechanisms.

7. IKE DHCP encapsulation

Michael Richardson:

Requirements: no new namespaces, provide client with info it needs; minimize
# of exchanges;  interfaces to existing infrastructure; preserves end-to-end
security of DHCP; permit independent  DHCP evolution.

Three methods: DHCP-over-IPsec; ModeCFG over IKE; proposed DHCP over IKE

DHCP-over IPsec: product of IPSRA; easy for bump-in-stack, all-in-one
gateway; leverages  existing DHCP server

ModeCFG: occurs in IKE msg 3, uses custom payload; if you need DHCP info, do
it over IPsec;  easy to interface to RADIUS/COPS/DHCP

Why bother? DHCP the defacto standard; don't reinvent

DHCP-over-IKE v. over IPsec: creating 0/0 tunnel is hard when=20 crypto
offloaded; client systems  without virtual i/fs cannot do this easily; may
have to leave 0/0 SA around for renewals

DHCP-over-IKE v. ModeCFG: same as DHCP-over-IKE, except format bits; ModeCFG
needs an IKE 1.5  exchange; DHCP-over-IKE preserves client-server security;
extensible; plugs into RADIUS/COPS  with mini-DHCP server/proxy; talks to
real DHCP server with no glue

8. IKEv2 issues

Ted Ts'o:

Posted open issues last call to determine how far away from getting IKEv2
out the door.

Time to shoot the engineers and ship the product: if not broken, don't fix;
some recently  introduced problems should be remanded to an IKEv2 extensions
WG; otherwise will suffer scope  creep

What's left: AH and ESPbis; 2401bis; then we can shut down! Want to finish
this year.

Issues recently resolved: Secure legacy authentication; cipher suites
document needed--Jeff  Schiller has volunteered; Hugo's key derivation
objections; suites v. a la carte; Charlie=92s  question about IKE suite #5.

Issues recently discussed (no closure): Multiple tunnels for QoS; multiple
tunnels for  outsourced VPNs; mobility peer address management; kill
me-Tarzan-you-Jane; revised identity;  DHCP v. config payload.

Outsourced VPNs: is this important to handle now? Solutions exist that
require no changes to  the draft

Mobility peer addr mgmt: support for changing IP addresses during=20 SA
lifetime. Important now?  assertion: move this into separate WG.

Comment: Defect in current draft about IP address. Can move this to another
WG. Charlie: if  clarifications to existing text, please send suggested text
and section changes apply to.

Comment: Combine NAT traversal, mobility? Ted: Don't see how the two are
related.

Comment (Mark Duffy): Include VPN ID in IKEv2. Within PPP have ways to
discover identities of  VPN members. VPN ID will facilitate this within
IPsec.

Comment: Suites v. a la carte: no idea what to do to support legacy
combinations that aren't  in a defined suite. Can't use IKEv2 with these.
Want to auto-upgrade configuration, but can't.  Response: It will have to be
allowed to use both suites and a la carte. We will leave IKEv1  customers as
IKEv1 until they can upgrade.

Comment (Dan Harkins): Will have to double suites because no way to indicate
PFS. Ted: Don't  understand.

Comment: If we go with suites, consider what other WGs have called out as
mandatory to  implement.

Comment (Charlie Kaufman): You can identify suite you want with vendor ID if
single vendor; if  multiple vendors want this, then they can ask for this to
be added to suites document.  Diffie-Hellman group is part of the suite.

Comment: Let's propose suite for every combination possible in IKEv1.

Comment (Paul Hoffman): Everyone in IKEv1 has GUI that lets them pick what
they want. No  consistent defaults. People are really using DES, because it
is mandatory to implement in  IKEv1. Upgrade cannot be direct, because we
won't support DES going forward.

Comment: Need more active discussion on peer addresses than just a few
comments, or we won't  handle the problem.

Comment (Radia Perlman): Curious whether there is passion behind suites?
Charlie: Only losing  side shows up. Ted: 80% of room in Atlanta wanted
suites. Charlie: heard requirement to  negotiate any combination in IKEv1.
Russ: Charlie's story: two bales of hay and a donkey.  Donkeys are not too
dumb not to decide which to eat from.

Comment: WG list came to consensus with a la carte suites. VPNID is just
another name, and we  don't need to do anything about it. Just agree upon a
name; just use them.

Comment: (Paul Hoffman) 80% people speaking did not support suites, but the
vote was 80%.  Developers more evenly split on a la carte.

Comment: v1 has a la carte, and it ain't broke

Comment: What happened to discussion about GUIs?

Charlie: Asked a la carte party which a la carte they want. The question of
"ands" and "ors"  has to be addressed. Changing is tiresome. There is always
consensus we can make it better

Uri: main reason to have a la carte is it is simpler. main reason to have
suites is it is  analyzable. This is the main reason to select a la carte.

Comment: In the protocol define as a la carte but draft 3 suites. This gives
benefits of both.  3 is the right number for interoperability testing.

Charlie: Can do this; a la carte text is escrowed.

Ted: We don't want to debate this one. Current draft: 5; some form of a la
carte: 25; some  form of a la carte in v2 '02 draft v v1 encoding scheme:
unanimous in favor of v2 '02.

Ted: we need to lock this decision in stone.

Ted: Want consensus that we won't do QoS, outsourced VPN, mobility support
in a new WG.  Everyone agrees.

9. Kill off me-Tarzan-you-Jane:

argument for: initiator id sufficient to demux multiple VPNs.

Comment: But this is not a problem for VPNs. It is a problem for end-to-end
use. Don't know  what it means to remove it.

Comment: Right. Keep me-Tarzan-you-Jane, because useful outside of VPN.

Comment: But do we need two different payloads to do same thing? What we
need to kill off is  optional ID payload.

Comment: No. The way the initiator wants to refer to responder identity
might not be a raw  key. Better to use identity name space rather than key
name space. Need to keep identity  across key roll-over.

Comment: Can't use CERTREQ with anything other than PKIX signing certs.

Comment: But then why do we have these other types?

Comment: Other types need to be specified; no semantics for them.

Comment: Can express remote identity by certificate you want to receive. You
will get that  certificate. We will always do this, so always pass
certificate chains. We won't get the  performance optimization we thought.
We need a bit saying whether the ID payload refers to  requestor or
responder. Requirement to specify remote end is a non-negotiable
requirement.  CERTREQ is for getting certs. This is premature optimization.

Charlie: There is confusion. Me-Tarzan-You-Jane solves one problem, but
people try to solve  other problems, but doesn't work there, so want to
remove it. If you don't use it to solve the  wrong problem, it is fine and
shouldn't be used.

Comment (Derek Atkins): Keep what's there.

Comment (Dan Harkins): Payload is not non-critical. It is a mandatory
option. The problem it  solves is never stated.

Ted: How many believe current language be kept? Removed? Don't care? Vote
was to keep it. If  you want it clarified, send text to Charlie.

10. Revised identity

Is there anything left to do?

Paul Hoffman: Charlie clarified when to send cert. Only open issue is to
define what identity  means. Do we want to clarify this?

Comment: Tarzan-Jane discussion arose because of no identity=20 notion.

Comment: We don't know how to build certificates for IKE. We can't change
PKIX. Does ID  payload contents need to match something in CERT payload? Can
solve this problem with one  sentence. Need to make this explicit to close
this issue.

Charlie: Devil is in details. Yes they have to match, but we don't know what
matching means.

Ted: In Kerberos, you specify name, ticket, and access control check. This
problem is never  addressed in Kerberos. Similarly in SSH. Because of Cert
structure, people think they don't  have to check access control list but
rather only check some magical field in cert. Interop  problems arise from
this. Draft haven't done this.

Paul: Can't decide this in IKEv2 timeframe. Let's defer it.

Comment: Don't want to go through same as last 4 years.

Comment: There are implementations that check ACL. Name is just a hint to
find right key.  People are looking for way to contact random machine and
make decisions.

Steve Kent: Agree with Paul; too complicated to get resolved. There is an
ACL; it is the SPD.  Problem people run into is we haven't nailed down SPD
syntax well enough to remove these  problems. Intent was precisely to
establish entries in form that cert will map to SPD entries.  This is a
2401bis problem

Comment: Two issues: access policy, which is user's decision.
Interoperability problems  because of configuration. Not trying to solve
these problems which is protocol  interoperability. What we need to insure
is protocol interoperability: do you have to match  something in cert to
something in ID payload or not.

Comment: Try: "after you have authenticated the dude on the other end, you
MUST decide whether  this matches the access control criteria on your end."

Comment: Deal with this in 2401bis. Short term solution is to say that what
goes in ID v CERT  payload is a local matter for now. It need not match.

Comment: SO we will put in sentence that ID payload is for policy lookup and
does not need to  match anything in CERT payload. Both fields may be used
for access control decisions, but need  not be correlated. 2-1 in favor.

Steve Kent: Don't think this clarifies anything, other than allows a vendor
to claim  compliance. It doesn't solve the problem.

Ted: alternate proposal?

Paul Hoffman: Do this on the list. What implementers claim their
implementations do doesn't  match debug log.

Comment: We have opened can of worms best closed on list.

11. DHCP v. CFG payload

Summary: Both solutions are technically workable. IKEv2-05 allows server to
refuse CFG request  and uses fallback to 3456bis. DHCP encapsulation within
IKE recent submission.

DHCP encapsulation might be suitable compromise, but not fleshed out. If
consensus in WG to  pursue this new idea, give them limited time, then
decide to fallback to IKEv2-05. If people  want 3456bis, give people short
time to produce text, otherwise fall back to IKEv2-05 CFG  payload. 5 or 6
happy with current, 3 or 4 unhappy.

Comment: growth of DHCP indicates configuration is a hard problem; let
someone solve it. That  speaks to just reusing DHCP. Don't reinvent the
wheel; just use DHCP. Pursue this with a  reasonable timeout with fallback.

Comment: CFG payload has fallback mechanism built in for implementations
that want to do  something else. Keep CFG payload as is to allow DHCP or
whatever else.

Comment: Getting into trouble with IPv6. Already have several, creating yet
another one.

Comment: DHCP INFORM gives options not given by CFG payload. This would
satisfy problems.  Yeah; we do need to think more about v6.

Comment: Makes sense to give DHCP 3 weeks to flesh out document.

Comment: DHCP is still evolving. CFG payload would not allow use of DHCP
end-to-end security.  In many cases DHCP options influence address
assignment, so need this information before CFG  payload. Better to restrict
ourselves to one way.

Comment: Alternative scenario. Authentication might influence address
assignment. Push to  restrict this to bootstrap and not generalize it. DHCP
is not interoperable in terms of  options.

Comment: Not clear how DHCP will work with RADIUS or LDP; CFG=20 option
superior for this.

Comment: Security Gateway acts as proxy for client; it is responsible for
authentication.

Comment: But this is not end-to-end.

Comment: In DHCP-over-IKE, Server is DHCP relay, not a proxy. There are
proposals to carry EAP  within DHCP, too. While server does have to
interpret DHCP bits, we don't want it to modify  them.

Ted: Seems to be a number of people speaking in favor of allowing
DHCP-over-IKE 3 weeks.  Strong interest in pursuing this?

Comment: in 3 weeks we will compare. Need a few days specifying=20 what
scenarios have to be  addressed.

Comment: More problems being raised now that there is a proposal. IKEv1 was
successful because  (1) there was a freeware implementation as a starting
point and (2) we did interoperability  testing before going to RFC. We are
not ready to go to RFC, because we have neither of these.  The nature of the
market is people will believe there is interoperability because it is an
RFC. Need to have something more baked. Need to have a bakeoff first. Need
to seriously  consider doing so before going to RFC.

Ted: Problem space WG says we should go to proposed standard sooner. From
process viewpoint,  we need some way to prevent flip-flop, so implementers
can implementers.

Comment: Flip-flop occurs because we don't understand problem.

Comment: We haven't started IKEv2 implementation. It would be good to have a
discussion about  this to express opinion about draft.

Ted: Let's close on DHCP first before talking about this. Sense of room to
try DHCP-within-IKE  for 3 weeks and fallback to CFG payload if this doesn't
pan out.

Comment: There are a lot of ModeCFG in IKEv1. CFG payload is near to this,
so there will have  to be new code and understanding.

Straw vote: CFG payload, DHCP-within-IKE with fallback, something else:
10-14-0. Too close to  call; take it to the list.

Comment: Let's have straw vote in 3 weeks.

Ted: Michael Richardson is the stuckee. We want to get draft ready for WG
last call by April  15. Goal to publish this as an RFC before Austria IETF.
Issue is whether baking occurs for  draft standard or proposed standard. We
need to have draft locked down, however.

Comment: what happens with 2401bis? Do we want to divorce IKEv2=20 from
2401bis? are there  linkages?

Ted: Should we publish IKEv2 and 2401bis simultaneous or in serial.

Comment: They should be "simultaneous"

Ted: That's what we did with IKEv1, but caused problems because there were
12 docs.

Comment: The hairball is not as large this time. Not convinced we have
thought through  problems we have solved.

Comment: Sympathize, but we should try the IETF thing. This is a better
goal.

Comment: Companies are under travel restrictions. we should make bakeoff
affordable and easy  to get to.

--=====================_523612==_.ALT-- From owner-ipsec@lists.tislabs.com Thu Apr 10 06:53:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ADrjJM013330; Thu, 10 Apr 2003 06:53:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04458 Thu, 10 Apr 2003 09:20:15 -0400 (EDT) Message-ID: <3E944D6A.9000904@creeksidenet.com> Date: Wed, 09 Apr 2003 12:42:18 -0400 From: "jpickering@creeksidenet.com" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Derek Atkins CC: Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com, umeth@sparta.com Subject: Re: IKEv2 cookie question References: <200304050304.h3534k023033@sydney.East.Sun.COM> Content-Type: multipart/alternative; boundary="------------050107000406050605020306" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------050107000406050605020306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I like this also, for the same reasons. Jeff Derek Atkins wrote: > Radia Perlman - Boston Center for Networking writes: > >> b) Put the actual cookie inside the N(COOKIE_REQUIRED) >> payload (so Bob wouldn't actually send an N(COOKIE)). >> So instead it's really Bob saying, "Send me THIS cookie". > > > I like this idea. It's clear, consise, and unambiguous. > >> Radia > > > -derek > --------------050107000406050605020306 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
I like this also, for the same reasons.
Jeff

Derek Atkins wrote:
Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com> writes:

b) Put the actual cookie inside the N(COOKIE_REQUIRED)
payload (so Bob wouldn't actually send an N(COOKIE)).
So instead it's really Bob saying, "Send me THIS cookie".

I like this idea.  It's clear, consise, and unambiguous.

Radia

-derek


--------------050107000406050605020306-- From owner-ipsec@lists.tislabs.com Thu Apr 10 06:53:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ADrpJM013346; Thu, 10 Apr 2003 06:53:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04479 Thu, 10 Apr 2003 09:22:16 -0400 (EDT) Message-Id: <200304091416.KAA00193@ietf.org> To: IETF-Announce:;;;;@tislabs.com;;; Cc: RFC Editor , Internet Architecture Board , ipsec@lists.tislabs.com From: The IESG Subject: Protocol Action: On the Use of SCTP with IPsec to Proposed Standard Date: Wed, 09 Apr 2003 10:16:56 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has approved the Internet-Draft On the Use of SCTP with IPsec as a Proposed Standard. This document is the product of the IP Security Protocol Working Group. The IESG contact persons are Jeffrey Schiller and Steve Bellovin. Technical Summary SCTP introduces the notion that a protocol end-point might have multiple IP addresses associated with it at one time (as a multi-homed host is). By specifying a set of addresses associated with each end-point, it can provide increased reliability in the event that one of its addresses become unreachable. IPSEC on the other-hand was designed with the notion that one host is one address. Important data structures such as SPD entries tend to be tied to an address. This document recommends implementation strategies (i.e., changes that do not require a "wire protocol" change) that can make for more efficient uses of IPSEC in multi-homed SCTP environments. It also recommends a new IKE payload to facilitate negotiating a list of addresses in place of a single address (the ID_LIST ID payload). Working Group Summary The working group had consensus on this document. Protocol Quality This document has been reviewed for the IESG by Jeff Schiller. From owner-ipsec@lists.tislabs.com Thu Apr 10 06:53:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ADrsJM013359; Thu, 10 Apr 2003 06:53:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04519 Thu, 10 Apr 2003 09:26:14 -0400 (EDT) X-Originating-IP: [64.114.95.129] X-Originating-Email: [askrywan@hotmail.com] From: "Andrew Krywaniuk" To: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. Date: Wed, 09 Apr 2003 21:52:20 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Apr 2003 01:52:20.0656 (UTC) FILETIME=[D2CEFB00:01C2FF03] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I wasn't at the San Francisco meeting, but I will add my voice to the consensus (thus slightly reducing its roughness). I would argue that the identity payload has never been authoritative, and it has always functioned as a policy hint, even in shared secret mode. (It is theoretically possible to have more than one user sharing the same secret, or - in the case of the initiator - multiple users with different secrets sharing the same id. I have heard that this has even been attempted on the responder as well.) Anyway, I digress. The receiver is authenticating the sender, so the receiver gets to choose which field in the certificate is authoritative. However, there may be cases where a user could match more than one policy rule (where the level of authorization is different). The receiver can use the sender's id to ensure that he agrees that the sender is who he thinks he is. The name I coined for this feature was the "gratuitous id check" (mostly because it tends to annoy people who don't care that their policy is incorrect as long as they can still set up a tunnel). E.g. A gateway has a number of policy rules for static peers (servers, gateways, etc) and a fall-through rule for remote access users. The static peers have different levels of authorization. Due to an ambiguity in configuration, one of the servers is granted basic access but not the extended privileges. The gratuitous id check detects this and fails the connection (or does something else of your choosing). Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-ipsec@lists.tislabs.com Thu Apr 10 08:30:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AFUqJM022214; Thu, 10 Apr 2003 08:30:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04954 Thu, 10 Apr 2003 10:49:37 -0400 (EDT) Message-ID: <4652644B98DFF34696801F8F3070D3FE03E36520@D2CSPEXM001.smartpipes.com> From: "Beadles, Mark A" To: "'David Jablon'" , "'Paul Hoffman / VPNC'" , "'Charlie_Kaufman@notesdev.ibm.com'" Cc: "'IPsec WG'" Subject: RE: draft-ietf-ipsec-ikev2-06.txt Date: Thu, 10 Apr 2003 14:53:40 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, delurking here for a moment as an implementor of a system which computationally generates IKE PSK's. Obviously a maximum-length cryptographically random PSK is "best" from a total security pt of view, in opposition to human generated passwords. This does not seem to be in question. The question is how and whether to mandate and/or enforce this. One point I'd like to make is, if the protocol specifies a MUST for this...then there would have to exist some method for determining noncompliance with this MUST. It is in my opinion contradictory to specify the PSK's are defined and exchanged "out of band" and then set a MUST requirement on that out-of-band process. An IKE implementation itself will operate correctly and in compliance with this specification regardless of the means of derivation of the PSK. A SHOULD is still a strong recommendation. (Additionally, if you are going down this path, "deriving the shared secret from a password is not secure" doesn't go far enough. True, "user passwords are unlikely to have sufficient randomness". But so would using host or peer IP address or name or system time, for example. The point is GIGO: insufficient entropy in, insufficient security out.) I'd suggest amending the text so that section 2.15 contains that protocol specification in SHOULD terms; and then including very strong best practices recommendations in the Security Considerations section. This will leave no doubt as to the desirability of randomness, but will not muddy the core protocol with things that cannot reasonably be enforced within the protocol itself. 2.15: It will commonly be the case (but it is not required) that if a shared secret is used for authentication that the same key is used in both directions. [snip] In the case of a pre-shared key, the AUTH value is computed as: AUTH = prf(Shared Secret | "Key Pad for IKEv2", ) where the string "Key Pad for IKEv2" is ASCII encoded and not null terminated. The shared secret can be variable length. The pad string is added so that if the shared secret is derived from a password, the IKE implementation need not store the password in cleartext, but rather can store a one way transformation of it that could not be used as a password equivalent for protocols other than IKEv2. [end] 5 Security Considerations: When using pre-shared keys, a critical consideration is how to ensure the randomness of these secrets. The strongest practice is to ensure that any pre-shared key contain as much randomness as the strongest key being negotiated. Deriving a shared secret solely from a password, name, other low-entropy source is not secure; passwords and other such sources are subject to dictionary and social engineering attacks, among others. + Mark Anthony Beadles + mbeadles@smartpipes.com + -----Original Message----- From: David Jablon [mailto:dpj@theworld.com] Sent: Wednesday, 09 April 2003 16:58 To: Paul Hoffman / VPNC; Charlie_Kaufman@notesdev.ibm.com Cc: IPsec WG Subject: Re: draft-ietf-ipsec-ikev2-06.txt Paul, I don't really want to debate the point of whether the text should *allow* for the use of weakened Shared Secret keys. But it seems like the implications need to be more clearly stated, and whether an implementation must allow for full-strength keys is not addressed in the SHOULD version. Here's the proposed text in question: 2(b)+: "When pre-sharing a key for use in prf-based authentication (i.e., Shared Secret") this key {SHOULD | MUST} be of the length of the key for the prf agreed for use by the parties, and this key {SHOULD NOT | MUST NOT} be derived solely from a password or other data that has less randomness than a truly random key of the appropriate length." At 09:47 AM 4/9/03 -0700, Paul Hoffman / VPNC wrote: >At 10:46 AM -0400 4/8/03, David Jablon wrote: >>I too prefer "MUST", and I prefer "MUST NOT" in the addition. > >Could you explain the technical reason for that? If someone uses a >password instead of a sufficiently-random shared secret, will the PRF >break? I think that's the wrong question, or at least I don't understand how insufficiently random input can "break" a PRF. But your first question forces me to elaborate my concern over the SHOULD version. Using "SHOULD", the security of an implementation may certainly be broken. And any relevant security proofs or arguments that assume that keys are random will certainly not apply. The text in draft 06 states that human-chosen password-derived keys are insecure in this context but it doesn't fully explain why. (See proposed change below.) Naively replacing key bytes with password bytes results in a skewed distribution. Depending on how the password is chosen, an N-byte password may have as little as 10% to 20% of the randomness of an N-byte key. Just having the high bit of each ASCII password byte set to zero guarantees at least a 12.5% loss. A good technical reason for saying MUST instead of SHOULD in 2(b)+ is that SHOULD permits implementations that restrict ALL keys to insecure length and/or insufficient randomness. >We have no way of testing if someone has used a password vs. a shared >secret. ... Now that you mention it, there are surely some easy ways to detect common causes for insufficient randomness. But I wasn't proposing such a requirement. >... If we say MUST and MUST NOT, we are saying that implementations >must somehow test for this. ... No. I don't think so. At least I didn't intend to. It does (and should) say something about the design of the mechanism for shared secret key entry, and for shared key selection (if any) --- namely that they should not force or encourage the use of weakened keys. >... SHOULD and SHOULD NOT (with the appropriate wording about the >problems of passwords) seems more realistic, but if there truly is a >technical problem with using a password in a PRF as Hugo has described, >then we should know about it. If we didn't know how passwords are different than keys, and how our security assumptions require truly random keys, then we should now. A little more wordsmithing would seem to be needed to fix the technical problem with the SHOULD version of 2(b)+. Even if weak keys are supported, it seems good to at least require that implementations MUST *permit* the use of full-strength keys, and { MUST | SHOULD } *encourage* the use of full-strength keys. Also, one sentence in draft 06 should be expanded to better distinguish the insecure practice from various other secure ways of deriving shared secrets from combinations of passwords and keys. Here's a suggested expansion: "Note that it is a common but [[ typically ]] insecure practice to have a shared key derived [[ solely ]] from a user chosen password[[, without incorporating another source of randomness ]]." -- David From owner-ipsec@lists.tislabs.com Thu Apr 10 09:41:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AGfcJM025538; Thu, 10 Apr 2003 09:41:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05265 Thu, 10 Apr 2003 12:04:48 -0400 (EDT) Message-Id: <200304101608.h3AG8oof054192@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: IKEv2 draft 6 (details) Date: Thu, 10 Apr 2003 18:08:50 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (1) *If* we decide to include a peer address update payload, we should take this into account in the Abstract and in the Overview (1-). (2) IMHO it can be useful to add the "proxy case" (transport mode IPsec SAs negociated on the behalf of a third party) in the Usage Scenarios (3-). I have a full subsection in draft-dupont-ikev2-addrmgmt-02.txt but a simple statement can be enough. Note this (the proxy case) is very useful in mobile and/or multi-homed environments. (3) NAT detection is performed in the IKE_SA_INIT so the descriptions at the beginning of the Initial Exchanges (1.2-) should be updated (or we should state that notifications are not included in order to keep the descriptions simple. IMHO this is the best and applies to descriptions of not INFORMATIONAL exchanges too). (4) In the section 1.5 (Informational Messages outside of an IKE_SA) we should be more accurate and give the notification to send. (5) Section 2 (IKE Protocol Details and Variations) is a good place to explain that an IKE SA is identified by its SPI and *not* by the addresses in the IP header of the message. (6) Section 2.1 (Use of Retransmission Timers) must specify what is in a message (request or response) to retransmit: this contains only the IKE header and payloads, as defined in section 3. So a peer MAY retransmit a message from and/or to a different address. BTW in section 3 the used term is "IKE message" so I propose to add IKE before the word message at least at the first occurrence of each subsection. (7) I don't like the wording of section 2.3 (Window Size) because it is not enough accurate about the allowed (un)sequencing of the processing of requests. IMHO the device is a message transmission facility, not an out of order processing. If we give the possibility as suggested in the current text to process requests out of order, then we should be very careful with peer address updates which must be processed strictly in order... (8) We should repeat in 2.3 the point 6 in order to be as clear as possible. (9) The terms IRAC and IRAS must be introduced in section 2.19 (Requesting an internal address on a remote network) before being used! (10) in Error Handling (2.21) please change: If a node receives a message on UDP port 500 outside the context of into If a node receives a message on UDP port 500 or 4500 outside the context of (11) This text in section 3.5 (Identification Payload) is not sound: Two implementations will interoperate only if each can generate a form of ID acceptable to the other. To assure maximum interoperability, implementations MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these forms. Implementations SHOULD be capable of generating and accepting all of these forms. perhaps it should be: Two implementations will interoperate only if each can generate a form of ID acceptable to the other. To assure maximum interoperability, implementations MUST be capable of accepting all of these forms and MUST be configurable to accept all of these forms. Implementations SHOULD be capable of generating all of these forms, and MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID. (12) I disagree with the current wording for NAT_DETECTION_*_IP in section 3.10.1 (Notify Message Types): NAT detection and NAT traversal support should be made mandatory, so we should change the MAYs into MUSTs and the term supported by the term enabled (note that an implementation which doesn't allow to enable NAT traversal should be still conformant, so some care is needed in the NAT traversal support requirement). I propose to change: NAT_DETECTION_SOURCE_IP 24582 This notification is used to by its recipient to determine whether the source is behind a NAT box. The data associated with this notification is a SHA-1 digest of the SPIs, IP address and port on which this packet was sent. There MAY be multiple notify payloads of this type in a message if the sender does not know which of several network attachments will be used to send the packet. The recipient of this notification MAY compare the supplied value to a hash of the source IP address and port and if they don't match it MAY invoke NAT specific handling (like using UDP encapsulation of ESP packets and subsequent IKE packets). Alternately, it MAY reject the connection attempt if NAT traversal is not supported. NAT_DETECTION_DESTINATION_IP 24583 This notification is used to by its recipient to determine whether it is behind a NAT box. The data associated with this notification is a SHA-1 digest of the SPIs, IP address and port to which this packet was sent. The recipient of this notification MAY compare the supplied value to a hash of the destination IP address and port and if they don't match it MAY invoke NAT specific handling (like using UDP encapsulation of ESP packets and subsequent IKE packets). Alternately, it MAY reject the connection attempt if NAT traversal is not supported. into: NAT_DETECTION_SOURCE_IP 24582 This notification is used to by its recipient to determine whether the source is behind a NAT box. The data associated with this notification is a SHA-1 digest of the SPIs, IP address and port on which this packet was sent. There MAY be multiple notify payloads of this type in a message if the sender does not know which of several network attachments will be used to send the packet. The recipient of this notification MUST compare the supplied value to a hash of the source IP address and port and if they don't match it MUST invoke NAT specific handling (like using UDP encapsulation of ESP packets and subsequent IKE packets). Alternately, it MUST reject the connection attempt if NAT traversal support is not enabled. NAT_DETECTION_DESTINATION_IP 24583 This notification is used to by its recipient to determine whether it is behind a NAT box. The data associated with this notification is a SHA-1 digest of the SPIs, IP address and port to which this packet was sent. The recipient of this notification MUST compare the supplied value to a hash of the destination IP address and port and if they don't match it MUST invoke NAT specific handling (like using UDP encapsulation of ESP packets and subsequent IKE packets). Alternately, it MUST reject the connection attempt if NAT traversal support is not enabled. (13) In Acknowledgements (7-) the first name of J. Ioannidis is John. Reingold's one is missing too. (14) Non-normative References (8.2-) has to out of the style author references for [LDAP] and [RADIUS] (15) in H.6 (Change History) s/ala carte/a la carte/ and please insert a blank line at the end before Editor's Address. Thanks Francis.Dupont@enst-bretagne.fr PS: I have major concerns (i.e., not little details to fix) about 2.11 (Address and Port Agility) and 2.23 (NAT Traversal). I have to specify two new notifications to protect peer addresses when NAT traversal is not active (cf draft-dupont-ikev2-addrmgmt-02.txt where one can find the peer address update payload too). From owner-ipsec@lists.tislabs.com Thu Apr 10 10:50:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AHoaJM027960; Thu, 10 Apr 2003 10:50:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05626 Thu, 10 Apr 2003 13:15:46 -0400 (EDT) Message-Id: <200304101719.h3AHJnof054361@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: peer address protection Date: Thu, 10 Apr 2003 19:19:49 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The peer addresses are not protected in IKEv2 and are not clearly protected in IKEv1 (in fact many implementations loosely bind them to the ID or to a CERT subject name so attacks work only in the road warrior case which of course conflicts...). I propose a very simple scheme: - the first exchange (IKE_SA_INIT) is done using UDP port 500 (common case) or UDP port 4500 (if someone believes there should be a NAT in the path). The NAT detection, using NAT_DETECTION_*_IP notifications, MUST be performed in this first exchange. - First case: a NAT is detected and NAT traversal is enabled: IKE and IPsec SAs run over UDP port 4500, implicit address update is enabled ONLY for the peer(s) which is behind the NAT (i.e., the address of a peer which is not behind a detected NAT is not allowed to change). This implicit address update mechanism SHOULD be supported and when it is triggered a check MUST be performed between the new address and the corresponding NAT_DETECTION_*_IP initial notification: if the addresses are the same (i.e., the detected NAT has disappeared) we fall into the third case or the IKE SA SHOULD be closed and reopened over UDP port 500. - Second case: a NAT is detected and NAT traversal is disabled: the connexion MUST be rejected. - Third case: no NAT is detected and for some reasons the initiator wants to run over UDP port 4500. It MAY keep the UDP port 4500 but as there is a bidding down attack against performances (NAT traversal has a cost, note that there is no security problem because as no peers are behind a NAT the implicit update mechanism MUST NOT be allowed) so a SHOULD is needed for the last case. - Fourth/last case: no NAT is detected: IKE and IPsec SAs SHOULD be run over UDP port 500 and peer addresses MUST be protected using PEER_ADDRESS_SOURCE and PEER_ADDRESS_DESTINATION notifications included in the encrypted payload of all messages. The concrete proposal for these notifications are: PEER_ADDRESS_SOURCE 2458X This notification is used to protect the source peer address against en route modifications. It includes the address family (from IANA Address Family Numbers, IPv4 is 1 and IPv6 2) on 16 bits, followed by the source port on 16 bits and the peer source address. It MUST be in an encrypted payload. At least one PEER_ADDRESS_SOURCE notification MUST be included into each message after the first exchange when no NAT has been detected. When multiple PEER_ADDRESS_SOURCE notifications are included, they encode its whole peer source address set, but the first one MUST be for the used source address. To allow the reduction of the peer source address set to one address, an address MAY be repeated. In case of a mismatch between the source address and the corresponding peer address notifications, there is a dangling update or an attack. If the possibly compromised message is a new request, its content MUST be ignored and a warning notification sent, but the message counter MUST be incremented in order to accept next requests. If it is a retransmitted request, the cached reply MUST be sent. If it is a reply, the corresponding request MUST be retransmitted. PEER_ADDRESS_DESTINATION 2458X This notification is used to protect the destination peer address against en route modifications. It includes the address family (from IANA Address Family Numbers, IPv4 is 1 and IPv6 2) on 16 bits, followed by the destination port on 16 bits and the peer destination address. It MUST be in an encrypted payload. At least one PEER_ADDRESS_DESTINATION notification MUST be included into each message after the first exchange when no NAT has been detected. When multiple PEER_ADDRESS_DESTINATION notifications are included, they encode its whole peer destination address set, but the first one MUST be for the used destination address. To allow the reduction of the peer destination address set to one address, an address MAY be repeated. In case of a mismatch between the destination address and the corresponding peer address notifications, there is a dangling update or an attack. If the possibly compromised message is a new request, its content MUST be ignored and a warning notification sent, but the message counter MUST be incremented in order to accept next requests. If it is a retransmitted request, the cached reply MUST be sent. If it is a reply, the corresponding request MUST be retransmitted. NOTES: - can the "first one MUST be for the used source address" be a problem, i.e., should we use a SHOULD or a MUST? Note that the NAT detection gives the used address and IPsec assumes the source (and destination) addresses are stable. - there is no defined warning in case of address mismatch, so please add after: PEER_ADDRESS_ALERT 2458X This notification is used to signal possible problems with peer addresse. For instance it MUST be included in replies when a new request has been received with a modified en route peer address and was ignored. Thanks Francis.Dupont@enst-bretagne.fr PS: as an implementor I clearly chose simplicity over message size! The remaining stuff is for 2.11 (address and port agility) which needs to be extended and of course for 2.13 (NAT traversal) but for the last thing I'll wait for Tero's new wording integration. The introduction of this message can give a good idea of my current opinion... PPS: an overbroken NAT can mess all attempts to run IKE over UDP port 500 so we have to allowed both to run IKE over UDP port 4500 (which is an optimization if there is a NAT) and to keep the port 4500 if the NAT doesn't show itself. From owner-ipsec@lists.tislabs.com Thu Apr 10 10:51:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AHpsJM027999; Thu, 10 Apr 2003 10:51:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05627 Thu, 10 Apr 2003 13:15:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <5.1.0.14.0.20030410101831.04527960@pop.theworld.com> References: <5.1.0.14.0.20030409151544.04582a30@pop.theworld.com> <5.1.0.14.0.20030408104652.00a37ec0@pop.theworld.com> <5.1.0.14.0.20030408104652.00a37ec0@pop.theworld.com> <5.1.0.14.0.20030409151544.04582a30@pop.theworld.com> <5.1.0.14.0.20030410101831.04527960@pop.theworld.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 10 Apr 2003 10:15:42 -0700 To: David Jablon From: Paul Hoffman / VPNC Subject: Re: draft-ietf-ipsec-ikev2-06.txt Cc: Charlie_Kaufman@notesdev.ibm.com, IPsec WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:57 AM -0400 4/10/03, David Jablon wrote: >I think I took a broader view of what "break something" means. >In the spirit of Hugo's medical analogy: >"The operation was a success! But the patient died from complications." >I think the use of very weak keys breaks the utility of the method, >and even if allowed, should not be encouraged. It doesn't break the utility of the method, it weakens it. There is a huge difference there. If it breaks it, you cannot ever allow it; if it weakens it, you are responsible for pointing out the weakness. >But you're absolutely right that I haven't justified the "MUST NOT" text, >given that I choose not to debate accomodation for weak keys. >"MUST NOT" doesn't work in that sense, regardless of what "I prefer". > >I wonder if we can agree that the "MUST" text in the first part works? >Especially in light of the two other points that Hugo raised: >(1) that having the first case be "MUST" fixes other problems, and >(2) that it still permits implementors to derive full-length keys from >passwords of arbitrary length using arbitrary functions, if they so choose. No, we still don't agree. If we say that the definition of MUST etc. comes from RFC 2119, we have to use that definition. This isn't hair-splitting: it is simple protocol mechanics. The "other problems" that it fixes are non-fatal problems. They are related to the weakness of passwords, namely their susceptibility to faster dictionary attacks, but they are not fatal to the protocol. They don't affect the communication channel. Please remember that we are talking about pre-shared keys here: *both* parties have to agree to using any particular key. If that is their shared security policy (even after our exhortations about the weakness of it), then that is what they want. > >But that is quite different than mandating that IKEv2 systems have >to check the randomness of the preshared key. > >Fine. I didn't propose that, and I never meant such a mandate to be implied. By using a MUST in the proposed wording, you are saying that the implementation *has* to prevent passwords from being used. > >That is not what RFC 2119 says for the difference between SHOULD >and MUST. If you want us to redefine the words in RFC 2119, we can, >but you can't both normatively reference RFC 2119 and use the >argument above. > >It's not a definition issue. In the first part, "MUST" is >justified, but in the >second part, "MUST NOT" isn't. > >Part 1: >>> ... this key {SHOULD | MUST} be of the length >>> of the key for the prf agreed for use by the parties, ... > >I see no need to re-define "MUST" and "SHOULD" to support this point: >The "SHOULD" here gives license to an implementator to do potentially >nasty things, like say, truncating all such keys to 64-bits, >in the interest of handling passwords in some way. Only if they have a technical reason to do so; that's what RFC 2119 says. There is no technical reason that I know of that says that the length of the key matters to the PRF. If the length is shorter, the PRF will not fail, it will simply produce that much less value. >That "MUST" here helps to guarantee interoperability when using >full-length keys, and that "SHOULD" does not, is something I thought >you'd agree with. And if not then, then perhaps now, in light of points >(1) and (2) above. Sorry, maybe I'm being dense. I don't see how the SHOULD would not guarantee the interoperability. Let's say that both sides are using a PRF that wants 128 bits of keying material, and the two parties agree to a shared secret of "Baseball2003". How is the guarantee of interoperability broken? > >> and { MUST | SHOULD } *encourage* the >>>use of full-strength keys. >> >>Now you are talking about the user interface, which most definitely >>is out of scope for this protocol document. If you want to write an >>implementation guide for IKEv2, this would obviously be appropriate >>there. > >I see the point, but I'm not so sure about where that scope line is, >or should be. The IETF almost never mandates how a user interface or documentation should act. This is meant to be an IETF protocol, so we have to follow the IETF rules. That's why we are using RFC 2119, even though we could use some other definitions of MUST and SHOULD if we wanted to. >I think the current draft has already crossed the line in talking >about the kinds >of keying material (e.g. passwords) that users will presumably stuff into the >user interface. Where in the draft is that? > And to maximize interoperability, one may wish to consider >the type and form of keying material that can be input (or output?), and any >relevant transformations that may be used by different implementations. That is already done: none are prohibited. >Are special password-to-key transformations deemed out of scope? Of course not: the two sides agree to a shared secret, regardless of how the secret is formed. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Apr 10 11:44:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AIiDJM002026; Thu, 10 Apr 2003 11:44:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05855 Thu, 10 Apr 2003 14:09:37 -0400 (EDT) To: Antonio Forzieri Cc: ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: Do ipsec vendors care about privacy? References: <3E93F27F.1010403@cefriel.it> Date: 10 Apr 2003 14:06:21 -0400 In-Reply-To: <3E93F27F.1010403@cefriel.it> Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Antonio Forzieri writes: > It disappoints me too. > > I think that we have to ask to ourselves what price we can pay to > obtain IDi protection. Remember that IPsec is a peer-to-peer protocol and can always be reversed. So the 'client' of one protocol can be turned into the 'server' in another context. The protection we're talking about here is against _ACTIVE_ attacks -- we're already protected against passive attacks. The concern is that an attacker sees an IKE connection from 1.2.3.4 and wants to figure out who 1.2.3.4 is, so they initiate an IKE to 1.2.3.4 (they can't just watch the existing session -- IKE is protected against passive eavesdropping). If the responder just gives up it's identity, then you've just lost! -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Thu Apr 10 12:13:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AJDeJM003546; Thu, 10 Apr 2003 12:13:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05941 Thu, 10 Apr 2003 14:42:03 -0400 (EDT) To: "Theodore Ts'o" Cc: ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: IKE V2 Open Issues References: Date: 10 Apr 2003 14:46:20 -0400 In-Reply-To: Message-ID: Lines: 22 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Theodore Ts'o" writes: > 5) Lack of definition of the COOKIE_REQUIRED notify payload. > Charlie's suggestion to delete the COOKIE_REQUIRED payload and simply > to use the COOKIE payload is simple, and non-controversial. Actually, I (and at least two others who have voiced opinions on the topic) prefer Radia's suggestion of putting the cookie into the COOKIE_REQUIRED notify payload and sending that. So Bob would send a N(COOKIE_REQUIRED{cookie}) message to Alice, and Alice would add N(COOKIE{cookie}) to message-3. I think this is clearer than Charlie's suggestion of just using N(COOKIE{cookie}) in both directions. Radia? Charlie? Others? -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Thu Apr 10 12:19:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AJJXJM004452; Thu, 10 Apr 2003 12:19:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05970 Thu, 10 Apr 2003 14:50:05 -0400 (EDT) To: Hugo Krawczyk Cc: "Theodore Ts'o" , IPsec WG From: Derek Atkins Subject: Re: IKE V2 Open Issues References: Date: 10 Apr 2003 14:54:21 -0400 In-Reply-To: Message-ID: Lines: 51 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk writes: > > > > 1) Hugo's proposal to change legacy authentication to protect the > > initiator's identity against active attacks. After looking at the > > discussion, Barbara and I have concluded that the impacts of moving > > around various protocol elements introduces numerous additional > > complexities which will be hard to address at this late date. Russ > > with his AD hat on set as the bar, "if the changes are the least bit > > onerous, then this should not be done". We believe these changes meet > > that test. > > objection! the above presentation of the complexity incurred by > the changes needed to suport user's identity privacy (against > active attackers) is inaccurate and misleading. The required changes are > purely local to the EAP extension of ikev2 and do not touch global > elements in the protocol nor they impact performance or any > other aspect of an application/implementation not running the > EAP extension (for example, if all we do is to move IDi to 5th message). Note that the responder cannot start the EAP authentication system until it has an identity from the initiator (or it needs to send an "EAP Identity Request" which adds yet another round trip). This is because the server needs to use the identity to determine what kind of EAP session to initiate. This is usually accomplished via an encapsulation within RADIUS to some AAA server in order to authenticate the supplicant (using EAP terminology). Basically, this means that moving IDi to message 5 implies you cannot start send the EAP Challenge until message 6, which means you're not done with IKE until at least message 8 (assuming a one-round-trip EAP protocol). Are you SURE you want an 8-message protocol? I'm not sure this is what we want. Also, what happens when you turn the protocol around? I see you're initiating IKE with server X, so I initiate IKE with you to determine your identity -- how do you protect your identity there? Or are you saying that you're putting the identity in different places based on whether EAP is being used? Well, how do you know if EAP is being used if you don't know who your peer is? I can certainly posit a server that is configured to use EAP with some subset of peers and RSA authenticatation with some other subset of peers. How does the server (acting as IKE responder) know which sub-protocol to use? -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Thu Apr 10 15:08:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AM82JM013141; Thu, 10 Apr 2003 15:08:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06511 Thu, 10 Apr 2003 17:21:42 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 10 Apr 2003 14:25:36 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: IKE V2 Open Issues Cc: Jeff Schiller , Charlie Kaufman Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is another big open issue that Ted didn't list, but we need to resolve, namely the splitting out of the crypto algorithms and MUSTs and SHOULDs. What we have in this moment is -06 which lists the crypto algorithms and discusses the mandatory algorithms (without actually specifying them). Jeff Schiller volunteered to write the second document, which would define the mandatory algorithms and the UI suites that we would use. After talking with Charlie, we realized that we had different views of what was agreed to at the San Francisco meeting, and unfortunately the minutes don't help clarify it. There seemed to be general agreement that the main IKEv2 document should not need to be revised if the we change algorithms or change how or why we want implementations to use them. The second document would be easier to update, specifically when we wanted to mandate AES and associated algorithms. This split has been used successfully in other IETF WGs. There also seemed to be agreement that we should have a small number of UI suites that cover the mandatory algorithms, and that the UI suites should have justifying text. Based on that, I propose the following: - The list of crypto algorithms should be in Jeff's document. Leave the transform IDs in section 3.3.2 of IKEv2, but move everything starting with "For Transform Type 1..." to Jeff's document. - Leave section 3.3.3 (the mandatory transform types, not algorithms) in the IKEv2 document. - Move the discussion of mandatory transform IDs to Jeff's document. Section 3.3.4 should not be in the IKEv2 document, and Jeff can use as much of it as he wants in his document, depending on how he is arranging it. - Jeff's document also has a short list of UI suites and some discussion of them. The list could be shorter than the one Charlie had in the -05 draft, and might only encompass the mandatory algorithms, or it might be longer. We need to discuss the list after we see it. The result will bring us more in line with current IETF practice, and will let us give the VPN industry some clear guidance on how they can make their future IKEv2 systems more interoperable. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Apr 10 15:15:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AMF3JM013918; Thu, 10 Apr 2003 15:15:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06541 Thu, 10 Apr 2003 17:44:48 -0400 (EDT) Date: Fri, 11 Apr 2003 00:48:55 +0300 Message-Id: <200304102148.h3ALmtPk029105@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com CC: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Wed, 9 Apr 2003 18:34:03 -0400) Subject: Re: Question on SA Bundle References: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Stephen Kent > In general I agree, but if we do that, and if we want to be able to > support bundles, then we need to add complexity to IKE to be able to > specify how multiple SAs relate to one another. In the general case, > that seems to be messy, which is why I believe we probably ought not > try to support this going forward, consistent with our overall > attempt to simplify IPsec. It would be GREAT simplification of IPSEC if the key management negotiated only individual unidirectional SA's by default. No policy checking for Phase2 SA's. I've repeated this for 4 years now, and been ignored. Let this be my one yearly reminder of the fact :-) > Flexibility is good, except to the extent that it introduces > complexity. I don't think flexibility is good if it serves primarily > to allow non-interoperable implementations to claim conformance with > a "flexible" standard. We have to be careful in that regard. Flexibily can be achieved without complexity. Consider analogy of high level language and machine code. In my view IPSEC base RFC's should describe the easy to implement "machine code", consisting of primitive operations, that are clear and easy to implement. Everything is already almost there (RFC 2401, PFKEY, ESP/AH). I always liked the idea of unidirectional SA being a good choice for a primitive unit. From owner-ipsec@lists.tislabs.com Thu Apr 10 16:09:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AN91JM015140; Thu, 10 Apr 2003 16:09:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06843 Thu, 10 Apr 2003 18:39:18 -0400 (EDT) Message-Id: <5.1.0.14.0.20030410101831.04527960@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 10 Apr 2003 11:57:27 -0400 To: Paul Hoffman / VPNC From: David Jablon Subject: Re: draft-ietf-ipsec-ikev2-06.txt Cc: Charlie_Kaufman@notesdev.ibm.com, IPsec WG In-Reply-To: References: <5.1.0.14.0.20030409151544.04582a30@pop.theworld.com> <5.1.0.14.0.20030408104652.00a37ec0@pop.theworld.com> <5.1.0.14.0.20030408104652.00a37ec0@pop.theworld.com> <5.1.0.14.0.20030409151544.04582a30@pop.theworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, An amended version of the text in question is at the end. The rest of this note is meant to explain or clarify any remaining differences of opinion, or mistakes. At 04:17 PM 4/9/03 -0700, Paul Hoffman / VPNC wrote: >At 4:57 PM -0400 4/9/03, David Jablon wrote: >>I don't really want to debate the point of whether the text should *allow* for >>the use of weakened Shared Secret keys. > >It sounds like you do. ... No, I really, really don't want to debate the *allow for* point. (regardless of how I feel about that practice. :-) >... RFC 2119 has very specific definitions for SHOULD, SHOULD NOT, MUST, and MUST NOT. Saying "MUST NOT" has very different semantics than "SHOULD NOT do this because it is weak". >I assume you are not proposing that we remove the normative reference to RFC 2119. If you are, that's a very different topic... I pointed out a problem or two with using "SHOULD", that don't exist when using "MUST". You noted different problems or issues with using the "MUST", "MUST NOT", and "SHOULD NOT" text. Surely, we can both assume we're at least *trying* to properly use these terms, despite any momentary blindness we might have for the other's viewpoint. >>Here's the proposed text in question: >> >>2(b)+: >> "When pre-sharing a key for use in prf-based authentication >> (i.e., Shared Secret") this key {SHOULD | MUST} be of the length >> of the key for the prf agreed for use by the parties, and this key >> {SHOULD NOT | MUST NOT} be derived solely from a password >> or other data that has less randomness than a truly random key >> of the appropriate length." >> >>At 09:47 AM 4/9/03 -0700, Paul Hoffman / VPNC wrote: >>>At 10:46 AM -0400 4/8/03, David Jablon wrote: >>>>I too prefer "MUST", and I prefer "MUST NOT" in the addition. >>> >>>Could you explain the technical reason for that? If someone uses a password instead of a sufficiently-random shared secret, will the PRF break? >> >>I think that's the wrong question, or at least I don't understand >>how insufficiently random input can "break" a PRF. > >I don't either, that's why I asked. "MUST NOT" would indicate that it would break something, "SHOULD NOT" would indicate that the the something would work but probably not the way one would want. I think I took a broader view of what "break something" means. In the spirit of Hugo's medical analogy: "The operation was a success! But the patient died from complications." I think the use of very weak keys breaks the utility of the method, and even if allowed, should not be encouraged. But you're absolutely right that I haven't justified the "MUST NOT" text, given that I choose not to debate accomodation for weak keys. "MUST NOT" doesn't work in that sense, regardless of what "I prefer". I wonder if we can agree that the "MUST" text in the first part works? Especially in light of the two other points that Hugo raised: (1) that having the first case be "MUST" fixes other problems, and (2) that it still permits implementors to derive full-length keys from passwords of arbitrary length using arbitrary functions, if they so choose. >>But your first question forces me to elaborate my concern over the >>SHOULD version. Using "SHOULD", the security of an implementation >>may certainly be broken. And any relevant security proofs or arguments >>that assume that keys are random will certainly not apply. > >I have never read a security proof, but if they rely on user-selected things like preshared keys to have a particularly amount of randomness, then they are not based on reality. No matter what you tell them, users will sometimes choose passwords or even non-password preshared secrets with less than 112/128 bits of randomness. They just will. > >We are designing IKEv2 for Internet users, not for people who write security proofs. ... You're preaching to a choir-boy. User security and user convenience are surely good things to seek. And I'd prefer to see implementors and users, that choose to use passwords, encouraged to seek alternate methods, where one may have a better chance of achieving these goals simultaneaously. I think that is part of the value of EAP. >... Having said that, I obviously support telling users as well as we can what they should do to make their systems secure in the way that the security proof says it is. ... Good. I too like "telling users what they should do to make their systems secure." And I see no need to qualify that point. >But that is quite different than mandating that IKEv2 systems have to check the randomness of the preshared key. Fine. I didn't propose that, and I never meant such a mandate to be implied. >>The text in draft 06 states that human-chosen password-derived >>keys are insecure in this context but it doesn't fully explain why. > >We should obviously fix that. Good. >>A good technical reason for saying MUST instead of SHOULD in 2(b)+ >>is that SHOULD permits implementations that restrict ALL keys to >>insecure length and/or insufficient randomness. > >That is not what RFC 2119 says for the difference between SHOULD and MUST. If you want us to redefine the words in RFC 2119, we can, but you can't both normatively reference RFC 2119 and use the argument above. It's not a definition issue. In the first part, "MUST" is justified, but in the second part, "MUST NOT" isn't. Part 1: >> ... this key {SHOULD | MUST} be of the length >> of the key for the prf agreed for use by the parties, ... I see no need to re-define "MUST" and "SHOULD" to support this point: The "SHOULD" here gives license to an implementator to do potentially nasty things, like say, truncating all such keys to 64-bits, in the interest of handling passwords in some way. That "MUST" here helps to guarantee interoperability when using full-length keys, and that "SHOULD" does not, is something I thought you'd agree with. And if not then, then perhaps now, in light of points (1) and (2) above. However, mandating a fixed key length does imply something about transformations that may be used to derive a key from a variable-length password. But, in light of your comments below, it's not clear to me whether such transformations are in the proper scope of this document. Part 2: >> ... this key >> {SHOULD NOT | MUST NOT} be derived solely from a password >> or other data that has less randomness than a truly random key >> of the appropriate length." I concede the point that the "MUST NOT" version doesn't accomodate implementations that allow weak keys to be derived from passwords. To accomodate this practice, this could be either "SHOULD NOT" or "should not". (More on that below.) I think either form permits, but doesn't promote the practice, which seems reasonable. >> >We have no way of testing if someone has used a password vs. a shared secret. ... >> >>Now that you mention it, there are surely some easy ways to detect >>common causes for insufficient randomness. But I wasn't proposing >>such a requirement. > >By using "MUST", you are. No, but I could see why you might think so. I tried to acknowledged the legitimacy of your alternate interpretation by proposing an alternate solution: >>... >>A little more wordsmithing would seem to be needed to fix the >>technical problem with the SHOULD version of 2(b)+. >>Even if weak keys are supported, it seems good to at least >>require that implementations MUST *permit* the use of >>full-strength keys, > >Ah, much better! There is an interoperability reason why they MUST: some systems designed for people who can't enter passwords if they tried will have preshared secrets that are long. Good. (I think.) >> and { MUST | SHOULD } *encourage* the >>use of full-strength keys. > >Now you are talking about the user interface, which most definitely is out of scope for this protocol document. If you want to write an implementation guide for IKEv2, this would obviously be appropriate there. I see the point, but I'm not so sure about where that scope line is, or should be. I think the current draft has already crossed the line in talking about the kinds of keying material (e.g. passwords) that users will presumably stuff into the user interface. And to maximize interoperability, one may wish to consider the type and form of keying material that can be input (or output?), and any relevant transformations that may be used by different implementations. Are special password-to-key transformations deemed out of scope? If so, how is a requirement to be able to permit input of any full-strength key, which seems similarly a user interface issue, justified as being in scope? In any case, I hope we agree that its generally a good thing to recommend discouraging use of shared secret keys that are derived solely from passwords without another source of randomness, and that it's good to elaborate the security implications of not following that recommendation. >>Also, one sentence in draft 06 should be expanded to better >>distinguish the insecure practice from various other secure ways >>of deriving shared secrets from combinations of passwords and keys. >>Here's a suggested expansion: >> >> "Note that it is a common but [[ typically ]] insecure practice to have a >> shared key derived [[ solely ]] from a user chosen password[[, >> without incorporating another source of randomness ]]." > >I would leave out the "typically": you simply don't see passwords with 112 or 128 bits of randomness. I don't agree with the final clause because we can't mandate that IKEv2 systems change the password on the user. Instead, you could say "In order to get preshared secrets with a sufficient amount of randomness, users typically need those preshared secrets supplied by systems that compute them." Ok. I sometimes use the term "password" broadly to encompass other kinds of memorizable authenticators, but expanding discussion to include high-entropy passphrases seems like opening an even larger can. In light of the above, and in the spirit of being constructive, see if the following text addresses your concerns: "When pre-sharing a key for use in prf-based authentication (i.e., "Shared Secret") the key MUST be of the length of the key for the prf agreed for use by the parties. The implementation must permit the use of any specific key value of that length, and the key should not be derived solely from a password or other data that is shorter than or is less random than a truly random key of the appropriate length. ..." Even though "is shorter than" seems redundant in light of "is less random than", I think this makes it clear that password length and key length are separate matters. -- David From owner-ipsec@lists.tislabs.com Thu Apr 10 16:09:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AN9SJM015160; Thu, 10 Apr 2003 16:09:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06829 Thu, 10 Apr 2003 18:36:18 -0400 (EDT) Message-ID: <6204FDDE129D364D8040A98BCCB290EF052203FD@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: smb@research.att.com Cc: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-sctp-06.txt Date: Thu, 10 Apr 2003 12:27:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FF7E.221FB260" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2FF7E.221FB260 Content-Type: text/plain Hi Steve and all, The draft (in the end of Section 2, below) appears to propose a new requirement that remote access tunnel mode IPsec users MUST use an inner IP address equivalent to their outer address (or else it reclassifies such users as "security gateways"). This seems to directly contradict all the work with DHCP over IKE and the entire Configuration Payload discussion, all of which is based on assigning an inner tunnel address which can be a part of a VPN address domain (i.e., different from the outer address). Am I missing something (besides my second cup of coffee)? Regards, Paul Knight >From Section 2: When operating in tunnel mode, the question of what to use as the tunnel destination address (for the "outer" header) arises. We distinguish three cases: where the end hosts are also the tunnel endpoints; where neither host is a tunnel endpoint (the tunnel endpoints are security gateways); and where only one of the hosts is a tunnel endpoint (the usual case for the "road warrior" talking to a security gateway). In the first case, the outer addresses MUST be the same as the inner addresses of the tunnel. In the second case (security gateways) there is no special processing; address selection proceeds as it would for two distinct sets of end hosts. In the third case, the "road warrior" uses the security gateway's address as the tunnel destination address, and MUST use the same source address as that of the inner packet. Symmetrically, the security gateway uses its own address as the source address of the tunnel, and MUST use the the same destination address in the outer header as that of the inner packet. An implementation will probably structure the code so that if, during SA setup, the inner and outer address of either side is the same, rather than explicitly store the corresponding address of the tunnel, it sets a flag that marks the SA to use the same address in the tunnel header as in the inner header. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, April 09, 2003 7:18 AM > To: IETF-Announce; @tislabs.com > Cc: ipsec@lists.tislabs.com > Subject: I-D ACTION:draft-ietf-ipsec-sctp-06.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the > IP Security Protocol Working Group of the IETF. > > Title : On the Use of SCTP with IPsec > Author(s) : S. Bellovin et al. > Filename : draft-ietf-ipsec-sctp-06.txt > Pages : 0 > Date : 2003-4-8 > > This document describes functional requirements for IPsec > [RFC2401] and IKE [RFC2409] to facilitate their use for > securing SCTP [RFC2960] traffic. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sctp-06.t xt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-sctp-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-sctp-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C2FF7E.221FB260 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-ipsec-sctp-06.txt

Hi Steve and all,

The draft (in the end of Section 2, below) appears to = propose a new requirement that remote access tunnel mode IPsec users = MUST use an inner IP address equivalent to their outer address (or else = it reclassifies such users as "security gateways").  = This seems to directly contradict all the work with DHCP over IKE and = the entire Configuration Payload discussion, all of which is based on = assigning an inner tunnel address which can be a part of a VPN address = domain (i.e., different from the outer address).

Am I missing something (besides my second cup of = coffee)?

Regards,
Paul Knight

From Section 2:
   When operating in tunnel mode, the = question of what to use as the
   tunnel destination address (for the = "outer" header) arises.  We
   distinguish three cases: where the end = hosts are also the tunnel
   endpoints; where neither host is a = tunnel endpoint (the tunnel
   endpoints are security gateways); and = where only one of the hosts is
   a tunnel endpoint (the usual case for = the "road warrior" talking to
   a security gateway).  In the first = case, the outer addresses MUST be
   the same as the inner addresses of the = tunnel.  In the second case
   (security gateways) there is no special = processing; address
   selection proceeds as it would for two = distinct sets of end hosts.
   In the third case, the "road = warrior" uses the security gateway's
   address as the tunnel destination = address, and MUST use the same
   source address as that of the inner = packet.  Symmetrically, the
   security gateway uses its own address = as the source address of the
   tunnel, and MUST use the the same = destination address in the outer
   header as that of the inner = packet.  An implementation will probably
   structure the code so that if, during = SA setup, the inner and outer
   address of either side is the same, = rather than explicitly store the
   corresponding address of the tunnel, it = sets a flag that marks the SA
   to use the same address in the tunnel = header as in the inner header.

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
> Sent: Wednesday, April 09, 2003 7:18 AM
> To: IETF-Announce; @tislabs.com
> Cc: ipsec@lists.tislabs.com
> Subject: I-D = ACTION:draft-ietf-ipsec-sctp-06.txt
>
>
> A New Internet-Draft is available from the = on-line
> Internet-Drafts directories. This draft is a = work item of the
> IP Security Protocol Working Group of the = IETF.
>
>       = Title           : On the = Use of SCTP with IPsec
>       = Author(s)       : S. Bellovin et = al.
>       = Filename        : = draft-ietf-ipsec-sctp-06.txt
>       = Pages           : 0
>       = Date            : = 2003-4-8
>      
> This document describes functional requirements = for IPsec
> [RFC2401] and IKE [RFC2409] to facilitate their = use for
> securing SCTP [RFC2960] traffic.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipsec-s= ctp-06.t
xt

To remove yourself from the IETF Announcement list, = send a message to
ietf-announce-request with the word unsubscribe in = the body of the message.

Internet-Drafts are also available by anonymous FTP. = Login with the username "anonymous" and a password of your = e-mail address. After logging in, type "cd internet-drafts" = and then

        "get = draft-ietf-ipsec-sctp-06.txt".

A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by = e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-ietf-ipsec-sctp-06.txt".
       =20
NOTE:   The mail server at ietf.org can = return the document in
        MIME-encoded form by using the "mpack" = utility.  To use this
        feature, = insert the command "ENCODING mime" before the = "FILE"
        command.  To decode the response(s), you will need = "munpack" or
        a = MIME-compliant mail reader.  Different MIME-compliant mail = readers
        exhibit = different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have = been split
        up into = multiple messages), so check your local documentation on
        how to = manipulate these messages.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader implementation to automatically retrieve the ASCII version = of the Internet-Draft.

------_=_NextPart_001_01C2FF7E.221FB260-- From owner-ipsec@lists.tislabs.com Thu Apr 10 16:10:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ANA5JM015188; Thu, 10 Apr 2003 16:10:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06849 Thu, 10 Apr 2003 18:40:19 -0400 (EDT) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Thu, 10 Apr 2003 10:58:33 -0700 Subject: Re: Confirm decision on identity handling. From: Brian Korver To: "Theodore Ts'o" , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted, The proposed text to add sounds good to me. - brian briank@briank.com On 4/9/03 2:18 PM, "Theodore Ts'o" wrote: > > At the San Jose IETF, the IPSEC working group came to a rough > consensus (confirmed by a straw poll) to solve an interoperability > problem as follows: (quoting from the minutes) > >> Comment: Deal with this in 2401bis. Short term solution is to say that what >> goes in ID v CERT payload is a local matter for now. It need not match. >> >> Comment: SO we will put in sentence that ID payload is for policy lookup and >> does not need to match anything in CERT payload. Both fields may be used >> for access control decisions, but need not be correlated. 2-1 in favor. > > The consensus was relatively rough, and there was a desire expressed > by some to continue the discussion on the list. > > In order to move the discussion forward, we propose the following > addition to section 3.5 of the ikev2-06 as meeting the spirit of the > consensus which was developed in San Francisco. Append to the first > paragraph, which begins: > > The Identification Payload, denoted ID in this memo, allows peers to > assert an identify to one another. The ID Payload names the identity > to be authenticated with the AUTH payload. > > .. the following text: > > ... This identity is used for policy lookup, but does not > necessarily have to match anything in the CERT payload; both fields > may be used by an implementation to perform access control > decisions. > > Discussion: > > The implication of this change, as was discussed in San Francisco, is > that it gives freedom to implementations to make more sophisticated > access control policies, where the responder might use the identity in > the ID payload to look up an access control list, and match the > subject name in the certificate against that ACL, for example. This > can be advantageous in that do not need to dictate the form of the > subject names in the certificate, which could promote the reuse of > certificates across multiple applications. The downside is that the > initiator must now allow the configuration of two pieces of > information; there is an additional configuration "knob" which must be > set correct in order for two peers to successfully ocmmunicate. > > There are other alternatives, which have been discussed in the past. > Two self-consistent and workable alternatives are presented here: > > 2) Require that that IPSEC strictly define the types of X.509 > certificate subject names that would be accepted, and precisely define > the matching rules of the identity payload. This in effect would > predefine the access control policies in the system. One mechanism > for doing so can be found in section 3.2 of > draft-ietf-ipsec-pki-profile-02.txt. > > 3) Specify that the ID payload must not be sent and/or is ignored when > using certificates to authenticate. In this case, the Certificate > subject name is used to lookup the policy information associated with > the SA instead of the contents identity payload. (This is essentially > very similar to a proposla contained in Paul Hoffman's > revised-identity I-D.) > > These alternatives have tradeoffs: to differing degress, they > essentially limit flexibility in the choice of certificate names and > the name (identity) used to look up policy information. In the first > case, the choice of the name found in certificate is limited to > something which passes the matching rule defined in the pki-profile > I-D when the subject name or the subject alt name is matched against > the contents of the identity payload. In the second case, the name > used to look up the SA policy is constrained to be exactly the subject > name in the certificate, or perhaps the certificate itself. > > The latter alternative in particular may impact some implementations > significantly, by changing the key used to look up and manage SA > policy information. > > Decision path: > > At the San Francisco meeting, there was clear (but rough) consensus to > explicitly specify that the contents of the ID payload do not have to > match the contents of the CERT payload, and which will require that > initiators have sufficient configuration controls to set both the ID and > Cert payloads. Proposed text which implements this rough conensus has > been included in this messange. > > Since the straw poll indicated that of the people in the room at San > Francisco, that people were 2-1 in favor of this choice, and this > chice should be considered the privileged or "default" choice. > However, especially given the roughness of the consensus there, this > decision must be confirmed on the mailing list. People who believe > that one of the above alternatives, or some other alternative, should > be adopted instead, are encouraged to speak up. > From owner-ipsec@lists.tislabs.com Thu Apr 10 16:14:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ANE1JM015432; Thu, 10 Apr 2003 16:14:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06891 Thu, 10 Apr 2003 18:45:21 -0400 (EDT) Message-Id: <200304101927.PAA03463@ietf.org> To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: The IESG SUBJECT: Last Call: Using AES Counter Mode With IPsec ESP to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 10 Apr 2003 15:27:19 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has received a request from the IP Security Protocol Working Group to consider Using AES Counter Mode With IPsec ESP as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-4-24. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-03.txt From owner-ipsec@lists.tislabs.com Thu Apr 10 16:15:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ANFAJM015473; Thu, 10 Apr 2003 16:15:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06892 Thu, 10 Apr 2003 18:45:25 -0400 (EDT) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Thu, 10 Apr 2003 10:58:33 -0700 Subject: Re: Confirm decision on identity handling. From: Brian Korver To: "Theodore Ts'o" , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted, The proposed text to add sounds good to me. - brian briank@briank.com On 4/9/03 2:18 PM, "Theodore Ts'o" wrote: > > At the San Jose IETF, the IPSEC working group came to a rough > consensus (confirmed by a straw poll) to solve an interoperability > problem as follows: (quoting from the minutes) > >> Comment: Deal with this in 2401bis. Short term solution is to say that what >> goes in ID v CERT payload is a local matter for now. It need not match. >> >> Comment: SO we will put in sentence that ID payload is for policy lookup and >> does not need to match anything in CERT payload. Both fields may be used >> for access control decisions, but need not be correlated. 2-1 in favor. > > The consensus was relatively rough, and there was a desire expressed > by some to continue the discussion on the list. > > In order to move the discussion forward, we propose the following > addition to section 3.5 of the ikev2-06 as meeting the spirit of the > consensus which was developed in San Francisco. Append to the first > paragraph, which begins: > > The Identification Payload, denoted ID in this memo, allows peers to > assert an identify to one another. The ID Payload names the identity > to be authenticated with the AUTH payload. > > .. the following text: > > ... This identity is used for policy lookup, but does not > necessarily have to match anything in the CERT payload; both fields > may be used by an implementation to perform access control > decisions. > > Discussion: > > The implication of this change, as was discussed in San Francisco, is > that it gives freedom to implementations to make more sophisticated > access control policies, where the responder might use the identity in > the ID payload to look up an access control list, and match the > subject name in the certificate against that ACL, for example. This > can be advantageous in that do not need to dictate the form of the > subject names in the certificate, which could promote the reuse of > certificates across multiple applications. The downside is that the > initiator must now allow the configuration of two pieces of > information; there is an additional configuration "knob" which must be > set correct in order for two peers to successfully ocmmunicate. > > There are other alternatives, which have been discussed in the past. > Two self-consistent and workable alternatives are presented here: > > 2) Require that that IPSEC strictly define the types of X.509 > certificate subject names that would be accepted, and precisely define > the matching rules of the identity payload. This in effect would > predefine the access control policies in the system. One mechanism > for doing so can be found in section 3.2 of > draft-ietf-ipsec-pki-profile-02.txt. > > 3) Specify that the ID payload must not be sent and/or is ignored when > using certificates to authenticate. In this case, the Certificate > subject name is used to lookup the policy information associated with > the SA instead of the contents identity payload. (This is essentially > very similar to a proposla contained in Paul Hoffman's > revised-identity I-D.) > > These alternatives have tradeoffs: to differing degress, they > essentially limit flexibility in the choice of certificate names and > the name (identity) used to look up policy information. In the first > case, the choice of the name found in certificate is limited to > something which passes the matching rule defined in the pki-profile > I-D when the subject name or the subject alt name is matched against > the contents of the identity payload. In the second case, the name > used to look up the SA policy is constrained to be exactly the subject > name in the certificate, or perhaps the certificate itself. > > The latter alternative in particular may impact some implementations > significantly, by changing the key used to look up and manage SA > policy information. > > Decision path: > > At the San Francisco meeting, there was clear (but rough) consensus to > explicitly specify that the contents of the ID payload do not have to > match the contents of the CERT payload, and which will require that > initiators have sufficient configuration controls to set both the ID and > Cert payloads. Proposed text which implements this rough conensus has > been included in this messange. > > Since the straw poll indicated that of the people in the room at San > Francisco, that people were 2-1 in favor of this choice, and this > chice should be considered the privileged or "default" choice. > However, especially given the roughness of the consensus there, this > decision must be confirmed on the mailing list. People who believe > that one of the above alternatives, or some other alternative, should > be adopted instead, are encouraged to speak up. > From owner-ipsec@lists.tislabs.com Thu Apr 10 16:18:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ANI0JM015539; Thu, 10 Apr 2003 16:18:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06905 Thu, 10 Apr 2003 18:46:21 -0400 (EDT) Message-ID: <3E95C826.50000@bell-labs.com> Date: Thu, 10 Apr 2003 15:38:14 -0400 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: IKE V2 Open Issues References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek Atkins wrote: >>5) Lack of definition of the COOKIE_REQUIRED notify payload. >>Charlie's suggestion to delete the COOKIE_REQUIRED payload and simply >>to use the COOKIE payload is simple, and non-controversial. > > Actually, I (and at least two others who have voiced opinions on the > topic) prefer Radia's suggestion of putting the cookie into the > COOKIE_REQUIRED notify payload and sending that. So Bob would send a > N(COOKIE_REQUIRED{cookie}) message to Alice, and Alice would add > N(COOKIE{cookie}) to message-3. I think this is clearer than > Charlie's suggestion of just using N(COOKIE{cookie}) in both > directions. Yes, your way it's clearer. However Charlie's way is simpler, and one less payload type to worry about... I'll be happy with either choice - but lean towards N(COOKIE{cookie})... From owner-ipsec@lists.tislabs.com Thu Apr 10 19:20:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B2KrJM024561; Thu, 10 Apr 2003 19:20:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07893 Thu, 10 Apr 2003 21:47:34 -0400 (EDT) To: Uri Blumenthal Cc: ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: IKE V2 Open Issues References: <3E95C826.50000@bell-labs.com> Date: 10 Apr 2003 21:51:18 -0400 In-Reply-To: <3E95C826.50000@bell-labs.com> Message-ID: Lines: 27 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Uri Blumenthal writes: > Yes, your way it's clearer. However Charlie's way is simpler, > and one less payload type to worry about... IMHO payload types are cheap. > I'll be happy with either choice - but lean towards N(COOKIE{cookie})... I can go either way. I don't feel extremely vetted to one way or the other. However, another benefit for using two payload types: it makes it easier for protocol analyzers like tcpdump or ethereal. They can differentiate the cookie request N(COOKIE_REQUIRED{cookie}) from a cookie response N(COOKIE{cookie}) to aid in analysis and debugging... A small benefit indeed, but a tangible one for, IMHO, little additional coding. You have to have the code to parse the packet either way -- whether you look for IKEV2_NOTIFY_COOKIE or ..._COOKIE_REQUIRED is a one-line change. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Thu Apr 10 19:22:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B2MHJM024610; Thu, 10 Apr 2003 19:22:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07908 Thu, 10 Apr 2003 21:54:42 -0400 (EDT) To: "Paul Knight" Cc: smb@research.att.com, ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: I-D ACTION:draft-ietf-ipsec-sctp-06.txt References: <6204FDDE129D364D8040A98BCCB290EF052203FD@zbl6c004.corpeast.baynetworks.com> Date: 10 Apr 2003 21:58:44 -0400 In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF052203FD@zbl6c004.corpeast.baynetworks.com> Message-ID: Lines: 56 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, No, it appears your reading of this is correct. I hope this is a bug (or an oversight). I agree with you that a road warrior probably has a different inner IP address than external IP Address. The main difference between a road warrior and a security gateway is that the road warrior generally has an inner network of an IPv4/32 or an IPv6/128. I agree this text should be fixed. -derek "Paul Knight" writes: > Hi Steve and all, > > The draft (in the end of Section 2, below) appears to propose a new > requirement that remote access tunnel mode IPsec users MUST use an inner IP > address equivalent to their outer address (or else it reclassifies such > users as "security gateways"). This seems to directly contradict all the > work with DHCP over IKE and the entire Configuration Payload discussion, all > of which is based on assigning an inner tunnel address which can be a part > of a VPN address domain (i.e., different from the outer address). > > Am I missing something (besides my second cup of coffee)? > > Regards, > Paul Knight > > >From Section 2: > When operating in tunnel mode, the question of what to use as the > tunnel destination address (for the "outer" header) arises. We > distinguish three cases: where the end hosts are also the tunnel > endpoints; where neither host is a tunnel endpoint (the tunnel > endpoints are security gateways); and where only one of the hosts is > a tunnel endpoint (the usual case for the "road warrior" talking to > a security gateway). In the first case, the outer addresses MUST be > the same as the inner addresses of the tunnel. In the second case > (security gateways) there is no special processing; address > selection proceeds as it would for two distinct sets of end hosts. > In the third case, the "road warrior" uses the security gateway's > address as the tunnel destination address, and MUST use the same > source address as that of the inner packet. Symmetrically, the > security gateway uses its own address as the source address of the > tunnel, and MUST use the the same destination address in the outer > header as that of the inner packet. An implementation will probably > structure the code so that if, during SA setup, the inner and outer > address of either side is the same, rather than explicitly store the > corresponding address of the tunnel, it sets a flag that marks the SA > to use the same address in the tunnel header as in the inner header. -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Thu Apr 10 20:31:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B3VPJM027510; Thu, 10 Apr 2003 20:31:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA08073 Thu, 10 Apr 2003 23:00:02 -0400 (EDT) Reply-To: From: "Darren Dukes" To: Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Date: Thu, 10 Apr 2003 23:04:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I mostly see the DHCP-over-IKE as a bits on the wire change from CP. The biggest differences between the two are: 1 - With DHCP backend DHCP-over-IKE does not necessarily require SGW to store DHCP state while CP requires a DHCP client on the SGW per IKE-SA. 2 - DHCP-over-IKE extends the IKE_AUTH exchange, similar to what EAP does. 3 - With DHCP backend DHCP-over-IKE offers end to end DHCP which may be useful for future DHCP options but I see no clear advantage today with current DHCP. 4 - With non-DHCP backends there is little to no difference between the two options. DHCP-in-IKE will satisfy what I think IKEv2 needs for address assignment, I don't know if the differences are significant enough to change things for rev07. I would like to know what others think. I've included a pro/con list for the two I used to come up with the stuff above, if you have more then add to this list. Pro DHCP-over-IKE ~~~~~~~~~~~~~~~~~ + Uses standard DHCP messages, and state machine on client + SGW may be able to be relatively stateless with DHCP backend (if DHCP server supports the DHCP relay options) + Allows end to end DHCP client address assignment with DHCP server (may be useful in the future but no current need) + Makes possible standard DHCP address re-assignment to local and remote clients (only useful/likely in very small networks) + Integration with RADIUS and DHCP (LDAP, etc. should not be a big deal) Con DHCP-over-IKE ~~~~~~~~~~~~~~~~~ - Minimum addition of 280 bytes to IKE messages, more options will make this bigger. - Extends IKE_AUTH exchange (but EAP does this too). - When DHCPDISCOVER will be to an unauthenticated peer (true for CP as well but DHCPDISCOVER may have many options that may be dangerous to give to an attacker impersonating the SGW, recommend sending _minimal_ DHCPDISCOVER). Pro CP ~~~~~~ + Small payload size + Similar to IKEv1 modecfg + Integration with RADIUS and DHCP (LDAP, etc. should not be a big deal) Con CP ~~~~~~ - No end to end DHCP negotiation, SGW must be DHCP client - No DHCP standard way to assign the same address to clients when physically on the LAN and when connecting via ipsec (Likely only useful in very small LANs) - Does not use DHCP state machine end to end may have future impact - When a DHCP backend is used the SGW will need to actively communicate with a DHCP server and keep DHCP client state Darren > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Theodore Ts'o > Sent: Wednesday, April 09, 2003 5:19 PM > To: ipsec@lists.tislabs.com > Subject: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload > > > > Last week on Thursday, Tero Kevinen has submitted three drafts (*) that > define DHCP over IKE. Comments to these documents are solicted, and > thoughts about whether this approach is superior or inferior to the > currently specified Configuration payload in ikev2-06 are hereby > solicited. > > (*) Tero, go ahead and submit them as IPSEC wg I-D's --- Barbara and I > will approve them as working group documents. > From owner-ipsec@lists.tislabs.com Fri Apr 11 03:39:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BAdhJM010727; Fri, 11 Apr 2003 03:39:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA08973 Fri, 11 Apr 2003 06:03:21 -0400 (EDT) Message-Id: <200304111007.h3BA7Eof056942@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Paul Knight" cc: smb@research.att.com, ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-sctp-06.txt In-reply-to: Your message of Thu, 10 Apr 2003 12:27:52 EDT. <6204FDDE129D364D8040A98BCCB290EF052203FD@zbl6c004.corpeast.baynetworks.com> Date: Fri, 11 Apr 2003 12:07:14 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: => Please don't send an HTML copy of the body... The draft (in the end of Section 2, below) appears to propose a new requirement that remote access tunnel mode IPsec users MUST use an inner IP address equivalent to their outer address (or else it reclassifies such users as "security gateways"). This seems to directly contradict all the work with DHCP over IKE and the entire Configuration Payload discussion, all of which is based on assigning an inner tunnel address which can be a part of a VPN address domain (i.e., different from the outer address). Am I missing something (besides my second cup of coffee)? => I believe this draft is about IKEv1 and IKEv2 can be different... I can say this issue stresses the need of an address management (so the fact a node can use several own addresses is taken into account and the "same address" becomes "address which belongs to the same node", the issue is solved at the price to have to implement the belonging (?) check). >From Section 2: When operating in tunnel mode, the question of what to use as the tunnel destination address (for the "outer" header) arises. We distinguish three cases: where the end hosts are also the tunnel endpoints; where neither host is a tunnel endpoint (the tunnel endpoints are security gateways); and where only one of the hosts is a tunnel endpoint (the usual case for the "road warrior" talking to a security gateway). In the first case, the outer addresses MUST be the same as the inner addresses of the tunnel. In the second case (security gateways) there is no special processing; address selection proceeds as it would for two distinct sets of end hosts. In the third case, the "road warrior" uses the security gateway's address as the tunnel destination address, and MUST use the same source address as that of the inner packet. Symmetrically, the security gateway uses its own address as the source address of the tunnel, and MUST use the the same destination address in the outer header as that of the inner packet. An implementation will probably structure the code so that if, during SA setup, the inner and outer address of either side is the same, rather than explicitly store the corresponding address of the tunnel, it sets a flag that marks the SA to use the same address in the tunnel header as in the inner header. => I have to confess that I don't understand why the draft requires the same address when all the text before this paragraph shows it should only require that the inner address and the outer address (aka the peer address) belongs to the same node, i.e., is member of the address set! Perhaps this is a consequence of the usual confusion between inner and outer addresses when we talk about SPD and SADB selectors... But the draft is clear about this issue, SPD selectors are trafic selectors and match the inner address. There is no SADB selector involved: the text is about the incoming processing and uses explicitely the outer address (the right term, "peer address", is in the text) for the SA lookup. The only reason (which is not in the draft) I can find is to make things simpler, i.e., disallow flexibility between inner and outer addresses. Of course, I share your concern, i.e., this doesn't work when some addresses have not the same status than others. I am waiting the answer from the authors! Thanks Francis.Dupont@enst-bretagne.fr PS: my address management proposal convers the multi-homing case so works well with SCTP. For instance, it provides a very easy way to negociate the set of addresses in all "phases". PPS: BTW the draft should reference the PKIX document, aka RFC 3280, in the certificate discussion (3-2-a). From owner-ipsec@lists.tislabs.com Fri Apr 11 06:20:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BDKpJM021585; Fri, 11 Apr 2003 06:20:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09324 Fri, 11 Apr 2003 08:52:03 -0400 (EDT) Message-Id: <200304111144.HAA07620@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esn-addendum-01.txt Date: Fri, 11 Apr 2003 07:44:01 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Extended Sequence Number Addendum to IPsec DOI for ISAKMP Author(s) : S. Kent Filename : draft-ietf-ipsec-esn-addendum-01.txt Pages : 5 Date : 2003-4-10 This document describes extensions to the Internet IP Security Domain of Interpretation for ISAKMP [DOI] that are needed to support negotiation of whether or not a Security Association will use Extended (64-bit) Sequence Numbers. (See [AH] and [ESP] for a description of Extended Sequence Numbers.) Comments should be sent to Stephen Kent (kent@bbn.com). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esn-addendum-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esn-addendum-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esn-addendum-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-10160017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esn-addendum-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esn-addendum-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-10160017.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Apr 11 06:22:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BDMuJM021654; Fri, 11 Apr 2003 06:22:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09318 Fri, 11 Apr 2003 08:51:04 -0400 (EDT) Message-ID: <3E963C5F.7040202@roc.co.in> Date: Fri, 11 Apr 2003 09:24:07 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: "Theodore Ts'o" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: Content-Type: multipart/alternative; boundary="------------020507000700030203020206" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------020507000700030203020206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Ted, This proposal looks OK to me too. As mentioned, it requires configuration of both payload ID information and Certicate ID information to be present in the configuration. -Ravi Brian Korver wrote: >Ted, > >The proposed text to add sounds good to me. > >- brian >briank@briank.com > > >On 4/9/03 2:18 PM, "Theodore Ts'o" wrote: > > >>At the San Jose IETF, the IPSEC working group came to a rough >>consensus (confirmed by a straw poll) to solve an interoperability >>problem as follows: (quoting from the minutes) >> >> >> >>>Comment: Deal with this in 2401bis. Short term solution is to say that what >>>goes in ID v CERT payload is a local matter for now. It need not match. >>> >>>Comment: SO we will put in sentence that ID payload is for policy lookup and >>>does not need to match anything in CERT payload. Both fields may be used >>>for access control decisions, but need not be correlated. 2-1 in favor. >>> >>> >>The consensus was relatively rough, and there was a desire expressed >>by some to continue the discussion on the list. >> >>In order to move the discussion forward, we propose the following >>addition to section 3.5 of the ikev2-06 as meeting the spirit of the >>consensus which was developed in San Francisco. Append to the first >>paragraph, which begins: >> >> The Identification Payload, denoted ID in this memo, allows peers to >> assert an identify to one another. The ID Payload names the identity >> to be authenticated with the AUTH payload. >> >>.. the following text: >> >> ... This identity is used for policy lookup, but does not >> necessarily have to match anything in the CERT payload; both fields >> may be used by an implementation to perform access control >> decisions. >> >>Discussion: >> >>The implication of this change, as was discussed in San Francisco, is >>that it gives freedom to implementations to make more sophisticated >>access control policies, where the responder might use the identity in >>the ID payload to look up an access control list, and match the >>subject name in the certificate against that ACL, for example. This >>can be advantageous in that do not need to dictate the form of the >>subject names in the certificate, which could promote the reuse of >>certificates across multiple applications. The downside is that the >>initiator must now allow the configuration of two pieces of >>information; there is an additional configuration "knob" which must be >>set correct in order for two peers to successfully ocmmunicate. >> >>There are other alternatives, which have been discussed in the past. >>Two self-consistent and workable alternatives are presented here: >> >>2) Require that that IPSEC strictly define the types of X.509 >>certificate subject names that would be accepted, and precisely define >>the matching rules of the identity payload. This in effect would >>predefine the access control policies in the system. One mechanism >>for doing so can be found in section 3.2 of >>draft-ietf-ipsec-pki-profile-02.txt. >> >>3) Specify that the ID payload must not be sent and/or is ignored when >>using certificates to authenticate. In this case, the Certificate >>subject name is used to lookup the policy information associated with >>the SA instead of the contents identity payload. (This is essentially >>very similar to a proposla contained in Paul Hoffman's >>revised-identity I-D.) >> >>These alternatives have tradeoffs: to differing degress, they >>essentially limit flexibility in the choice of certificate names and >>the name (identity) used to look up policy information. In the first >>case, the choice of the name found in certificate is limited to >>something which passes the matching rule defined in the pki-profile >>I-D when the subject name or the subject alt name is matched against >>the contents of the identity payload. In the second case, the name >>used to look up the SA policy is constrained to be exactly the subject >>name in the certificate, or perhaps the certificate itself. >> >>The latter alternative in particular may impact some implementations >>significantly, by changing the key used to look up and manage SA >>policy information. >> >>Decision path: >> >>At the San Francisco meeting, there was clear (but rough) consensus to >>explicitly specify that the contents of the ID payload do not have to >>match the contents of the CERT payload, and which will require that >>initiators have sufficient configuration controls to set both the ID and >>Cert payloads. Proposed text which implements this rough conensus has >>been included in this messange. >> >>Since the straw poll indicated that of the people in the room at San >>Francisco, that people were 2-1 in favor of this choice, and this >>chice should be considered the privileged or "default" choice. >>However, especially given the roughness of the consensus there, this >>decision must be confirmed on the mailing list. People who believe >>that one of the above alternatives, or some other alternative, should >>be adopted instead, are encouraged to speak up. >> >> >> > > > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------020507000700030203020206 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Ted, This proposal looks OK to me too. As mentioned, it requires configuration of both payload ID information and Certicate ID information to be present in the configuration. -Ravi Brian Korver wrote: >Ted, > >The proposed text to add sounds good to me. > >- brian >briank@briank.com > > >On 4/9/03 2:18 PM, "Theodore Ts'o" wrote: > >> >>At the San Jose IETF, the IPSEC working group came to a rough >>consensus (confirmed by a straw poll) to solve an interoperability >>problem as follows: (quoting from the minutes) >> >> >>> >>>Comment: Deal with this in 2401bis. Short term solution is to say that what >>>goes in ID v CERT payload is a local matter for now. It need not match. >>> >>>Comment: SO we will put in sentence that ID payload is for policy lookup and >>>does not need to match anything in CERT payload. Both fields may be used >>>for access control decisions, but need not be correlated. 2-1 in favor. >>> >> >>The consensus was relatively rough, and there was a desire expressed >>by some to continue the discussion on the list. >> >>In order to move the discussion forward, we propose the following >>addition to section 3.5 of the ikev2-06 as meeting the spirit of the >>consensus which was developed in San Francisco. Append to the first >>paragraph, which begins: >> >> The Identification Payload, denoted ID in this memo, allows peers to >> assert an identify to one another. The ID Payload names the identity >> to be authenticated with the AUTH payload. >> >>.. the following text: >> >> ... This identity is used for policy lookup, but does not >> necessarily have to match anything in the CERT payload; both fields >> may be used by an implementation to perform access control >> decisions. >> >>Discussion: >> >>The implication of this change, as was discussed in San Francisco, is >>that it gives freedom to implementations to make more sophisticated >>access control policies, where the responder might use the identity in >>the ID payload to look up an access control list, and match the >>subject name in the certificate against that ACL, for example. This >>can be advantageous in that do not need to dictate the form of the >>subject names in the certificate, which could promote the reuse of >>certificates across multiple applications. The downside is that the >>initiator must now allow the configuration of two pieces of >>information; there is an additional configuration "knob" which must be >>set correct in order for two peers to successfully ocmmunicate. >> >>There are other alternatives, which have been discussed in the past. >>Two self-consistent and workable alternatives are presented here: >> >>2) Require that that IPSEC strictly define the types of X.509 >>certificate subject names that would be accepted, and precisely define >>the matching rules of the identity payload. This in effect would >>predefine the access control policies in the system. One mechanism >>for doing so can be found in section 3.2 of >>draft-ietf-ipsec-pki-profile-02.txt. >> >>3) Specify that the ID payload must not be sent and/or is ignored when >>using certificates to authenticate. In this case, the Certificate >>subject name is used to lookup the policy information associated with >>the SA instead of the contents identity payload. (This is essentially >>very similar to a proposla contained in Paul Hoffman's >>revised-identity I-D.) >> >>These alternatives have tradeoffs: to differing degress, they >>essentially limit flexibility in the choice of certificate names and >>the name (identity) used to look up policy information. In the first >>case, the choice of the name found in certificate is limited to >>something which passes the matching rule defined in the pki-profile >>I-D when the subject name or the subject alt name is matched against >>the contents of the identity payload. In the second case, the name >>used to look up the SA policy is constrained to be exactly the subject >>name in the certificate, or perhaps the certificate itself. >> >>The latter alternative in particular may impact some implementations >>significantly, by changing the key used to look up and manage SA >>policy information. >> >>Decision path: >> >>At the San Francisco meeting, there was clear (but rough) consensus to >>explicitly specify that the contents of the ID payload do not have to >>match the contents of the CERT payload, and which will require that >>initiators have sufficient configuration controls to set both the ID and >>Cert payloads. Proposed text which implements this rough conensus has >>been included in this messange. >> >>Since the straw poll indicated that of the people in the room at San >>Francisco, that people were 2-1 in favor of this choice, and this >>chice should be considered the privileged or "default" choice. >>However, especially given the roughness of the consensus there, this >>decision must be confirmed on the mailing list. People who believe >>that one of the above alternatives, or some other alternative, should >>be adopted instead, are encouraged to speak up. >> >> > > > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------020507000700030203020206-- From owner-ipsec@lists.tislabs.com Fri Apr 11 08:08:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BF8YJM000790; Fri, 11 Apr 2003 08:08:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09645 Fri, 11 Apr 2003 10:13:56 -0400 (EDT) Message-Id: <200304111417.h3BEHbof057932@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: rewrite of IKEv2 Section 2.11 Address and Port Agility Date: Fri, 11 Apr 2003 16:17:37 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The current text is: 2.11 Address and Port Agility IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and AH associations for the same IP addresses it runs over. The IP addresses and ports in the outer header are, however, not themselves cryptographically protected, and IKE is designed to work even through Network Address Translation (NAT) boxes. An implementation MUST accept incoming connection requests even if not received from UDP port 500 or 4500, and MUST respond to the address and port from which the request was received. IKE functions identically over IPv4 or IPv6. There are a lot of details to change: - the proxy case - clearer rule for responses - peer address protection when NAT traversal is not active (i.e., when UDP port 500 is used) - peer address set management The whole stuff is in draft-dupont-ikev2-addrmgmt-02.txt but needs to be integrated into the current draft. Here is my proposal: 2.11 Address and Port Agility An implementation MUST accept incoming connection requests even if not received from UDP port 500 or 4500, and MUST respond to the address and port from which the request was received. IKE functions identically over IPv4 or IPv6 and is designed to work either through Network Address Translation (NAT) boxes or with a cryptographically protection of the IP addresses and ports in the outer header. IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and AH associations for the same IP addresses it runs over, i.e., for the peer addresses. The response rule has no exception: the response to a request MUST be sent from the destination address and port of the request to the source address and port of the request using the same transport protocol. In case of a retransmitted request, the last received message only SHALL be taken into account. The NAT detection is performed in the IKE_SA_INIT exchange. All messages following this first exchange are either over UDP port 4500 if NAT traversal support is active, or over UDP port 500 with a REQUIRED cryptographically protection of peer addresses and ports by PEER_ADDRESS_SOURCE and PEER_ADDRESS_DESTINATION notifications. If multiple peer address notifications for the same peer are included in a message, the first one MUST be the used peer address. In order to associate some possible peer source addresses to possible peer destination addresses, the source and destination peer addresses notifications MAY be mixed (i.e., not in the common order source(s) first, destination(s) after). For instance S1, S2, D1, S3, D2, D3 is a hint: S1 or S2 should be used in conjunction with D1, S3 with D2 or D3. According to its policy, a peer MAY verify the peer address sets at any time, commonly in the IKE_AUTH exchange or when they change, for instance using the SubjAltName ASN.1 sequence field of X.509v3 certificates. When ESP or AH associations in transport mode are setup with different addresses in the traffic selectors, i.e., when IKE is acting as a client negotiator on behalf of another party, the addresses used in the transport mode SAs are the addresses of the traffic selectors. A proper authorization in the local policy of peers is REQUIRED and this case SHOULD be supported. Note that the IPsec SAs built in this proxy case can not be handled by any address management mechanism like NAT traversal support. Thanks Francis.Dupont@enst-bretagne.fr PS: my next message will be about the peer address update which can be included now or postponed as the rekeying already provides a way to get the same result (but not at the same price). From owner-ipsec@lists.tislabs.com Fri Apr 11 08:27:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BFRoJM001604; Fri, 11 Apr 2003 08:27:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09808 Fri, 11 Apr 2003 10:58:19 -0400 (EDT) Cc: ipsec@lists.tislabs.com Message-ID: <3E96CE2D.8040901@bell-labs.com> Date: Fri, 11 Apr 2003 10:16:13 -0400 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: Derek Atkins Original-CC: ipsec@lists.tislabs.com Subject: Re: IKE V2 Open Issues References: <3E95C826.50000@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek Atkins wrote: >>Yes, your way it's clearer. However Charlie's way is simpler, >>and one less payload type to worry about... > > IMHO payload types are cheap. Hm, OK. > I can go either way. I don't feel extremely vetted to one way or the > other. > > However, another benefit for using two payload types: it makes it > easier for protocol analyzers like tcpdump or ethereal. They can > differentiate the cookie request N(COOKIE_REQUIRED{cookie}) from a > cookie response N(COOKIE{cookie}) to aid in analysis and debugging... > A small benefit indeed, but a tangible one for, IMHO, little > additional coding. You have to have the code to parse the packet > either way -- whether you look for IKEV2_NOTIFY_COOKIE or > ..._COOKIE_REQUIRED is a one-line change. OK, sold. I'm convinced in the value of COOKIE_REQUIRED and support it. From owner-ipsec@lists.tislabs.com Fri Apr 11 08:45:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BFjNJM002672; Fri, 11 Apr 2003 08:45:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09855 Fri, 11 Apr 2003 11:12:33 -0400 (EDT) Message-Id: <200304111516.h3BFGmof058143@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: peer address update payload Date: Fri, 11 Apr 2003 17:16:48 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here is a proposal for the peer address update payload if we decide to include it in the next IKEv2 draft. The modifs are: - an update of the section 1.4 (The INFORMATIONAL Exchange). BTW IMHO we should split this section in three parts, a general one, the next one about Deletes and the last one about Updates. - a new subsection at the end of section 3 (Header and Payload Formats). Don't forget to update the last subsection (Other Payload types) (:)! As the format is simple (it was modelled after the Delete one), I begin by it: 3.17 Peer Address Update Payload Format The next figure 26 shows the format of the Peer Address Update Payload. It is possible to send multiple SPIs in a Peer Address Update payload, however, each SPI MUST be for the same protocol. Mixing of Protocol Identifiers MUST NOT be performed in a the Peer Address Update payload. It is permitted, however, to include multiple Peer Address Update payloads in a single INFORMATIONAL Exchange where each Peer Address Update payload lists SPIs for a different protocol. Update of the IKE_SA is indicated by a Protocol_Id of 0 (IKE) but no SPIs. Update of a CHILD_SA, such as ESP or AH, will contain the Protocol_Id of that protocol (1 for ESP, 2 for AH) and the SPI is the SPI the sending endpoint would expect in inbound ESP or AH packets. The following diagram illustrates the content of the Peer Address Update Notification: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !A| Protocol-ID ! SPI Size ! # of SPIs ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Security Parameter Index(es) (SPI) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25: Peer Address Update Payload Format o All (1 bit) - MUST be set to one when all SAs (the IKE SA and all non-proxy incoming IPsec SAs negotiated by it) are updated. In this case the update is for the IKE-SA (Protocol-ID 0, SPI size 0, no SPI and number of SPIs 0). MUST be set to zero when an individual SA is updated. o Protocol_Id (7 bits) - Must be zero for an IKE_SA, 1 for ESP, or 2 for AH. o SPI Size (1 octet) - Length in octets of the SPI as defined by the Protocol-Id. Zero for IKE (SPI is in message header) or four for AH and ESP. o # of SPIs (2 octets) - The number of SPIs contained in the Peer Address Update Notification. The size of each SPI is defined by the SPI Size field. o Security Parameter Index(es) (variable length) - Identifies the specific security association(s) to delete. The lengths of these fields are determined by the SPI Size and # of SPIs fields. The payload type for the Peer Address Update Payload (in short the Update (U) Payload) is seventeen (17). 3.18 Other Payload Types Payload type values 18-127 are reserved to IANA for future assignment in IKEv2 (see section 10). Payload type values 128-255 are for private use among mutually consenting parties. The text to add at the end of the section 1.4 (IMHO in the subsection 1.4.2 of a reorganized 1.4) is: The explicit mechanism SHALL be used when NAT traversal support is not active, i.e., when IKE runs over UDP port 500 with protected peer addresses and only it this case. It has strong sequencing requirements: as IKEv2 messages have a protected sequence number, the only issue is the window of processing and pending exchanges. Any INFORMATIONAL Exchange with a peer address update payload MUST be processed in order. When the receiver of an update request has to check the validity of the new peer address, it MAY use a return routability check sending an empty INFORMATIONAL message to the new address and waiting for a response in a similar way to liveness checks (2.4). The default policy SHOULD be to perform this check but a peer MAY choose to directly accept updates. When an SA is updated for a peer address, both members of the pair MUST be updated. When SAs are nested, as when data (and IP headers if in tunnel mode) are encapsulated first with IPcomp, then with ESP, and finally with AH between the same pair of endpoints, all of the SAs MUST be updated together. Each endpoint MUST update the SAs it receives on and allow the other endpoint to update the other SA in each pair. To update a peer address of an SA, an Informational Exchange with one or more peer address update payloads is sent listing the SPIs (as they would be placed in the headers of inbound packets) of the SAs to be updated. The recipient MUST update the designated SAs. Normally, the reply in the Informational Exchange will contain peer address update payloads for the paired SAs going in the other direction. Note there is no special case for update collision, and there is a simple way to handle the common case where all SAs, i.e., the IKE SA and all non-proxy IPsec SAs negociated by it, have to be updated. Thanks Francis.Dupont@enst-bretagne.fr PS: if this is adopted, we need to update the introduction (abstract/ overview). The Update Payload adds the support for multi-homing and a partial support for mobility (partial because the mobile-to-mobile case with possible simultaneous handoffs needs more). BTW IKEv2 with the Update Payload can do the same thing than unoptimized mobile IPv6! PPS: about NAT-T text, I am waiting for the integration of Tero's comments: From: Tero Kivinen Subject: draft-ietf-ipsec-ikev2-05.txt comments Message-ID: <15983.47777.849792.382994@ryijy.hel.fi.ssh.com> Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24164 Wed, 12 Mar 2003 17:52:04 -0500 (EST) From owner-ipsec@lists.tislabs.com Fri Apr 11 10:12:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BHC9JM005647; Fri, 11 Apr 2003 10:12:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10142 Fri, 11 Apr 2003 12:40:47 -0400 (EDT) Date: Fri, 11 Apr 2003 19:44:41 +0300 (IDT) From: Hugo Krawczyk To: Derek Atkins cc: "Theodore Ts'o" , IPsec WG Subject: Re: IKE V2 Open Issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, the questions you raise below were discussed in this thread. Take a look at past messages on it. They should , hopefully, ,clear some misunderstandings. Here are some brief answers to your questions. First let me make a clarification that is important to keep in mind (and relates to an objection that you raised in another message in this thread). The proposal to protect IDi from active attacks applies ONLY to the EAP extension of ikev2. All other runs of the protocol (in particular peer-to-peer runs) will have the same protection that the WG decided long ago (that is, IDr has full protection while IDi has only protection against active attacks). Also, important to keep in mind is that in the current EAP solution BOTH initiator and responder's identities are vulnerable to active attacks. What I was proposing for the EAP exchange does not make it worse for the responder in the EAP context (that is, it still has protection against passive attacks) while it improves substantially the privacy guarantee for the initiator. See more below: On 10 Apr 2003, Derek Atkins wrote: > Hugo Krawczyk writes: > > > > > > > 1) Hugo's proposal to change legacy authentication to protect the > > > initiator's identity against active attacks. After looking at the > > > discussion, Barbara and I have concluded that the impacts of moving > > > around various protocol elements introduces numerous additional > > > complexities which will be hard to address at this late date. Russ > > > with his AD hat on set as the bar, "if the changes are the least bit > > > onerous, then this should not be done". We believe these changes meet > > > that test. > > > > objection! the above presentation of the complexity incurred by > > the changes needed to suport user's identity privacy (against > > active attackers) is inaccurate and misleading. The required changes are > > purely local to the EAP extension of ikev2 and do not touch global > > elements in the protocol nor they impact performance or any > > other aspect of an application/implementation not running the > > EAP extension (for example, if all we do is to move IDi to 5th message). > > Note that the responder cannot start the EAP authentication system > until it has an identity from the initiator (or it needs to send an > "EAP Identity Request" which adds yet another round trip). This is > because the server needs to use the identity to determine what kind of > EAP session to initiate. This is usually accomplished via an > encapsulation within RADIUS to some AAA server in order to > authenticate the supplicant (using EAP terminology). > > Basically, this means that moving IDi to message 5 implies you cannot > start send the EAP Challenge until message 6, which means you're not > done with IKE until at least message 8 (assuming a one-round-trip EAP > protocol). Are you SURE you want an 8-message protocol? I'm not sure > this is what we want. > This additional RT is the price for one of the solutions (moving IDi to 5th message). The other solution (moving R's authentication to msg 2 as SLA proposed) does not have this problem though it has some complexity by itself (again these trade-offs were discussed already in this thread). As for the question "Are you SURE you want an 8-message protocol?" I have to say that its formulation is a bit unfair. It makes it sound as a horrible thing. And may be it is. The question, however, is "Are you willing to pay an increase from 6-mesages to 8 messages for user's id privacy?". I am. But apparently most people are not. And again, there are solutions that do not require the extra RT > Also, what happens when you turn the protocol around? I see you're > initiating IKE with server X, so I initiate IKE with you to determine > your identity -- how do you protect your identity there? > I am assuming that the user's machine (or policy) will be configured such that it will never respond to IKE-EAP initiations, but will only act as initiator of EAP methods. That's how the user's id is protected from probe attacks. BTW, note that anyone that requires protection of its own identity from probing attacks has to make sure that it does not act as responder in a EAP exchange. If a machine is configured to allow for such responses then the protection promised by IKEv2 is gone. (I ACTUALLY THINK THAT THIS NEEDS TO BE SPELLED EXPLICITLY IN THE DRAFT) > Or are you saying that you're putting the identity in different places > based on whether EAP is being used? Well, how do you know if EAP is > being used if you don't know who your peer is? I can certainly posit > a server that is configured to use EAP with some subset of peers and > RSA authenticatation with some other subset of peers. How does the > server (acting as IKE responder) know which sub-protocol to use? the server knows that the iniitiator requests EAP by the lack of signature in message 3. All machines should be configured to reject such requests except for those specific machines that will work as EAP-supporting gateways. In any case, this discussion is over. The decision on the EAP protocol for IKEv2 has been made. (And I will be travelling for a while now so do not expect a response from here) Hugo > > -derek > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com > From owner-ipsec@lists.tislabs.com Fri Apr 11 11:48:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BImkJM010154; Fri, 11 Apr 2003 11:48:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10583 Fri, 11 Apr 2003 14:14:05 -0400 (EDT) X-Originating-IP: [64.114.95.129] X-Originating-Email: [askrywan@hotmail.com] From: "Andrew Krywaniuk" To: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ikev2-06.txt Date: Fri, 11 Apr 2003 14:11:52 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Apr 2003 18:11:52.0747 (UTC) FILETIME=[D41E1FB0:01C30055] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As Paul discussed, the MUST clauses can only refer to things that affect compliance. Therefore, it sounds to me like the only MUST we need is the following: "Implementations that provide an interface for the user to enter a purely alphanumeric shared secret (i.e. a password), must allow that value to be a minimum of 64 bytes(*) long." Then there can be the usual warning about poorly-chosen passwords elsewhere. I'd be surprised if anyone didn't support 64 byte shared secrets already. (*) Alphanumeric characters comprise 1/4th of the available 256 bits. Therefore, for 128 bits of key strength, you need a minimum of 64 bytes. Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From owner-ipsec@lists.tislabs.com Fri Apr 11 12:56:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BJuBJM015194; Fri, 11 Apr 2003 12:56:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10744 Fri, 11 Apr 2003 15:21:47 -0400 (EDT) Date: Fri, 11 Apr 2003 15:25:49 -0400 From: "Theodore Ts'o" To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. Message-ID: <20030411192548.GC30438@think> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Apr 09, 2003 at 05:53:10PM -0700, Paul Hoffman / VPNC wrote: > > We are better off with just the first sentence and a revision of the > one proposed here by Ted: > > The Identification Payload, denoted ID in this memo, allows peers to > assert an identify to one another. This identity may be used for policy > lookup, but does not necessarily have to match anything in the CERT > payload; both fields may be used by an implementation to perform > access control decisions. Paul's proposed revision seems clearer and reflects the discussion in San Francisco. Does anybody have any problems with this text, or should we just go with it? - Ted From owner-ipsec@lists.tislabs.com Fri Apr 11 12:56:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BJucJM015210; Fri, 11 Apr 2003 12:56:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10758 Fri, 11 Apr 2003 15:25:48 -0400 (EDT) Date: Fri, 11 Apr 2003 15:29:19 -0400 From: "Theodore Ts'o" To: Darren Dukes Cc: ipsec@lists.tislabs.com Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Message-ID: <20030411192919.GD30438@think> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Darren, thanks for your good summary of the pros versus cons of DHCP over IKE vs. Configuration Payload. Only one thing was missing: your weighing on which proposal you think is superior. :-) To the rest of the list, the amount of comments on this item has been extremely underwhelming. Barbara and I would like to call on supporters of the two proposals to send their comments to the list ASAP. We note that in San Francisco the wg had decided that in the absence of strong support, the default would be to stay with the existing text in the ikev2 document (Configuration Payload). - Ted From owner-ipsec@lists.tislabs.com Fri Apr 11 12:56:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BJugJM015223; Fri, 11 Apr 2003 12:56:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10738 Fri, 11 Apr 2003 15:20:46 -0400 (EDT) Date: Fri, 11 Apr 2003 15:24:04 -0400 From: "Theodore Ts'o" To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com, Jeff Schiller , Charlie Kaufman Subject: Re: IKE V2 Open Issues Message-ID: <20030411192404.GB30438@think> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, Most of what you suggest sounds reasonable, although I have one comment: > - The list of crypto algorithms should be in Jeff's document. Leave > the transform IDs in section 3.3.2 of IKEv2, but move everything > starting with "For Transform Type 1..." to Jeff's document. Barbara and I believe that the list of algorithms and numbers which is used to seed the IANA registry should stay in the ikv2 document: For Transform Type 1 (Encryption Algorithm), defined Transform IDs are: Name Number Defined In RESERVED 0 ENCR_DES_IV64 1 (RFC1827) ENCR_DES 2 (RFC2405) ENCR_3DES 3 (RFC2451) ENCR_RC5 4 (RFC2451) ENCR_IDEA 5 (RFC2451) ... The reasoning is that there are other assigned numbers in the ikev2 document, and keeping the initial list in the ikev2 specs will be more convenient for implementors. As with all of the other initial assigned number lists, the list kept by the IANA can be extended in the future without needing to revise the ikev2 document. - Ted From owner-ipsec@lists.tislabs.com Fri Apr 11 12:57:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BJv6JM015239; Fri, 11 Apr 2003 12:57:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10768 Fri, 11 Apr 2003 15:27:50 -0400 (EDT) Date: Fri, 11 Apr 2003 15:31:35 -0400 From: "Theodore Ts'o" To: Uri Blumenthal Cc: Derek Atkins , ipsec@lists.tislabs.com Subject: Re: IKE V2 Open Issues Message-ID: <20030411193135.GE30438@think> References: <3E95C826.50000@bell-labs.com> <3E96CE2D.8040901@bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E96CE2D.8040901@bell-labs.com> User-Agent: Mutt/1.5.3i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Apr 11, 2003 at 10:16:13AM -0400, Uri Blumenthal wrote: > > > >However, another benefit for using two payload types: it makes it > >easier for protocol analyzers like tcpdump or ethereal. They can > >differentiate the cookie request N(COOKIE_REQUIRED{cookie}) from a > >cookie response N(COOKIE{cookie}) to aid in analysis and debugging... > >A small benefit indeed, but a tangible one for, IMHO, little > >additional coding. You have to have the code to parse the packet > >either way -- whether you look for IKEV2_NOTIFY_COOKIE or > >..._COOKIE_REQUIRED is a one-line change. > > OK, sold. I'm convinced in the value of COOKIE_REQUIRED and > support it. > There hasn't been much other discussion on the list, but in the absence of other comments, it seems to make sense to go with this proposal, although it does require defining a new number for COOKIE_REQUIRED. - Ted From owner-ipsec@lists.tislabs.com Fri Apr 11 13:22:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BKMbJM016493; Fri, 11 Apr 2003 13:22:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10878 Fri, 11 Apr 2003 15:52:11 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16023.7639.315149.753112@pkoning.dev.equallogic.com> Date: Fri, 11 Apr 2003 15:56:07 -0400 From: Paul Koning To: askrywan@hotmail.com Cc: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ikev2-06.txt References: X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Andrew" == Andrew Krywaniuk writes: Andrew> As Paul discussed, the MUST clauses can only refer to things Andrew> that affect compliance. Therefore, it sounds to me like the Andrew> only MUST we need is the following: Andrew> "Implementations that provide an interface for the user to Andrew> enter a purely alphanumeric shared secret (i.e. a password), Andrew> must allow that value to be a minimum of 64 bytes(*) long." That sounds like a fine requirement. Andrew> Then there can be the usual warning about poorly-chosen Andrew> passwords elsewhere. Right. Andrew> (*) Alphanumeric characters comprise 1/4th of the available Andrew> 256 bits. Therefore, for 128 bits of key strength, you need a Andrew> minimum of 64 bytes. I think there's a glitch in your arithmetic. If the password is just alphanumeric, that gives 62 possible characters, so just about 6 bits per character. So for 128 bits of key strength you need at least 12 characters. If you assume that a halfway reasonable passphrase has 2 bits of entropy per character, then you do arrive at the minimum of 64 characters. I would suggest not putting that footnote into the spec; simply state the requirement, which is a perfectly sensible one. paul From owner-ipsec@lists.tislabs.com Fri Apr 11 13:23:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BKNMJM016509; Fri, 11 Apr 2003 13:23:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10886 Fri, 11 Apr 2003 15:55:16 -0400 (EDT) Date: Fri, 11 Apr 2003 15:59:27 -0400 From: "Theodore Ts'o" To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: Re: rewrite of IKEv2 Section 2.11 Address and Port Agility Message-ID: <20030411195927.GF30438@think> References: <200304111417.h3BEHbof057932@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304111417.h3BEHbof057932@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.5.3i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis, There seems to be some fundamental differences in the approach that you take to handling NAT traversal and the approach which is currently in ikev2. The approach in ikev2 is substantially similar to what is in the IKEv1 NAT traversal documents, which were authored by Tero Kivinen, Brian Swander, Ari Huttunen, and Victor Volpe, and for which there is implementation experience and a non-trivial amount of testing with currently deployed NAT boxes. Your proposals for changing how NAT traversal would work in ikev2 does not seem to have drawn much resonance with the rest of the working group. In particular, your desire to require that the administrators explicitly declare whether or not NAT traversal should be turned on seems to be at odds with many other wg participants. While it is true that someone on the network path can pretend to be a NAT and redirect the connection, someone who controls a machine on the network path between two end points can achieve this easily anyway. Furthermore, in the road-warrior scenario, most end-users will not necessarily know whether or not they are behind a NAT --- and I think most would agree that it is desireable that users not be forced to know details of how their ISP is provisioning their network service. - Ted From owner-ipsec@lists.tislabs.com Fri Apr 11 13:48:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BKm1JM017498; Fri, 11 Apr 2003 13:48:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11025 Fri, 11 Apr 2003 16:18:45 -0400 (EDT) Date: Fri, 11 Apr 2003 16:23:02 -0400 From: "Theodore Ts'o" To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: Re: peer address update payload Message-ID: <20030411202302.GG30438@think> References: <200304111516.h3BFGmof058143@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304111516.h3BFGmof058143@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.5.3i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis, your proposal doesn't seem to any sense to me: > The following diagram illustrates the content of the Peer Address > Update Notification: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Next Payload !C! RESERVED ! Payload Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > !A| Protocol-ID ! SPI Size ! # of SPIs ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ Security Parameter Index(es) (SPI) ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It's not clear to me where the address used to update the source addr in the SA is coming from, since it is not specified in the packet. If you are assuming that it will be derived from the source address in the IP header, this will be problematic since most implementations will discard the packet upon initial verification of the IP header and the SPI, long before they start processing the IKE payload. In contrast, Tero's proposal (which I include below for convenience) explicitly includes the source address in the notification payload. Unlike your proposal, his does not allow for the simultaneous updating of multiple SPI's. - Ted --------------- Tero's proposal 2.25 Explicit Address Updating For some cases there are needed for explicitly update the peer address. This can be used to support mobile-ip, multihoming, and to help SCTP support. The difference with implicit address updating, is that in this case the other end can actually notify the other end about the change in the address, and authenticate the new address (and port). The explicit address update is done by sending SOURCE-ADDRESS-CHANGED notification, having new port and ip-address inside, to the other end. This notification can be send either using the old or new address, but the sender MUST be able receive in the new address before sending this out. When receiving the SOURCE-ADDRESS-CHANGED notification the IKE process MUST check that the other end can receive the packets sent to new address, by sending empty notification to the peer addres and port given inside the notification (not the UDP outer address). When the host requesting the change replies to that notification, and proofs that it can actually receive packets sent to that address the actual change should take effect. This change affects the IKE SA used to receive the notification (i.e all future exchanges started on that IKE SA will use this new address) and all child IPsec SAs created by this IKE SA (i.e tunnel endpoint updated to new address). The reply to the original SOURCE-ADDRESS-CHANGED notification is sent back to the address where it was received, as is also all other requests, where reply is not yet sent (i.e they follow normal rule, that the reply is sent back to the address where the packet originated). Note, that all hosts are required to process this notification while waiting for reply to their SOURCE-ADDRESS-CHANGED notification (see section 2.3). This requires implementations to support mutating the already existing SAs (one way to implement this is to atomically delete the SA and then add it back with new information). Similar feature is also needed for the implicit address updating needed for NAT traversal, where we need to update the UDP encapsulation addresses and ports. ---------------------------------------------------------------------- Following text should be added to section 3.10.1 after HTTP-CERT-LOOKUP-SUPPORTED: ---------------------------------------------------------------------- SOURCE-ADDRESS-CHANGED 24587 This notification is sent when the other end has changed its IP-address and wants the responder of this notification to update the IKE SA remote peer address and port. When this notification is received the host MUST do the dead peer detection against the address given in this payload, and if that is successful then the IKE SA peer address and all the child SA tunnel endpoint addresses MUST be updated to new address. This notification is not used in the NAT traversal case, as the host behind NAT does not know when its address changes. The data associated with this notification is 2 byte port number and 4 or 16 byte IP-address. From owner-ipsec@lists.tislabs.com Fri Apr 11 13:48:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BKmTJM017525; Fri, 11 Apr 2003 13:48:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11021 Fri, 11 Apr 2003 16:18:42 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Concerning the SOURCE-ADDRESS-CHANGED proposal From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Fri, 11 Apr 2003 16:22:55 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hmm... after looking at Tero's proposal, Barbara and I have found some places where it requires some polishing and attention to corner cases as well: > This notification is sent when the other end has changed ^^^^^^^^^ We assume this should be "sender", or the rest of the sentence doesn't make any sense. > its IP-address and wants the responder of this > notification to update the IKE SA remote peer address and > port. When this notification is received the host MUST > do the dead peer detection against the address given in > this payload, and if that is successful then the IKE SA > peer address and all the child SA tunnel endpoint > addresses MUST be updated to new address. Tero's specification doesn't state what should happen if the dead peer detection fails, or how long the responder should hold onto the address change notification state information and do the "dead peer detection thing" until its peer appears on the new source address. These are minor issues, which can certainly be worked out. But in the interests of time and closure, and given that both Tero's and Francis's proposals are additions to the ikev2 protocol that could be easily specified as an addition in a separate document, Barbara and I will suggest that this be best handled separately from the ikev2 specification. - Ted From owner-ipsec@lists.tislabs.com Fri Apr 11 14:19:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLIwJM019055; Fri, 11 Apr 2003 14:19:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11329 Fri, 11 Apr 2003 16:50:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20030411134521.0544b760@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Apr 2003 13:50:52 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: March 2003 WG Minutes Submitted Cc: byfraser@cisco.com, tytso@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I received no requests for modification to the minutes I posted on April 9, so I will submit them as is. thanks, Barb From owner-ipsec@lists.tislabs.com Fri Apr 11 14:19:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLJ1JM019057; Fri, 11 Apr 2003 14:19:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11335 Fri, 11 Apr 2003 16:50:17 -0400 (EDT) To: "Theodore Ts'o" Cc: Darren Dukes , ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload References: <20030411192919.GD30438@think> Date: 11 Apr 2003 16:51:35 -0400 In-Reply-To: <20030411192919.GD30438@think> Message-ID: Lines: 37 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Personally, I dont have a strong opionion on DHCP-over-IKE vs. Configuration Payload. Both provide the necesaary security hooks I think need to be there, so it's mostly a syntactic, performance, and extensibility issue, rather than a major semantic issue. The question is whether the syntax, performance, and extensibility issues point at one towards the other. I think Config Payload wins on performance, and DHCP-over-IKE wins on extensibility. DHCP certainly wins in terms of using end-to-end DHCP authentication, but that implies the use of a DHCP infrastructure. If the Security Gateway backend is using something other than DHCP then it's probably more work to use DHCP... I think it's probably a toss-up over syntax ;) Ted, I'm sorry this doesn't help add weight to one side or the other. I'm just as happy with flip-a-coin... -derek "Theodore Ts'o" writes: > Darren, thanks for your good summary of the pros versus cons of DHCP > over IKE vs. Configuration Payload. Only one thing was missing: your > weighing on which proposal you think is superior. :-) > > To the rest of the list, the amount of comments on this item has been > extremely underwhelming. Barbara and I would like to call on > supporters of the two proposals to send their comments to the list > ASAP. We note that in San Francisco the wg had decided that in the > absence of strong support, the default would be to stay with the > existing text in the ikev2 document (Configuration Payload). > > - Ted -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Fri Apr 11 14:25:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLPaJM019254; Fri, 11 Apr 2003 14:25:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11395 Fri, 11 Apr 2003 16:58:23 -0400 (EDT) Date: Fri, 11 Apr 2003 17:02:40 -0400 From: "Theodore Ts'o" To: Hugo Krawczyk Cc: Derek Atkins , IPsec WG Subject: Re: IKE V2 Open Issues Message-ID: <20030411210240.GH30438@think> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Apr 11, 2003 at 07:44:41PM +0300, Hugo Krawczyk wrote: > First let me make a clarification that is important to keep in mind > (and relates to an objection that you raised in another message in this > thread). The proposal to protect IDi from active attacks applies ONLY > to the EAP extension of ikev2. All other runs of the protocol (in > particular peer-to-peer runs) will have the same protection that the WG > decided long ago (that is, IDr has full protection while IDi has only > protection against active attacks). Hugo, The proposal that we do things such as "moving IDr, [CERT,] AUTH from msg 4 to msg 2", but only in the case of legacy authentication, is by its very nature complicated. In essence, instead of legacy authentication being just an extra optional EAP payload, it becomes a different protocol with payloads appearing in a different order and information being available at different times. Doing this would complicate the job of the spec writer, the implementor, as well as someone trying to reason about the security properties of IKE. - Ted From owner-ipsec@lists.tislabs.com Fri Apr 11 14:38:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLcJJM019715; Fri, 11 Apr 2003 14:38:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11474 Fri, 11 Apr 2003 17:11:36 -0400 (EDT) Message-Id: <200304112115.h3BLFFlR002801@thunk.east.sun.com> From: Bill Sommerfeld To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload In-Reply-To: Your message of "Wed, 09 Apr 2003 17:19:17 EDT." Reply-to: sommerfeld@east.sun.com Date: Fri, 11 Apr 2003 17:15:15 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As should surprise nobody, I strongly support the use of DHCP over IKE instead of the config payload approach for a number of reasons. Among other things it coexists better with existing non-IPsec network infrastructure and provides a better future expansion/extension path, and avoids a bunch of redundant standardization work. - Bill From owner-ipsec@lists.tislabs.com Fri Apr 11 15:02:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BM2OJM021046; Fri, 11 Apr 2003 15:02:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11595 Fri, 11 Apr 2003 17:33:11 -0400 (EDT) Reply-To: From: "Darren Dukes" To: "Theodore Ts'o" Cc: Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Date: Fri, 11 Apr 2003 17:37:35 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030411192919.GD30438@think> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To me it's a bits on the wire change. I don't particlarly like the 280+ bytes extra or the extra round trips but I don't think they are evil. DHCP end to end may be good in some cased but don't see it as a necessity (others opinions differ here). I'm leaning toward CP just because it's in the current rev. Darren > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Theodore Ts'o > Sent: Friday, April 11, 2003 3:29 PM > To: Darren Dukes > Cc: ipsec@lists.tislabs.com > Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload > > > Darren, thanks for your good summary of the pros versus cons of DHCP > over IKE vs. Configuration Payload. Only one thing was missing: your > weighing on which proposal you think is superior. :-) > > To the rest of the list, the amount of comments on this item has been > extremely underwhelming. Barbara and I would like to call on > supporters of the two proposals to send their comments to the list > ASAP. We note that in San Francisco the wg had decided that in the > absence of strong support, the default would be to stay with the > existing text in the ikev2 document (Configuration Payload). > > - Ted From owner-ipsec@lists.tislabs.com Fri Apr 11 15:15:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BMFBJM022509; Fri, 11 Apr 2003 15:15:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11679 Fri, 11 Apr 2003 17:48:30 -0400 (EDT) Message-Id: <200304112152.h3BLq5ux021015@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload In-reply-to: Your message of "11 Apr 2003 16:51:35 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 11 Apr 2003 17:52:04 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Derek" == Derek Atkins writes: Derek> issues point at one towards the other. I think Config Payload Derek> wins on performance, and DHCP-over-IKE wins on extensibility. Derek> DHCP certainly wins in terms of using end-to-end DHCP Derek> authentication, but that implies the use of a DHCP infrastructure. The use of DHCP syntax on the wire does not imply that a DHCP infrastructure must exist. If you want to build a self-contained gateway box that manages its own address pool (on the box irself), then you can do that. If you want to translate to other infrasture (radius), Tero has documented how to do that. Tero also argues that if you are using Radius with EAP, that your round trip count is already larger than 4, so DHCP does not add to it. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Fri Apr 11 16:03:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BN39JM024521; Fri, 11 Apr 2003 16:03:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11962 Fri, 11 Apr 2003 18:31:16 -0400 (EDT) Message-Id: <200304112235.h3BMZ7of059373@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: rewrite of IKEv2 Section 2.11 Address and Port Agility In-reply-to: Your message of Fri, 11 Apr 2003 15:59:27 EDT. <20030411195927.GF30438@think> Date: Sat, 12 Apr 2003 00:35:07 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: There seems to be some fundamental differences in the approach that you take to handling NAT traversal and the approach which is currently ikev2. => I am afraid that it is mainly a problem of wording, for instance when I've just reread my messages (I've tried to understand why you believe there are deep differences) it's seemed I failed to explain clearly enough than active NAT traversal and peer address protection are mutually exclusive. I'm afraid you didn't read my messages in the right order too (the first one is the peer address protection format, the second is the 2.11 rewrite and the last one is the peer address update payload). The approach in ikev2 is substantially similar to what is in the IKEv1 NAT traversal documents, which were authored by Tero Kivinen, Brian Swander, Ari Huttunen, and Victor Volpe, and for which there is implementation experience and a non-trivial amount of testing with currently deployed NAT boxes. => in fact not only I agree but I'd like that Tero's comments will be ASAP included in the draft because the current text is both not enough clear and incomplete (the implicit peer address update is not specified when it is very useful). Your proposals for changing how NAT traversal would work in ikev2 does not seem to have drawn much resonance with the rest of the working group. => unfortunately there is a security flaw in the common NAT traversal support in signaling protocols like IKE, and it drew resonance in the mobile-ip WG (cf draft-ietf-mobileip-nat-traversal-XX.txt). IMHO as there is some relationship problems between the ipsec and the mobile-ip WGs, this issue should be taken into account. In particular, your desire to require that the administrators explicitly declare whether or not NAT traversal should be turned on => is it the NAT traversal support enabled/disabled? seems to be at odds with many other wg participants. While it is true that someone on the network path can pretend to be a NAT and redirect the connection, someone who controls a machine on the network path between two end points can achieve this easily anyway. => but it can't continue to redirect the traffic if it leaves the path. The issue with signaling protocols is the attacker who only hacks some packets will redirect a possibly large amount of traffic for a long time. It is too late to fix IKEv1 but I can't believe you'd like to publish IKEv2 with this kind of flaw... Furthermore, in the road-warrior scenario, most end-users will not necessarily know whether or not they are behind a NAT => they wish that they are not behind a NAT (:-)! and I think most would agree that it is desireable that users not be forced to know details of how their ISP is provisioning their network service. => I don't parse your last sentence: in these 3 messages I never suggest to forbid NAT traversal, I only considered there is a knob in the policy (not a global one, the decision is done in the IKE_AUTH exchange, i.e., after NAT detection and for the responder with the ID and the authentication stuff) which says if the NAT traversal support is enabled or disabled. I even added in the rationale/introduction part that the policy should allow to activate the NAT traversal support when no NAT was detected. But as I wrote, I am waiting for the next text about NAT traversal in order to see if there still are little details to discuss. BTW in the case of a road-warrior over IPv4, the policy should allow NAT traversal support on the client and on the server (in the VPN software I use the policy is in fact controlled by the server). But between two SGs and when the administrator knows there is no NAT, he should get the possibility to forbid NAT traversal support. The same when IPv6 is used. And as far as I know, all reasonable softwares either lack NAT traversal support or provide this kind of knob in their config (i.e., I can't see what is the problem). Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Apr 11 16:31:31 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BNVVJM025683; Fri, 11 Apr 2003 16:31:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12133 Fri, 11 Apr 2003 19:03:39 -0400 (EDT) Message-Id: <200304112307.h3BN7Wof059462@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: peer address update payload In-reply-to: Your message of Fri, 11 Apr 2003 16:23:02 EDT. <20030411202302.GG30438@think> Date: Sat, 12 Apr 2003 01:07:32 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Francis, your proposal doesn't seem to any sense to me: > The following diagram illustrates the content of the Peer Address > Update Notification: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Next Payload !C! RESERVED ! Payload Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > !A| Protocol-ID ! SPI Size ! # of SPIs ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ Security Parameter Index(es) (SPI) ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It's not clear to me where the address used to update the source addr in the SA is coming from, since it is not specified in the packet. => argh! IP packets have no source addresses? To be serious, perhaps the text should repeat this requirement "The explicit mechanism SHALL be used when NAT traversal support is not active, i.e., when IKE runs over UDP port 500 with protected peer addresses and only it this case" which is after the format description in my message but will be before in the draft. If you are assuming that it will be derived from the source address in the IP header, this will be problematic since most implementations will discard the packet upon initial verification of the IP header and the SPI, long before they start processing the IKE payload. => and where they get the addresses to setup tunnel mode SAs? Where they get the addresses for sending responses? These implementations don't interoperate correctly in IKEv1 and won't be compliant in IKEv2. In contrast, Tero's proposal (which I include below for convenience) => I know it: it is a subset of my proposal, it doesn't fix the pseudo-NAT problem and is not powerful enough for multi-homing. explicitly includes the source address in the notification payload. => in my proposal the source address is in a mandatory peer address protection notification, so there is no need to include it twice. BTW these peer address protection notifications are in every messages when the NAT traversal is not active so the source address cannot be changed en route for other critical operations like a CREATE_CHILD_SA exchange. Unlike your proposal, his does not allow for the simultaneous updating of multiple SPI's. => at the opposite his does allow only the simultaneous updating of all SAs: "This change affects the IKE SA used to receive the notification (i.e all future exchanges started on that IKE SA will use this new address) and all child IPsec SAs created by this IKE SA (i.e tunnel endpoint updated to new address)." This is a common case, covered in my proposal by the ALL flag, but this is not the only case in multi-homed environments. There is another difference, Tero's proposal works from the old souce address but this will give only a win of 1/2 RTT in some cases at the cost of 1 RTT for some others (cf the thread between me and Jari). Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Apr 11 16:38:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BNcGJM025774; Fri, 11 Apr 2003 16:38:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12168 Fri, 11 Apr 2003 19:10:44 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <20030411192404.GB30438@think> References: <20030411192404.GB30438@think> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 11 Apr 2003 16:14:27 -0700 To: "Theodore Ts'o" From: Paul Hoffman / VPNC Subject: Re: IKE V2 Open Issues Cc: ipsec@lists.tislabs.com, Jeff Schiller , Charlie Kaufman Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:24 PM -0400 4/11/03, Theodore Ts'o wrote: >Barbara and I believe that the list of algorithms and numbers which is >used to seed the IANA registry should stay in the ikv2 document: > > For Transform Type 1 (Encryption Algorithm), defined Transform IDs > are: > > Name Number Defined In > RESERVED 0 > ENCR_DES_IV64 1 (RFC1827) > ENCR_DES 2 (RFC2405) > ENCR_3DES 3 (RFC2451) > ENCR_RC5 4 (RFC2451) > ENCR_IDEA 5 (RFC2451) > ... > >The reasoning is that there are other assigned numbers in the ikev2 >document, and keeping the initial list in the ikev2 specs will be more >convenient for implementors. None of the "other assigned numbers" are dealt with in Jeff's document; these are. Implementers *have* to read both documents. They cannot implement the mandatory algorithms without reading Jeff's document. Thus, having the algorithm identifiers in the same document as the explanations of what is mandatory makes more sense than putting the numeric values in one document and the protocol description of the values (what is mandatory and what is not) in a different document. > As with all of the other initial >assigned number lists, the list kept by the IANA can be extended in >the future without needing to revise the ikev2 document. Assuming everything goes cleanly, that's correct. VPN vendors have seen this not go cleanly. If we choose to change the mandatory or suggested values in Jeff's document to something that is not in the base document, we'll then have numbers in *both* documents in the future; that's a mess. If we start off with all of initial registries in Jeff's document, revising Jeff's document will be cleaner. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Apr 11 16:48:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BNm4JM026333; Fri, 11 Apr 2003 16:48:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12205 Fri, 11 Apr 2003 19:20:49 -0400 (EDT) Message-Id: <200304112325.h3BNPAof059529@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: Concerning the SOURCE-ADDRESS-CHANGED proposal In-reply-to: Your message of Fri, 11 Apr 2003 16:22:55 EDT. Date: Sat, 12 Apr 2003 01:25:10 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > its IP-address and wants the responder of this > notification to update the IKE SA remote peer address and > port. When this notification is received the host MUST => note that this problem (to trust in the peer to give its real address or to perform a return routability check) was discussed for mobile IPv6 and the conclusion is to trust the peer in some cases (I can send references if you are interested): I have a concern about this MUST (in my proposal it is a SHOULD and there is a MAY if the responder decides to not perform the check). > do the dead peer detection against the address given in > this payload, and if that is successful then the IKE SA > peer address and all the child SA tunnel endpoint > addresses MUST be updated to new address. Tero's specification doesn't state what should happen if the dead peer detection fails, or how long the responder should hold onto the address change notification state information and do the "dead peer detection thing" until its peer appears on the new source address. => you've put the finger on some reasons I don't like the idea to allow to send an update from the old address (something which is not allowed too in mobile IP): a lot of problems for a little gain in some cases... These are minor issues, which can certainly be worked out. But in the interests of time and closure, and given that both Tero's and Francis's proposals are additions to the ikev2 protocol that could be easily specified as an addition in a separate document, Barbara and I will suggest that this be best handled separately from the ikev2 specification. => I have no problem with that. I always wrote or said the update itself can be postponed (it will be the first critical payload :-) because it can be simulated by rekeying, i.e., it is only an optimization. Note this is *not* the case for the peer address protection (which fixes a security flaw) or for a better text for NAT traversal... Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Apr 11 21:57:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C4v7JM010335; Fri, 11 Apr 2003 21:57:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA13150 Sat, 12 Apr 2003 00:25:25 -0400 (EDT) Message-ID: <3E97960F.6050704@kolumbus.fi> Date: Sat, 12 Apr 2003 07:29:03 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Theodore Ts'o" Cc: ipsec@lists.tislabs.com Subject: Re: Concerning the SOURCE-ADDRESS-CHANGED proposal References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Ts'o wrote: > These are minor issues, which can certainly be worked out. But in the > interests of time and closure, and given that both Tero's and > Francis's proposals are additions to the ikev2 protocol that could be > easily specified as an addition in a separate document, Barbara and I > will suggest that this be best handled separately from the ikev2 > specification. I would actually like to see Tero's scheme in the base IKEv2 document. An ability to cope with changing addresses is becoming essential in today's networks. Roaming around, being mobile, multi-homing, ... all of these call for an ability to change addresses. While it is true that rekeying can help here as well, its really undesireable solution for many people. Jari P.S. I can also promise to contribute in solving the issues you identified. From owner-ipsec@lists.tislabs.com Sat Apr 12 05:14:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CCEfJM028923; Sat, 12 Apr 2003 05:14:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA14012 Sat, 12 Apr 2003 07:41:37 -0400 (EDT) Message-ID: <3E97EA4A.9030102@roc.co.in> Date: Sat, 12 Apr 2003 15:58:26 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sommerfeld@east.sun.com CC: "Theodore Ts'o" , ipsec@lists.tislabs.com Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload References: <200304112115.h3BLFFlR002801@thunk.east.sun.com> Content-Type: multipart/alternative; boundary="------------020300030208030909010309" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------020300030208030909010309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Bill, I prefer configuration payload for serving the IP address, Domain name servers and other information. It gives flexibility in the deployment and the configuration can be configured locally OR configuration can be retrieved from the DHCP Server OR other mechanism. So, by de-coupling the serving IP address from specific protocol like DHCP will give lot of flexibility. -Ravi Bill Sommerfeld wrote: >As should surprise nobody, I strongly support the use of DHCP over IKE >instead of the config payload approach for a number of reasons. > >Among other things it coexists better with existing non-IPsec network >infrastructure and provides a better future expansion/extension path, >and avoids a bunch of redundant standardization work. > > - Bill > > > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------020300030208030909010309 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Hi Bill,
I prefer configuration payload for serving the IP address,
Domain name servers and other information. 
It gives flexibility in the deployment and the configuration 
can be configured locally OR configuration can be retrieved
from the DHCP Server OR other mechanism. So, by de-coupling
the serving IP address from specific protocol like DHCP 
will give lot of flexibility.
-Ravi

Bill Sommerfeld wrote:
As should surprise nobody, I strongly support the use of DHCP over IKE
instead of the config payload approach for a number of reasons.

Among other things it coexists better with existing non-IPsec network
infrastructure and provides a better future expansion/extension path,
and avoids a bunch of redundant standardization work.

					- Bill

--
signature

The views presented in this mail are completely mine. The company is not responsible for whatsoever.
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page



--------------020300030208030909010309-- From owner-ipsec@lists.tislabs.com Sat Apr 12 05:14:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CCEhJM028929; Sat, 12 Apr 2003 05:14:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA14018 Sat, 12 Apr 2003 07:42:37 -0400 (EDT) Message-ID: <3E97ECD1.3050506@roc.co.in> Date: Sat, 12 Apr 2003 16:09:13 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Theodore Ts'o" CC: Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <20030411192548.GC30438@think> Content-Type: multipart/alternative; boundary="------------000404070104050906070507" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------000404070104050906070507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, This text is very clear. I support this wording -Ravi Theodore Ts'o wrote: >On Wed, Apr 09, 2003 at 05:53:10PM -0700, Paul Hoffman / VPNC wrote: > > >>We are better off with just the first sentence and a revision of the >>one proposed here by Ted: >> >> The Identification Payload, denoted ID in this memo, allows peers to >> assert an identify to one another. This identity may be used for policy >> lookup, but does not necessarily have to match anything in the CERT >> payload; both fields may be used by an implementation to perform >> access control decisions. >> >> > >Paul's proposed revision seems clearer and reflects the discussion in >San Francisco. Does anybody have any problems with this text, or >should we just go with it? > > - Ted > > > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------000404070104050906070507 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,
This text is very clear. I support this wording
-Ravi

Theodore Ts'o wrote:
On Wed, Apr 09, 2003 at 05:53:10PM -0700, Paul Hoffman / VPNC wrote:
  
We are better off with just the first sentence and a revision of the 
one proposed here by Ted:

   The Identification Payload, denoted ID in this memo, allows peers to
   assert an identify to one another. This identity may be used for policy
   lookup, but does not necessarily have to match anything in the CERT
   payload; both fields may be used by an implementation to perform
   access control decisions.
    

Paul's proposed revision seems clearer and reflects the discussion in
San Francisco.  Does anybody have any problems with this text, or
should we just go with it?

							- Ted

--
signature

The views presented in this mail are completely mine. The company is not responsible for whatsoever.
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page



--------------000404070104050906070507-- From owner-ipsec@lists.tislabs.com Sat Apr 12 13:15:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CKFTJM026485; Sat, 12 Apr 2003 13:15:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14983 Sat, 12 Apr 2003 15:34:52 -0400 (EDT) Message-Id: <5.2.0.9.0.20030412122124.034c2748@mail.attbi.com> X-Sender: alten@mail.attbi.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 12 Apr 2003 12:35:25 -0700 To: ipsec@lists.tislabs.com From: Alex Alten Subject: exporting IPsec? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Has anyone on this list encountered any issues with exporting IPsec from USA/Canada to other countries? In particular I'd curious to know what types of restrictions; key length, countries approved (or not), escrow requirements, product type restrictions (network hardware, software), etc. Did you have to maintain two types of product one for North America and the other for overseas? I'm not looking for names in particular, just whether or not the BXA would approve (or not) types of IPsec products to areas of the planet (Europe, Asia, etc.), and what types of restrictions were placed on successful export licenses. Also, out of curiosity, has Sept. 11th caused any tightening of the export requirements? Are you finding it harder to get BXA license approval? - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Sat Apr 12 19:17:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3D2H4JM010794; Sat, 12 Apr 2003 19:17:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA15703 Sat, 12 Apr 2003 21:39:52 -0400 (EDT) Message-Id: <200304121323.h3CDNpge011215@ritz.appli.se> To: Ravi cc: "Theodore Ts'o" , Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-reply-to: Your message of "Sat, 12 Apr 2003 16:09:13 +0530." <3E97ECD1.3050506@roc.co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Sat, 12 Apr 2003 15:23:50 +0200 From: Niklas Hallqvist X-RAVMilter-Version: 8.4.1(snapshot 20020920) (ritz) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Am I the only one spotting the typo? s/identify/identity/ Otherwise it is ok. Niklas > Date: Sat, 12 Apr 2003 16:09:13 +0530 > From: Ravi > > > --------------000404070104050906070507 > Content-Type: text/plain; charset=us-ascii; format=flowed > Content-Transfer-Encoding: 7bit > > Hi, > > This text is very clear. I support this wording > -Ravi > > > Theodore Ts'o wrote: > > >On Wed, Apr 09, 2003 at 05:53:10PM -0700, Paul Hoffman / VPNC wrote: > > > > > >>We are better off with just the first sentence and a revision of the > >>one proposed here by Ted: > >> > >> The Identification Payload, denoted ID in this memo, allows peers to > >> assert an identify to one another. This identity may be used for policy > >> lookup, but does not necessarily have to match anything in the CERT > >> payload; both fields may be used by an implementation to perform > >> access control decisions. > >> > >> > > > >Paul's proposed revision seems clearer and reflects the discussion in > >San Francisco. Does anybody have any problems with this text, or > >should we just go with it? > > > > - Ted > > > > > > > > -- > > > The views presented in this mail are completely mine. The company is not > responsible for whatsoever. > ------------------------------------------------------------------------ > Ravi Kumar CH > Rendezvous On Chip (i) Pvt Ltd > Hyderabad, India > Ph: +91-40-2335 1214 / 1175 / 1184 > > ROC home page > > > > > --------------000404070104050906070507 > Content-Type: text/html; charset=us-ascii > Content-Transfer-Encoding: 7bit > > > > > > > > > Hi,
> 
This text is very clear. I support this wording
> -Ravi
>
>
> Theodore Ts'o wrote:
>
> 
On Wed, Apr 09, 2003 at 05:53:10PM -0700, Paul Hoffman / VPNC wrote:
>
>
> 
We are better off with just the first sentence and a revision of the 
> one proposed here by Ted:
> 
>    The Identification Payload, denoted ID in this memo, allows peers to
>    assert an identify to one another. This identity may be used for policy
>    lookup, but does not necessarily have to match anything in the CERT
>    payload; both fields may be used by an implementation to perform
>    access control decisions.
>
>
> 

> Paul's proposed revision seems clearer and reflects the discussion in
> San Francisco.  Does anybody have any problems with this text, or
> should we just go with it?
> 
> 							- Ted
> 
>
>
>
>
--
> signature > > >
>
> The views presented in this mail are completely mine. The company is not > responsible for whatsoever.
> >
face="Times New Roman, Times, serif">Ravi Kumar CH
> Rendezvous On Chip (i) Pvt Ltd
> Hyderabad, India
> Ph: +91-40-2335 > 1214 / 1175 / 1184
>
> ROC home page
>
>
>
>
> > > > --------------000404070104050906070507-- > From owner-ipsec@lists.tislabs.com Sat Apr 12 19:17:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3D2H9JM010799; Sat, 12 Apr 2003 19:17:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA15722 Sat, 12 Apr 2003 21:43:55 -0400 (EDT) Message-Id: <5.1.0.14.0.20030411160456.0451a210@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 12 Apr 2003 11:01:05 -0400 To: IPsec WG From: David Jablon Subject: Re: draft-ietf-ipsec-ikev2-06.txt In-Reply-To: References: <5.1.0.14.0.20030410101831.04527960@pop.theworld.com> <5.1.0.14.0.20030409151544.04582a30@pop.theworld.com> <5.1.0.14.0.20030408104652.00a37ec0@pop.theworld.com> <5.1.0.14.0.20030408104652.00a37ec0@pop.theworld.com> <5.1.0.14.0.20030409151544.04582a30@pop.theworld.com> <5.1.0.14.0.20030410101831.04527960@pop.theworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, In light of your repeated inappropriate referrals to RFC 2119, a few things need to be said. >At 11:57 AM -0400 4/10/03, David Jablon wrote: >>I think the use of very weak keys breaks the utility of the method, >>and even if allowed, should not be encouraged. At 10:15 AM 4/10/03 -0700, Paul Hoffman / VPNC wrote: >It doesn't break the utility of the method, it weakens it. There is a huge difference there. If it breaks it, you cannot ever allow it; if it weakens it, you are responsible for pointing out the weakness. There is no huge difference between a 20-bit key and a zero-bit key, in this method. They're both broken. Do you really want to argue otherwise? David wrote: >>I wonder if we can agree that the "MUST" text in the first part works? >>Especially in light of the two other points that Hugo raised: >>(1) that having the first case be "MUST" fixes other problems, and >>(2) that it still permits implementors to derive full-length keys from >>passwords of arbitrary length using arbitrary functions, if they so choose. Paul wrote: >No, we still don't agree. If we say that the definition of MUST etc. comes from RFC 2119, we have to use that definition. This isn't hair-splitting: it is simple protocol mechanics. I see you also don't agree with being particularly polite too, in continuing to imply that I am somehow ignorant of the rules or unable to apply them. Regarding the text in question: "When pre-sharing a key for use in prf-based authentication (i.e., "Shared Secret") the key MUST be of the length of the key for the prf agreed for use by the parties. It merely mandates the size of a value that used to create another protocol element, in the interest of guaranteeing interoperability and increasing security. This is more than sufficient motivation for using the term MUST. Whether the text actually achieves those objectives, without introducing unwanted side-effects, may be a point of debate. But it cannot legitimately be dismissed by simply telling the opponent to go read a dictionary. Speaking of which: From RFC 2119: >6. Guidance in the use of these Imperatives > > [The imperative "MUST"] MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) Regarding interoperation, it is actually required that two parties agree on key size. This motivates providing clear guidance for the appropriate key size, or range of key sizes, that implementations must support. And I have heard no technical reason of any kind to motivate using a *key* size other than the size of the prf key. Note, again, that password size is a different matter than key size. Specifying limits for acceptable key length does not imply any limits on the length of a password. One can use hash, padding, and truncation functions to transform any password into a key of any desired length. Limitations on key size may constrain the choices of such a transformation method, but, I believe this could only have a *positive* effect on interoperability, even if you dismiss Hugo's stated positive effect on security. Regarding security, I simply call attention to the words "to limit behavior which has the potential for causing harm". Maybe I've misinterpreted your words, but this sounds like a *significantly* lower threshhold for use of the term "MUST" than your interpretation. Are "retransmissions" so much more devastating than using a very weak key? Paul wrote: >Please remember that we are talking about pre-shared keys here: *both* parties have to agree to using any particular key. If that is their shared security policy (even after our exhortations about the weakness of it), then that is what they want. I presume your words attempt to justify the point that people should be able to get the rope to do it. Fine. I gave that one to you already, and I won't debate it ... unless you really really want me to. My point is that people already have that rope, to use a password of any size or quality, regardless of any MUST/SHOULD limitations on key size. Thus, your words are pointless in an argument against the use of "MUST" in this context. David wrote: >>I see no need to re-define "MUST" and "SHOULD" to support this point: >>The "SHOULD" here gives license to an implementator to do potentially >>nasty things, like say, truncating all such keys to 64-bits, >>in the interest of handling passwords in some way. Paul wrote: >Only if they have a technical reason to do so; that's what RFC 2119 says. Loose specs. sink ships. Can anyone think of *any* legitimate technical reason to use other *key* sizes? Why leave potential implementors guessing? >There is no technical reason that I know of that says that the length of the key matters to the PRF. If the length is shorter, the PRF will not fail, it will simply produce that much less value. I believe that a decreased level of security, with the *potential* to cause harm, perhaps by naive or confused implementors, *is* a valid technical reason. Especially if the concern is easily avoided. David wrote: >>That "MUST" here helps to guarantee interoperability when using >>full-length keys, and that "SHOULD" does not, is something I thought >>you'd agree with. And if not then, then perhaps now, in light of points >>(1) and (2) above. Paul wrote: >Sorry, maybe I'm being dense. I don't see how the SHOULD would not guarantee the interoperability. Let's say that both sides are using a PRF that wants 128 bits of keying material, and the two parties agree to a shared secret of "Baseball2003". How is the guarantee of interoperability broken? I'm going to deliberately sound dense in this first part of the answer, to make a point: I have no idea what it means to "agree on a shared secret [key] of "Baseball2003"". Of course, I do have a fairly good idea of what it means to agree on a shared secret *password* of "Baseball2003". But without knowing binary character representation (ASCII, UNICODE, ...?) and other aspects of the necessary, but unspecified, password-to-key transformation function (hash it, pad it, truncate it, include the null, ...?), it's not at all clear that two different implementations will interoperate using a shared password. Second, the SHOULD version of the text by itself does not absolutely guarantee support for *keys* that have a size that matches the prf. One implementation may use fixed 128-bit keys, another may use 256, and a third may use another arbitrary range, all for reasons that a (perhaps naive) implementor may deem technically valid. How can one determine a set of keys that will work for all implementations? "SHOULD support X" is not the same as "MUST support X and MAY support Y". There are multiple kinds of interoperability concerns, between different implementations using a given key, between different implementations using a given password, and between different implementations where only one provides a convenient means to enter a password. But even if the text is *never* be clear about how to deal with passwords in a standard way in this pre-shared key mechanism, it *must* be crystal clear how to deal with keys. The MUST version achieves that, and draws a clear line in the sand between passwords and keys, whereas the SHOULD version does neither. Paul wrote: >The IETF almost never mandates how a user interface or documentation should act. This is meant to be an IETF protocol, so we have to follow the IETF rules. That's why we are using RFC 2119, even though we could use some other definitions of MUST and SHOULD if we wanted to. Please, spare us all the unnecessary lecture. David wrote: >>I think the current draft has already crossed the line in talking about the kinds >>of keying material (e.g. passwords) that users will presumably stuff into the >>user interface. Paul wrote: >Where in the draft is that? Surely you're not asking about where in the draft it talks about passwords, and a password obviously has to come from somewhere. But this is old news. I addressed your concern anyway. Just in case you missed it, I carefully avoided using RFC 2119 terms with regard to passwords in the text in the message to which you've responded, in light of your concern that passwords are elements of the user interface. My main point, in case I haven't beaten it to death by now, is that a "password" is not the same thing as a "key". Part of your argument only makes sense if one mistakenly interprets these terms as synonyms. Regardless of how the text ends up, I urge that the distinction between passwords and keys be kept clear, and that at least interoperability when using keys be guaranteed. -- David From owner-ipsec@lists.tislabs.com Mon Apr 14 06:28:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EDS01r055120; Mon, 14 Apr 2003 06:28:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19465 Mon, 14 Apr 2003 08:43:20 -0400 (EDT) Date: Mon, 14 Apr 2003 08:46:09 -0400 From: "Theodore Ts'o" To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com, Jeff Schiller , Charlie Kaufman Subject: Re: IKE V2 Open Issues Message-ID: <20030414124609.GB6909@think> References: <20030411192404.GB30438@think> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Apr 11, 2003 at 04:14:27PM -0700, Paul Hoffman / VPNC wrote: > None of the "other assigned numbers" are dealt with in Jeff's > document; these are. > > Implementers *have* to read both documents. They cannot implement the > mandatory algorithms without reading Jeff's document. Thus, having > the algorithm identifiers in the same document as the explanations of > what is mandatory makes more sense than putting the numeric values in > one document and the protocol description of the values (what is > mandatory and what is not) in a different document. Implementors can start implementing IKEv2 without knowing exactly which algorithms will be mandatory and which will be optional. In most implementations which I've seen, the choice of such things is kept in a modular design, and given that we've already said that what will be mandatory will be changing over time, a wise implementor will certainly make their product easy to update with respect to what crypto algorithms are in use. Furthermore, I would like to reduce the number of interdependencies on the ikev2 document, so that we don't end up having to hold up the ikev2 document based on external dependencies. The good news is that Jeff has finished the first cut at the document, so this is not to say that I don't have faith that the second document won't be immediately forthcoming. However, Barbara and I would like to be able to get ikev2 off our hands and into the IESG's plate as soon as possible, and so anything where we can remove dependencies is a good thing. Due to its complexity ikev2 will probably require extra time for the IESG to consider, if past experience with IKE is any guide. So we can finish polishing the required crypto algorithms document in parallel with the IESG cogitating over ikev2, and once it's ready, we can ship that off to the IESG, and given that the required crypto algorithms document will be much simpler, I imagine that will be able to zip through the IESG review stage very quickly. Having seen a first draft of Jeff's document, one compromise which I think would work well is to have the initial definition of algorithms and assigned numbers in both documents. Given that it is the IANA registry which is authoratative, NOT either of these documents, having the numbers in both places will be most convenient to the implementors, and allows us to avoid having a forward dependency from ikev2 to the "required algorithms" draft. Russ, Steve --- procedurally, do you think any of the IESG nit-pickers/process mavens will have a problem with this approach? - Ted From owner-ipsec@lists.tislabs.com Mon Apr 14 06:36:31 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EDaU1r055403; Mon, 14 Apr 2003 06:36:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19538 Mon, 14 Apr 2003 09:03:41 -0400 (EDT) Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'Yaron Sheffer'" , IPSec List , rohc@ietf.org Subject: RE: [rohc] FW: ESP and header compression (ROHC) Date: Mon, 14 Apr 2003 09:04:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, A few notes: 1) ROHC is applied on a per-link basis, e.g. over PPP 2) Based on the above point, there are ROHC compression profiles defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) Compressing the network layer header is most important to gain anything, but that can only be done on a per-link basis. Header compression is thus applied per-link to compress network and transport layer headers (and by heuristics also the application layer RTP header). It is also simpler to do compression per-link, as one can optimize for certain assumed characteristics (such as in-order delivery). Further, it makes most sense as header compression is an optimization for "narrow links". Therefore, I can not see why/how one could do "ROHC over ESP". BR /Lars-Erik > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf@gmx.net] > Sent: den 13 april 2003 21:26 > To: IPSec List; rohc@ietf.org > Subject: [rohc] FW: ESP and header compression (ROHC) > > > (please reply to both lists) > > Below is my question to Steve Kent (author of the new rev of ESP, and > co-author of the original RFC) and his reply. I understand > that IPCOMP is > inferior to ROHC for RTP streams, and I'd like to hear other opinions > regarding the usefulness of an "ROHC" indicator in ESP. > > This might certaily add complexity to IPSec, but if you make it > non-negotiable and non-mandatory, it cannot be too terrible. > > Thanks, > Yaron > > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Thursday, April 10, 2003 12:06 AM > To: Yaron Sheffer > Cc: Sara Bitan; kent@bbn.com > Subject: Re: ESP and header compression (ROHC) > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > >Hi Steve, > > > >I have lately looked at issues with IPSec encryption of RTP > streams (I am > >aware of SRTP but I think we will want RTP over IPSec for > some time to > >come). A major issue is packet overhead. You can use Robust Header > >Compression (ROHC) on the external IP+ESP headers - this is > defined by the > >ROHC RFC. But if you want to header-compress the RTP packets > before it is > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > because there's no > >way to detect ROHC packets in the ESP header. I'd expect ESP > to contain a > >marker for ROHC packets, similarly to PPP. Has this option > been considered > >for the new version of ESP? > > > >Thanks, > > Yaron > > No, the WG has not considered that option. The WG has been striving > to make IPsec simpler and thus adding support for ROHC is contrary to > that theme. For example, ROHC would have be be implemented within > IPsec, after the SA lookup was performed, and ROHC decompression > would have to be implemented in IPsec at the receiver, since the > receiver has to check the headers against the SAD. IPsec already > supports IPCOMP as a compression method for whole packets, not just > headers, and thus it might be hard to persuade the WG to add ROHC > support too. > > But, that's just my impression. You can always raise the > question on the > list. > > Steve > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > From owner-ipsec@lists.tislabs.com Mon Apr 14 06:47:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EDlh1r056175; Mon, 14 Apr 2003 06:47:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19566 Mon, 14 Apr 2003 09:13:47 -0400 (EDT) Message-ID: <3E9A3266.9060708@roc.co.in> Date: Mon, 14 Apr 2003 09:30:38 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Dead Peer Detection Content-Type: multipart/alternative; boundary="------------070208010508030107010308" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------070208010508030107010308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi All, I was going through Dead Peer Detection version 2. Are there any windows based VPN clients supporting this draft OR version 1 draft? I would like this for my interoperability testing. Thanks in advance, Ravi. -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------070208010508030107010308 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, I was going through Dead Peer Detection version 2. Are there any windows based VPN clients supporting this draft OR version 1 draft? I would like this for my interoperability testing. Thanks in advance, Ravi. -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------070208010508030107010308-- From owner-ipsec@lists.tislabs.com Mon Apr 14 06:48:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EDmA1r056201; Mon, 14 Apr 2003 06:48:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19572 Mon, 14 Apr 2003 09:13:50 -0400 (EDT) Message-ID: <3E9A3AC7.9060302@roc.co.in> Date: Mon, 14 Apr 2003 10:06:23 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Regarding Peer Address Update Content-Type: multipart/alternative; boundary="------------060809080104000003040005" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------060809080104000003040005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi All, I also felt that this feature is very powerful feature where the IKE SA and IPSEC SAs are not terminated even when the external IP address of box changes (via DHCP from ISP or PPP from ISP OR in case of mobile-ip, it is care-of-address that changes). Whenever the IP address is changed, it can inform the peer of this change. I have some questions and comments: 1. If the security appliance OR client is behind the NAT gateway, it should not send the address update. Also, if the NAT traversal is active, then this update request should not be honored by the responder of this message. 2. What is the need for sending SPIs in UPDATE request? IKE receives this message on a particular IKE SA. IKE SA has original IP address and from the source IP address of the packet, it knows the new IP address. This new IP address is used to update the IKE SA and corresponding IPSEC SAs. Regards, Ravi -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------060809080104000003040005 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, I also felt that this feature is very powerful feature where the IKE SA and IPSEC SAs are not terminated even when the external IP address of box changes (via DHCP from ISP or PPP from ISP OR in case of mobile-ip, it is care-of-address that changes). Whenever the IP address is changed, it can inform the peer of this change. I have some questions and comments: 1. If the security appliance OR client is behind the NAT gateway, it should not send the address update. Also, if the NAT traversal is active, then this update request should not be honored by the responder of this message. 2. What is the need for sending SPIs in UPDATE request? IKE receives this message on a particular IKE SA. IKE SA has original IP address and from the source IP address of the packet, it knows the new IP address. This new IP address is used to update the IKE SA and corresponding IPSEC SAs. Regards, Ravi -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------060809080104000003040005-- From owner-ipsec@lists.tislabs.com Mon Apr 14 06:48:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EDmF1r056213; Mon, 14 Apr 2003 06:48:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19595 Mon, 14 Apr 2003 09:15:49 -0400 (EDT) Message-ID: <3E9AB15F.4010102@creeksidenet.com> Date: Mon, 14 Apr 2003 09:02:23 -0400 From: "jpickering@creeksidenet.com" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: "Theodore Ts'o" CC: Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <20030411192548.GC30438@think> Content-Type: multipart/alternative; boundary="------------090601000002060605000300" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------090601000002060605000300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Go with it. - jeff Theodore Ts'o wrote: > On Wed, Apr 09, 2003 at 05:53:10PM -0700, Paul Hoffman / VPNC wrote: > >> We are better off with just the first sentence and a revision of the >> one proposed here by Ted: >> >> The Identification Payload, denoted ID in this memo, allows peers to >> assert an identify to one another. This identity may be used for policy >> lookup, but does not necessarily have to match anything in the CERT >> payload; both fields may be used by an implementation to perform >> access control decisions. > > > Paul's proposed revision seems clearer and reflects the discussion in > San Francisco. Does anybody have any problems with this text, or > should we just go with it? > > - Ted > > > --------------090601000002060605000300 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Go with it. - jeff Theodore Ts'o wrote: >On Wed, Apr 09, 2003 at 05:53:10PM -0700, Paul Hoffman / VPNC wrote: >> >>We are better off with just the first sentence and a revision of the >>one proposed here by Ted: >> >> The Identification Payload, denoted ID in this memo, allows peers to >> assert an identify to one another. This identity may be used for policy >> lookup, but does not necessarily have to match anything in the CERT >> payload; both fields may be used by an implementation to perform >> access control decisions. > > >Paul's proposed revision seems clearer and reflects the discussion in >San Francisco. Does anybody have any problems with this text, or >should we just go with it? > > - Ted > > > --------------090601000002060605000300-- From owner-ipsec@lists.tislabs.com Mon Apr 14 06:49:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EDn91r056266; Mon, 14 Apr 2003 06:49:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19571 Mon, 14 Apr 2003 09:13:49 -0400 (EDT) Message-ID: <3E9A3B28.2040805@roc.co.in> Date: Mon, 14 Apr 2003 10:08:00 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Peer address update and DPD Content-Type: multipart/alternative; boundary="------------020800010302050907010301" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------020800010302050907010301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi All, I saw in one of the recent emails that, DPD is should be used to check the existence of new updated address by the receiver, before start using this. May somebody give the reasoning for checking the liveness of the address. Since, the notification message comes with new IP address as source IP of the notification message, does this itself indicate that that IP is reachable. Regards, Ravi. -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------020800010302050907010301 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, I saw in one of the recent emails that, DPD is should be used to check the existence of new updated address by the receiver, before start using this. May somebody give the reasoning for checking the liveness of the address. Since, the notification message comes with new IP address as source IP of the notification message, does this itself indicate that that IP is reachable. Regards, Ravi. -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------020800010302050907010301-- From owner-ipsec@lists.tislabs.com Mon Apr 14 06:49:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EDnt1r056293; Mon, 14 Apr 2003 06:49:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19578 Mon, 14 Apr 2003 09:14:45 -0400 (EDT) Message-ID: <3E9A3BE1.90003@roc.co.in> Date: Mon, 14 Apr 2003 10:11:05 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: DPD and Clear notification message Content-Type: multipart/alternative; boundary="------------090800040104010103010004" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------090800040104010103010004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi All, DPD draft allows only encrypted notification messages. It is useful to find out the liveness of current IKE peer. But, it is not possible to find out liveness of peer if the IKE SA does not exist. I have following problem to solve. VPN clients can come to corporate network via two security routers. These security routers connect to the internet via two PPPoE DSL lines. These security routers have different IP addresses. Through DPD it can switch to second router, if primary security router fails. But, there is no way to switch back to primary security router when it is back online. There should be some interoperable way to find out the primary security is back to normal. One way is to create IKE SA periodically with the primary, but this can be expensive from processing power perspective. Second is to have a way to send the DPD notification messages in clear and finding out whether primary router is back or not. With the second approach, there could be concern that it potentially become DDOS attack. This can be mitigated by having some sort of rate limiting the ACKs. Do you see any problem with this? Regards, Ravi -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------090800040104010103010004 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, DPD draft allows only encrypted notification messages. It is useful to find out the liveness of current IKE peer. But, it is not possible to find out liveness of peer if the IKE SA does not exist. I have following problem to solve. VPN clients can come to corporate network via two security routers. These security routers connect to the internet via two PPPoE DSL lines. These security routers have different IP addresses. Through DPD it can switch to second router, if primary security router fails. But, there is no way to switch back to primary security router when it is back online. There should be some interoperable way to find out the primary security is back to normal. One way is to create IKE SA periodically with the primary, but this can be expensive from processing power perspective. Second is to have a way to send the DPD notification messages in clear and finding out whether primary router is back or not. With the second approach, there could be concern that it potentially become DDOS attack. This can be mitigated by having some sort of rate limiting the ACKs. Do you see any problem with this? Regards,Ravi -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------090800040104010103010004-- From owner-ipsec@lists.tislabs.com Mon Apr 14 06:50:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EDoV1r056322; Mon, 14 Apr 2003 06:50:34 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19663 Mon, 14 Apr 2003 09:21:48 -0400 (EDT) Message-ID: <000601c30289$706f3fe0$5a00a8c0@personeta.com> From: "Yaron Sheffer" To: "Lars-Erik Jonsson \(EAB\)" , "IPSec List" , References: Subject: Re: [rohc] FW: ESP and header compression (ROHC) Date: Mon, 14 Apr 2003 16:26:17 +0300 Organization: Personeta MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Lars-Erik, I may have been misunderstood. To clarify, I am discussing the following stack: PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload In some cases, depending on the nature of the flows that use the ESP tunnel, ESP plays the role of a link. In those cases, it makes sense to compress the "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP conversation there will be a single RTP flow within the tunnel, and ROHC is beneficial for the internal headers. In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for IP(2)+UDP+RTP. Regards, Yaron ----- Original Message ----- From: "Lars-Erik Jonsson (EAB)" To: "'Yaron Sheffer'" ; "IPSec List" ; Sent: Monday, April 14, 2003 10:04 Subject: RE: [rohc] FW: ESP and header compression (ROHC) > Hi all, > > A few notes: > 1) ROHC is applied on a per-link basis, e.g. over PPP > 2) Based on the above point, there are ROHC compression profiles > defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) > > Compressing the network layer header is most important to gain > anything, but that can only be done on a per-link basis. Header > compression is thus applied per-link to compress network and > transport layer headers (and by heuristics also the application > layer RTP header). It is also simpler to do compression per-link, > as one can optimize for certain assumed characteristics (such as > in-order delivery). Further, it makes most sense as header > compression is an optimization for "narrow links". > > Therefore, I can not see why/how one could do "ROHC over ESP". > > BR > /Lars-Erik > > > > > > -----Original Message----- > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > Sent: den 13 april 2003 21:26 > > To: IPSec List; rohc@ietf.org > > Subject: [rohc] FW: ESP and header compression (ROHC) > > > > > > (please reply to both lists) > > > > Below is my question to Steve Kent (author of the new rev of ESP, and > > co-author of the original RFC) and his reply. I understand > > that IPCOMP is > > inferior to ROHC for RTP streams, and I'd like to hear other opinions > > regarding the usefulness of an "ROHC" indicator in ESP. > > > > This might certaily add complexity to IPSec, but if you make it > > non-negotiable and non-mandatory, it cannot be too terrible. > > > > Thanks, > > Yaron > > > > -----Original Message----- > > From: Stephen Kent [mailto:kent@bbn.com] > > Sent: Thursday, April 10, 2003 12:06 AM > > To: Yaron Sheffer > > Cc: Sara Bitan; kent@bbn.com > > Subject: Re: ESP and header compression (ROHC) > > > > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > > >Hi Steve, > > > > > >I have lately looked at issues with IPSec encryption of RTP > > streams (I am > > >aware of SRTP but I think we will want RTP over IPSec for > > some time to > > >come). A major issue is packet overhead. You can use Robust Header > > >Compression (ROHC) on the external IP+ESP headers - this is > > defined by the > > >ROHC RFC. But if you want to header-compress the RTP packets > > before it is > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > > because there's no > > >way to detect ROHC packets in the ESP header. I'd expect ESP > > to contain a > > >marker for ROHC packets, similarly to PPP. Has this option > > been considered > > >for the new version of ESP? > > > > > >Thanks, > > > Yaron > > > > No, the WG has not considered that option. The WG has been striving > > to make IPsec simpler and thus adding support for ROHC is contrary to > > that theme. For example, ROHC would have be be implemented within > > IPsec, after the SA lookup was performed, and ROHC decompression > > would have to be implemented in IPsec at the receiver, since the > > receiver has to check the headers against the SAD. IPsec already > > supports IPCOMP as a compression method for whole packets, not just > > headers, and thus it might be hard to persuade the WG to add ROHC > > support too. > > > > But, that's just my impression. You can always raise the > > question on the > > list. > > > > Steve > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > From owner-ipsec@lists.tislabs.com Mon Apr 14 07:23:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EENK1r058123; Mon, 14 Apr 2003 07:23:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19958 Mon, 14 Apr 2003 09:56:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200304102148.h3ALmtPk029105@burp.tkv.asdf.org> References: <200304102148.h3ALmtPk029105@burp.tkv.asdf.org> Date: Mon, 14 Apr 2003 09:56:05 -0400 To: Markku Savela From: Stephen Kent Subject: Re: Question on SA Bundle Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:48 AM +0300 4/11/03, Markku Savela wrote: > > From: Stephen Kent > >> In general I agree, but if we do that, and if we want to be able to >> support bundles, then we need to add complexity to IKE to be able to >> specify how multiple SAs relate to one another. In the general case, >> that seems to be messy, which is why I believe we probably ought not >> try to support this going forward, consistent with our overall >> attempt to simplify IPsec. > >It would be GREAT simplification of IPSEC if the key management >negotiated only individual unidirectional SA's by default. No policy >checking for Phase2 SA's. I've repeated this for 4 years now, and been >ignored. Let this be my one yearly reminder of the fact :-) Yes, you are consistent in your views :-) However, we've had this discussion before and I believe the consensus is that IPsec is a security protocol, not just a crypto protocol. Access control really underlies why many folks will use IPsec, and thus access control is an essential feature of the protocol. > > Flexibility is good, except to the extent that it introduces >> complexity. I don't think flexibility is good if it serves primarily >> to allow non-interoperable implementations to claim conformance with >> a "flexible" standard. We have to be careful in that regard. > >Flexibily can be achieved without complexity. Consider analogy of high >level language and machine code. In my view IPSEC base RFC's should >describe the easy to implement "machine code", consisting of primitive >operations, that are clear and easy to implement. Everything is >already almost there (RFC 2401, PFKEY, ESP/AH). I always liked the >idea of unidirectional SA being a good choice for a primitive >unit. I agree that what you suggest would be simpler, but very few applications deal with only unidirectional traffic. Thus the offered, simpler service you suggest would not match well what applications really do. In that case, the loss of functionality that would accompany the increased simplicity is a poor tradeoff, IMHO, since we would have to do do additional work establishing pairs of unidirectional SAs via separate negotiations, which hardly seems worth the extra effort. I think the bottom line is that we have an ability to create paired AH/ESP SAs now, and we can retain that going forward, even though this will not be the common case, i.e., usually just ESP will be used. If folks really want to add in the ability to do nesting of SAs by creating bundles, then we need to add it now to IKE v2, or I'll plan to drop it from 2401bis. Steve Steve From owner-ipsec@lists.tislabs.com Mon Apr 14 07:23:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EENt1r058138; Mon, 14 Apr 2003 07:23:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19888 Mon, 14 Apr 2003 09:50:46 -0400 (EDT) Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'Yaron Sheffer'" , IPSec List , rohc@ietf.org Subject: RE: [rohc] FW: ESP and header compression (ROHC) Date: Mon, 14 Apr 2003 15:46:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yaron, That clarified the scenario, just note that "ROHC over tunnels" has not yet been addressed in the ROHC WG. I do not say that that there must be problems with that, but it should be noted that the link assumptions made for ROHC might not match a tunneling case. Anyway, I am not sure you need anything special in the ESP header, but can do per-link compression of the whole chain. You would have an outer and an inner IP header, and the ESP header would be part of a compressed chain (RFC 3095 section 5.8, 5.8.4.3). However, if the inner headers are encrypted, you can of course not compress all headers on a per-link basis. Is that the case you are considering? Cheers, /L-E > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf@gmx.net] > Sent: den 14 april 2003 15:26 > To: Lars-Erik Jonsson (EAB); IPSec List; rohc@ietf.org > Subject: Re: [rohc] FW: ESP and header compression (ROHC) > > > Hi Lars-Erik, > > I may have been misunderstood. To clarify, I am discussing > the following > stack: > > PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload > > In some cases, depending on the nature of the flows that use > the ESP tunnel, > ESP plays the role of a link. In those cases, it makes sense > to compress the > "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP > conversation there will be a single RTP flow within the > tunnel, and ROHC is > beneficial for the internal headers. > > In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for > IP(2)+UDP+RTP. > > Regards, > Yaron > > ----- Original Message ----- > From: "Lars-Erik Jonsson (EAB)" > To: "'Yaron Sheffer'" ; "IPSec List" > ; > Sent: Monday, April 14, 2003 10:04 > Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > > > Hi all, > > > > A few notes: > > 1) ROHC is applied on a per-link basis, e.g. over PPP > > 2) Based on the above point, there are ROHC compression profiles > > defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) > > > > Compressing the network layer header is most important to gain > > anything, but that can only be done on a per-link basis. Header > > compression is thus applied per-link to compress network and > > transport layer headers (and by heuristics also the application > > layer RTP header). It is also simpler to do compression per-link, > > as one can optimize for certain assumed characteristics (such as > > in-order delivery). Further, it makes most sense as header > > compression is an optimization for "narrow links". > > > > Therefore, I can not see why/how one could do "ROHC over ESP". > > > > BR > > /Lars-Erik > > > > > > > > > > > -----Original Message----- > > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > > Sent: den 13 april 2003 21:26 > > > To: IPSec List; rohc@ietf.org > > > Subject: [rohc] FW: ESP and header compression (ROHC) > > > > > > > > > (please reply to both lists) > > > > > > Below is my question to Steve Kent (author of the new rev > of ESP, and > > > co-author of the original RFC) and his reply. I understand > > > that IPCOMP is > > > inferior to ROHC for RTP streams, and I'd like to hear > other opinions > > > regarding the usefulness of an "ROHC" indicator in ESP. > > > > > > This might certaily add complexity to IPSec, but if you make it > > > non-negotiable and non-mandatory, it cannot be too terrible. > > > > > > Thanks, > > > Yaron > > > > > > -----Original Message----- > > > From: Stephen Kent [mailto:kent@bbn.com] > > > Sent: Thursday, April 10, 2003 12:06 AM > > > To: Yaron Sheffer > > > Cc: Sara Bitan; kent@bbn.com > > > Subject: Re: ESP and header compression (ROHC) > > > > > > > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > > > >Hi Steve, > > > > > > > >I have lately looked at issues with IPSec encryption of RTP > > > streams (I am > > > >aware of SRTP but I think we will want RTP over IPSec for > > > some time to > > > >come). A major issue is packet overhead. You can use > Robust Header > > > >Compression (ROHC) on the external IP+ESP headers - this is > > > defined by the > > > >ROHC RFC. But if you want to header-compress the RTP packets > > > before it is > > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > > > because there's no > > > >way to detect ROHC packets in the ESP header. I'd expect ESP > > > to contain a > > > >marker for ROHC packets, similarly to PPP. Has this option > > > been considered > > > >for the new version of ESP? > > > > > > > >Thanks, > > > > Yaron > > > > > > No, the WG has not considered that option. The WG has > been striving > > > to make IPsec simpler and thus adding support for ROHC is > contrary to > > > that theme. For example, ROHC would have be be implemented within > > > IPsec, after the SA lookup was performed, and ROHC decompression > > > would have to be implemented in IPsec at the receiver, since the > > > receiver has to check the headers against the SAD. IPsec already > > > supports IPCOMP as a compression method for whole > packets, not just > > > headers, and thus it might be hard to persuade the WG to add ROHC > > > support too. > > > > > > But, that's just my impression. You can always raise the > > > question on the > > > list. > > > > > > Steve > > > > > > _______________________________________________ > > > Rohc mailing list > > > Rohc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > From owner-ipsec@lists.tislabs.com Mon Apr 14 08:14:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EFEe1r063697; Mon, 14 Apr 2003 08:14:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20315 Mon, 14 Apr 2003 10:39:23 -0400 (EDT) Message-ID: <000801c30294$377c1540$5a00a8c0@personeta.com> From: "Yaron Sheffer" To: "Lars-Erik Jonsson \(EAB\)" , "IPSec List" , References: Subject: Re: [rohc] FW: ESP and header compression (ROHC) Date: Mon, 14 Apr 2003 17:43:23 +0300 Organization: Personeta MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Lars-Erik, You are right, I was considering the encrypted case. ESP is only interesting if the inner headers (and the payload, of course) are encrypted. Which is why you need to compress the inner part before encryption, and the outer part after. You'd need a special marker in the ESP header to denote a compressed packet, just as you do in PPP. The existing ESP (RFC 2406) has a Next Header field, which contains a "protocol number" (see http://www.iana.org/assignments/protocol-numbers). For ESP in "tunnel mode" this field holds the value for IP. AFAIK, there is no value for ROHC. Best regards, Yaron ----- Original Message ----- From: "Lars-Erik Jonsson (EAB)" To: "'Yaron Sheffer'" ; "IPSec List" ; Sent: Monday, April 14, 2003 16:46 Subject: RE: [rohc] FW: ESP and header compression (ROHC) > Yaron, > > That clarified the scenario, just note that "ROHC over tunnels" > has not yet been addressed in the ROHC WG. I do not say that > that there must be problems with that, but it should be noted > that the link assumptions made for ROHC might not match a > tunneling case. > > Anyway, I am not sure you need anything special in the ESP > header, but can do per-link compression of the whole chain. You > would have an outer and an inner IP header, and the ESP header > would be part of a compressed chain (RFC 3095 section 5.8, 5.8.4.3). > > However, if the inner headers are encrypted, you can of course > not compress all headers on a per-link basis. Is that the case > you are considering? > > Cheers, > /L-E > > > > -----Original Message----- > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > Sent: den 14 april 2003 15:26 > > To: Lars-Erik Jonsson (EAB); IPSec List; rohc@ietf.org > > Subject: Re: [rohc] FW: ESP and header compression (ROHC) > > > > > > Hi Lars-Erik, > > > > I may have been misunderstood. To clarify, I am discussing > > the following > > stack: > > > > PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload > > > > In some cases, depending on the nature of the flows that use > > the ESP tunnel, > > ESP plays the role of a link. In those cases, it makes sense > > to compress the > > "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP > > conversation there will be a single RTP flow within the > > tunnel, and ROHC is > > beneficial for the internal headers. > > > > In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for > > IP(2)+UDP+RTP. > > > > Regards, > > Yaron > > > > ----- Original Message ----- > > From: "Lars-Erik Jonsson (EAB)" > > To: "'Yaron Sheffer'" ; "IPSec List" > > ; > > Sent: Monday, April 14, 2003 10:04 > > Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > > > > > > Hi all, > > > > > > A few notes: > > > 1) ROHC is applied on a per-link basis, e.g. over PPP > > > 2) Based on the above point, there are ROHC compression profiles > > > defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) > > > > > > Compressing the network layer header is most important to gain > > > anything, but that can only be done on a per-link basis. Header > > > compression is thus applied per-link to compress network and > > > transport layer headers (and by heuristics also the application > > > layer RTP header). It is also simpler to do compression per-link, > > > as one can optimize for certain assumed characteristics (such as > > > in-order delivery). Further, it makes most sense as header > > > compression is an optimization for "narrow links". > > > > > > Therefore, I can not see why/how one could do "ROHC over ESP". > > > > > > BR > > > /Lars-Erik > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > > > Sent: den 13 april 2003 21:26 > > > > To: IPSec List; rohc@ietf.org > > > > Subject: [rohc] FW: ESP and header compression (ROHC) > > > > > > > > > > > > (please reply to both lists) > > > > > > > > Below is my question to Steve Kent (author of the new rev > > of ESP, and > > > > co-author of the original RFC) and his reply. I understand > > > > that IPCOMP is > > > > inferior to ROHC for RTP streams, and I'd like to hear > > other opinions > > > > regarding the usefulness of an "ROHC" indicator in ESP. > > > > > > > > This might certaily add complexity to IPSec, but if you make it > > > > non-negotiable and non-mandatory, it cannot be too terrible. > > > > > > > > Thanks, > > > > Yaron > > > > > > > > -----Original Message----- > > > > From: Stephen Kent [mailto:kent@bbn.com] > > > > Sent: Thursday, April 10, 2003 12:06 AM > > > > To: Yaron Sheffer > > > > Cc: Sara Bitan; kent@bbn.com > > > > Subject: Re: ESP and header compression (ROHC) > > > > > > > > > > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > > > > >Hi Steve, > > > > > > > > > >I have lately looked at issues with IPSec encryption of RTP > > > > streams (I am > > > > >aware of SRTP but I think we will want RTP over IPSec for > > > > some time to > > > > >come). A major issue is packet overhead. You can use > > Robust Header > > > > >Compression (ROHC) on the external IP+ESP headers - this is > > > > defined by the > > > > >ROHC RFC. But if you want to header-compress the RTP packets > > > > before it is > > > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > > > > because there's no > > > > >way to detect ROHC packets in the ESP header. I'd expect ESP > > > > to contain a > > > > >marker for ROHC packets, similarly to PPP. Has this option > > > > been considered > > > > >for the new version of ESP? > > > > > > > > > >Thanks, > > > > > Yaron > > > > > > > > No, the WG has not considered that option. The WG has > > been striving > > > > to make IPsec simpler and thus adding support for ROHC is > > contrary to > > > > that theme. For example, ROHC would have be be implemented within > > > > IPsec, after the SA lookup was performed, and ROHC decompression > > > > would have to be implemented in IPsec at the receiver, since the > > > > receiver has to check the headers against the SAD. IPsec already > > > > supports IPCOMP as a compression method for whole > > packets, not just > > > > headers, and thus it might be hard to persuade the WG to add ROHC > > > > support too. > > > > > > > > But, that's just my impression. You can always raise the > > > > question on the > > > > list. > > > > > > > > Steve > > > > > > > > _______________________________________________ > > > > Rohc mailing list > > > > Rohc@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > > > > > From owner-ipsec@lists.tislabs.com Mon Apr 14 08:15:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EFFd1r063725; Mon, 14 Apr 2003 08:15:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20347 Mon, 14 Apr 2003 10:46:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 14 Apr 2003 10:49:01 -0400 To: "Yaron Sheffer" From: Stephen Kent Subject: Re: FW: ESP and header compression (ROHC) Cc: "IPSec List" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:26 PM +0200 4/13/03, Yaron Sheffer wrote: >(please reply to both lists) > >Below is my question to Steve Kent (author of the new rev of ESP, and >co-author of the original RFC) and his reply. I understand that IPCOMP is >inferior to ROHC for RTP streams, and I'd like to hear other opinions >regarding the usefulness of an "ROHC" indicator in ESP. > >This might certaily add complexity to IPSec, but if you make it >non-negotiable and non-mandatory, it cannot be too terrible. > >Thanks, > Yaron Yaron, If the ability to do this was "non-negotiable and non-mandatory" how would two IPsec peers know when to do this? Steve From owner-ipsec@lists.tislabs.com Mon Apr 14 08:49:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EFnTbP065678; Mon, 14 Apr 2003 08:49:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20624 Mon, 14 Apr 2003 11:15:41 -0400 (EDT) Message-ID: From: "Zimmerman, Mark" To: ipsec@lists.tislabs.com Subject: Interoperability - Overlapping requests Date: Mon, 14 Apr 2003 11:14:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30298.963DE870" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C30298.963DE870 Content-Type: text/plain Greetings, A question regarding Section 2.3 of ikev2-06. Perhaps I am not understanding the verbage correctly, but I could foresee differing interpretations being made by different developers. The first paragraph states: In order to maximize IKE throughput, an IKE endpoint MAY issue multiple requests before getting a response to any of them. For simplicity, an IKE implementation MAY choose to process requests strictly in order and/or wait for a response to one request before issuing another. Certain rules must be followed to assure interoperability between implementations using different strategies. While Paragraph 3 states: An IKE endpoint MUST wait for a response to each of its messages before sending a subsequent message unless it has received a Notify message from its peer informing it that the peer is prepared to maintain state for multiple outstanding messages in order to allow greater throughput. Should paragraph 1 also contain a statement regarding an outstanding message state? Also, can I assume that the outstanding messages can fall outside of the replay protection window? Any clarification is appreciated, Regards, Mark Zimmerman Program Manager ICSA Labs 1000 Bent Creek Blvd, Suite 200 Mechanicsburg PA 17050 Phone: 717.790.8144 Fax: 717.790.8170 mzimmerman@icsalabs.com www.icsalabs.com *********************************************************************** This message is intended only for the use of the intended recipient and may contain information that is PRIVILEGED and/or CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy all copies of this message and its attachments and notify us immediately. *********************************************************************** ------_=_NextPart_001_01C30298.963DE870 Content-Type: text/html Content-Transfer-Encoding: quoted-printable xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" = xmlns=3D"http://www.w3.org/TR/REC-html40"> Greetings, A question regarding Section 2.3 of ikev2-06. = Perhaps I am not understanding the verbage = correctly, but I could foresee differing interpretations being made by different = developers. The first paragraph = states: In order to maximize IKE throughput, an IKE = endpoint MAY issue multiple requests before = getting a response to any of them. = For simplicity, an IKE = implementation MAY choose to process = requests strictly in order and/or = wait for a response to one request = before issuing another. Certain = rules must be followed to = assure interoperability between = implementations using different = strategies. While Paragraph 3 = states: An IKE endpoint MUST wait for a response to = each of its messages before sending a = subsequent message unless it has received a = Notify message from its peer = informing it that the peer is prepared = to maintain state for = multiple outstanding messages in order to = allow greater = throughput. Should = paragraph 1 also contain a statement regarding an outstanding = message state? = Also, can I assume that the outstanding messages can fall outside of = the replay = protection window? Any = clarification is appreciated, Regards, Mark = Zimmerman Program Manager ICSA Labs 1000 Bent Creek Blvd, Suite = 200 Mechanicsburg PA 17050 Phone: 717.790.8144 Fax: 717.790.8170 <3d.htm>mzimmerman@icsalabs.com www.icsalabs.com ------_=_NextPart_001_01C30298.963DE870-- From owner-ipsec@lists.tislabs.com Mon Apr 14 10:09:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EH9hbP068233; Mon, 14 Apr 2003 10:09:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21046 Mon, 14 Apr 2003 12:34:38 -0400 (EDT) Message-ID: <3E9AE3C9.C7026779@airespace.com> Date: Mon, 14 Apr 2003 09:37:29 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Apr 2003 16:38:21.0314 (UTC) FILETIME=[42AEA620:01C302A4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think Darren's summary is pretty accurate. It's kind of a toss up. However, one difference that I note is that with the dhcp approach, all client config is (potentially) done prior to the instantiation of the child sa. I'm not sure if this is a benefit or not, but it might be. Scott From owner-ipsec@lists.tislabs.com Mon Apr 14 10:25:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EHPXbP068653; Mon, 14 Apr 2003 10:25:34 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21160 Mon, 14 Apr 2003 12:52:54 -0400 (EDT) Message-Id: <200304141657.h3EGvHof069873@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Ravi cc: ipsec@lists.tislabs.com Subject: Re: Peer address update and DPD In-reply-to: Your message of Mon, 14 Apr 2003 10:08:00 +0530. <3E9A3B28.2040805@roc.co.in> Date: Mon, 14 Apr 2003 18:57:17 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I saw in one of the recent emails that, DPD is should be used to check the existence of new updated address by the receiver, before start using this. May somebody give the reasoning for checking the liveness of the address. => easy: this is a return routability check: a request is sent to the peer at its new address and when the response comes back one knows the peer is able to receive messages sent to this address. This is not high security but you catch attackers using random fake addresses (note: attackers knowing the keys negociated in phase one, i.e., this is more an issue about the trust one puts on its peer than other thing. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Apr 14 10:48:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EHmJbP069192; Mon, 14 Apr 2003 10:48:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21263 Mon, 14 Apr 2003 13:13:33 -0400 (EDT) Message-ID: From: "Zimmerman, Mark" To: ipsec@lists.tislabs.com Subject: Interoperability - Overlapping requests Date: Mon, 14 Apr 2003 13:17:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings, A question regarding Section 2.3 of ikev2-06. Perhaps I am not understanding the verbage correctly, but I could foresee differing interpretations being made by different developers. The first paragraph states: In order to maximize IKE throughput, an IKE endpoint MAY issue multiple requests before getting a response to any of them. For simplicity, an IKE implementation MAY choose to process requests strictly in order and/or wait for a response to one request before issuing another. Certain rules must be followed to assure interoperability between implementations using different strategies. While Paragraph 3 states: An IKE endpoint MUST wait for a response to each of its messages before sending a subsequent message unless it has received a Notify message from its peer informing it that the peer is prepared to maintain state for multiple outstanding messages in order to allow greater throughput. Should paragraph 1 also contain a statement regarding an outstanding message state? Also, can I assume that the outstanding messages can fall outside of the replay protection window? Any clarification is appreciated, Regards, Mark Zimmerman Program Manager ICSA Labs *********************************************************************** This message is intended only for the use of the intended recipient and may contain information that is PRIVILEGED and/or CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy all copies of this message and its attachments and notify us immediately. *********************************************************************** From owner-ipsec@lists.tislabs.com Mon Apr 14 10:53:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EHrAbP069298; Mon, 14 Apr 2003 10:53:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21295 Mon, 14 Apr 2003 13:17:43 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload To: "Theodore Ts'o" Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Sun, 13 Apr 2003 22:19:08 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04072003NP|April 07, 2003) at 04/14/2003 01:21:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Having read Tero's DHCP over IKE proposal, I continue to believe that while either DHCP or CP could be made to work that CP is the better choice for reasons of simplicity. (If I were king, I'd pick a protocol that was simpler than either). While it's attractive to reference DHCP rather than define a subset of it in order to shorten the spec, Tero's drafts make it clear that using DHCP won't shorten the spec because of the integration issues that would need to be added. DHCP was designed to run over an unreliable datagram protocol with broadcast capabilities for server discovery. IKE is a reliable request/response protocol to a single peer. So running DHCP over IKE requires that we specify how DHCP timeouts get handled and how to deal with the case where the responder has a packet but it's not his turn to talk. Tero's proposal describes how to deal with all these cases, but it's awkward. The strongest case for DHCP is when optimizing for the configuration where the IKE responder doesn't itself allocate IP addresses to the IKE initiator but rather acts as a DHCP relay to some DHCP server it accesses over a network. Then there would be pretty much a one-to-one mapping between the messages on the wire and the DHCP payloads in the IKE messages. But the IKE endpoint would still be doing more processing than a DHCP relay since it would have to parse the DHCP messages as it passed them through to learn what address was assigned in order to put that address in the traffic selectors. When the IKE responder is allocating addresses out of its own pool or getting them using RADIUS, it appears to me that processing would be more complex translating them to DHCP than translating them to CP. My intuition is that having the IKE responder lease addresses from its own pool will be the common case, since if the address is acquired from elsewhere the IKE responder will have to take some action to get traffic to the allocated address routed to it (most likely by responding to ARPs). So I continue to "not get it" in trying to understand the advantages of DHCP. Do we envision using the advanced capabilities of DHCP to do things like booting over the IPsec connection? If so, encapsulating all the messages in IKE seems even more cumbersome. I would think the boot rom would want to set up the IPsec connection, get an IP address, and then run DHCP over ESP. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Mon Apr 14 11:24:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EIOQbP070275; Mon, 14 Apr 2003 11:24:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21432 Mon, 14 Apr 2003 13:53:25 -0400 (EDT) Date: Mon, 14 Apr 2003 13:56:38 -0400 From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: Re: IKE V2 Open Issues Message-ID: <20030414175638.GA5919@think> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There have been distressingly few comments on the final open issues. It has been suggested that perhaps for those folks in the U.S., they have been too absorbed in trying to reduce the amount of involuntary support they have to give to the U.S. Government. :-) We have default editing instructions that we can give to Charlie in the absence of working group feedback, which were listed in the e-mails we sent last week. If necessary, we will issue those instructions to Charlie and then initiate wg last call. While people are of course free to wait until then to submit their comments, the earlier we can get comments from wg members, the better. So we ask that people try to look through ikev2-06, read through the discussion of the last few remaining issues, and make comments as soon as possible, preferably in the next few days. Even if we can't get the to wg last call by tomorrow, we'd prefer to only slip the schedule by a few days. Many thanks, - Ted From owner-ipsec@lists.tislabs.com Mon Apr 14 11:51:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EIpgbP072292; Mon, 14 Apr 2003 11:51:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21548 Mon, 14 Apr 2003 14:26:14 -0400 (EDT) Date: Mon, 14 Apr 2003 14:30:19 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: IKE V2 Open Issues In-Reply-To: <20030414175638.GA5919@think> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 14 Apr 2003, Theodore Ts'o wrote: > There have been distressingly few comments on the final open issues. > It has been suggested that perhaps for those folks in the U.S., they > have been too absorbed in trying to reduce the amount of involuntary > support they have to give to the U.S. Government. :-) Yes, the choice of schedule clearly violates Natalie's Law. :-) (The original Natalie's Law -- enunciated by Ron Natalie during the planning for the Great Renaming of Usenet in 1986 -- is "Never schedule major software changes on or near major holidays!", with the added comment that things like Usenix conferences, the World Science Fiction Convention, and April 15th qualify as holidays for this purpose.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Apr 14 12:12:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EJCDbP072703; Mon, 14 Apr 2003 12:12:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21659 Mon, 14 Apr 2003 14:44:57 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16027.670.754689.254671@thomasm-u1.cisco.com> Date: Mon, 14 Apr 2003 11:49:02 -0700 (PDT) To: "Scott G. Kelly" Cc: ipsec@lists.tislabs.com Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload In-Reply-To: <3E9AE3C9.C7026779@airespace.com> References: <3E9AE3C9.C7026779@airespace.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not entirely sure how impolitic this is wrt my employer's hive mind, but the thing that really tips my feeling about this is that DHCP-in-IKE keeps the IPsec wg out of the business of dealing with... configuration. That seems like a huge boon in my mind from a wheel-reinvention standpoint. So, mark my preference as DHCP-in-IKE. Mike Scott G. Kelly writes: > I think Darren's summary is pretty accurate. It's kind of a toss up. > However, one difference that I note is that with the dhcp approach, all > client config is (potentially) done prior to the instantiation of the > child sa. I'm not sure if this is a benefit or not, but it might be. > > Scott From owner-ipsec@lists.tislabs.com Mon Apr 14 12:40:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EJenbP073903; Mon, 14 Apr 2003 12:40:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21811 Mon, 14 Apr 2003 15:09:45 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16027.2108.76439.979793@thomasm-u1.cisco.com> Date: Mon, 14 Apr 2003 12:13:00 -0700 (PDT) To: Charlie_Kaufman@notesdev.ibm.com Cc: "Theodore Ts'o" , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie_Kaufman@notesdev.ibm.com writes: > While it's attractive to reference DHCP rather than define a subset of it > in order to shorten the spec, Tero's drafts make it clear that using DHCP > won't shorten the spec because of the integration issues that would need to > be added. DHCP was designed to run over an unreliable datagram protocol > with broadcast capabilities for server discovery. IKE is a reliable > request/response protocol to a single peer. So running DHCP over IKE > requires that we specify how DHCP timeouts get handled and how to deal with > the case where the responder has a packet but it's not his turn to talk. > Tero's proposal describes how to deal with all these cases, but it's > awkward. Charlie, Neither of these seems like a big deal to me. In fact, knowing the destination of the relay *constrains* the problem space, not the other way around. Also: many protocols which have both a reliable and unreliable transport face these same questions (DNS, SIP...), so the how-to doesn't seem too hard to overcome. > So I continue to "not get it" in trying to understand the advantages of > DHCP. Do we envision using the advanced capabilities of DHCP to do things > like booting over the IPsec connection? If so, encapsulating all the > messages in IKE seems even more cumbersome. I would think the boot rom > would want to set up the IPsec connection, get an IP address, and then run > DHCP over ESP. Well, there's that too, but I get the impression that config-over-IKE is pretty well ingrained so trying to excise that mindset at this point is pretty hopeless. Thus to my mind, lesser of evils is to beg, borrow and steal and punt as much work as possible to other wg's that actually care about this sort of thing... Mike From owner-ipsec@lists.tislabs.com Mon Apr 14 13:02:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EK2ibP076889; Mon, 14 Apr 2003 13:02:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21888 Mon, 14 Apr 2003 15:33:12 -0400 (EDT) Date: Mon, 14 Apr 2003 22:36:50 +0300 Message-Id: <200304141936.h3EJaoI3008229@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com CC: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Wed, 9 Apr 2003 18:34:03 -0400) Subject: Re: Question on SA Bundle References: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Back to bundle issue, why I want "bundle" to be a rather loose concept: - bundle is just a collection of SA's that are required You ignored my example from MIPv6. As I earlier presented 1) MN is at home, talks to CN. CN could be web server or mailbox that requires some IPSEC for access. We have policy remote CN -> CN-SA() 2) MN moves away from home. Suddenly MN needs IPSEC with HA agent remote HA -> HA-SA() 3) MN still wants to communicate with CN. MIPv6 calls for tunneling the traffic via HA. From IPSEC viewpoint HA is like a SG, and the whole internet is the protected network. Now, the packets at MN need to look like Outgoing: Incoming: --------- --------- IP: dst=HA dst=COA src=COA src=HA IPSEC with HA-SA IPSEC with HA-SA IP: dst=CN dst=HOME src=HOME src=CN IPSEC with CN-SA IPSEC with CN-SA Payload Payload SOMEHOW, above MUST be achieved. Surely there are many ways. BUT, in MY IPSEC policy I could express the requirement and rule to achieve above as (roughly, not going here into detail of how I separate "at home" and "at away", trust me I can do it :-) remote CN -> CN-SA(), HA-SA(tunnel to HA) I don't want this solution to become "non-conformant". It works for me! Now, this looks like a "bundle": a selector and two SA's, and this is how it's handled in IPSEC packet processing. Packets matching "remote CN" must have both CN-SA and HA-SA(tunnel) successfully applied for incoming and outgoing. However, as far as key management (IKEv1 or IKEv2) are concerned, this is really two different Phase1 associations, one negotiated between HOME and CN, and other negotiated between HOME and HA. ------------ Above is prime example why I don't like IKE (or any key management) to mess/check policy in phase2. Policy is just too complex for them to handle. I want to be able to work on policy definitions and echancements independently of key negotiation implementation. Similar example can occur even without mobile IP, say | A -|--- SG ====== B where A has some highly classified data. You don't want to pass it clear, even within internal net. Thus any communication with A needs IPSEC. Now, if B wants to access A outside, it needs IPSEC with SG and A simultaneously! From owner-ipsec@lists.tislabs.com Mon Apr 14 13:31:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EKVdbP078105; Mon, 14 Apr 2003 13:31:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22003 Mon, 14 Apr 2003 15:59:39 -0400 (EDT) Message-Id: <200304142002.h3EK2xwm000983@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Thomas cc: Charlie_Kaufman@notesdev.ibm.com, "Theodore Ts'o" , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload In-Reply-To: Your message of "Mon, 14 Apr 2003 12:13:00 PDT." <16027.2108.76439.979793@thomasm-u1.cisco.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 14 Apr 2003 16:02:59 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Well, there's that too, but I get the impression > that config-over-IKE is pretty well ingrained so > trying to excise that mindset at this point is > pretty hopeless. Thus to my mind, lesser of evils > is to beg, borrow and steal and punt as much work > as possible to other wg's that actually care about > this sort of thing... Indeed. My sense is that configuration is not an area of expertise for the members of this WG, and incorporating DHCP as-is is a better solution than trying to reinvent a wheel here. - Bill From owner-ipsec@lists.tislabs.com Mon Apr 14 14:01:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EL19bP078796; Mon, 14 Apr 2003 14:01:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22089 Mon, 14 Apr 2003 16:30:13 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16027.7008.163700.835267@ryijy.hel.fi.ssh.com> Date: Mon, 14 Apr 2003 23:34:40 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: tytso@mit.edu Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload References: X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 2 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk tytso@mit.edu ("Theodore Ts'o") writes: > Last week on Thursday, Tero Kevinen has submitted three drafts (*) that ^ > define DHCP over IKE. Comments to these documents are solicted, and > thoughts about whether this approach is superior or inferior to the > currently specified Configuration payload in ikev2-06 are hereby > solicited. As you can guess, I prefer the DHCP over IKE :-) > (*) Tero, go ahead and submit them as IPSEC wg I-D's --- Barbara and I > will approve them as working group documents. I sent them out few minutes ago. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Apr 14 14:23:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ELNrbP079449; Mon, 14 Apr 2003 14:23:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22193 Mon, 14 Apr 2003 16:44:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200304141936.h3EJaoI3008229@burp.tkv.asdf.org> References: <200304141936.h3EJaoI3008229@burp.tkv.asdf.org> Date: Mon, 14 Apr 2003 16:42:03 -0400 To: Markku Savela From: Stephen Kent Subject: Re: Question on SA Bundle Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:36 PM +0300 4/14/03, Markku Savela wrote: >Back to bundle issue, why I want "bundle" to be a rather loose concept: > > - bundle is just a collection of SA's that are required > >You ignored my example from MIPv6. As I earlier presented I ignored your example because there is a separate document from the MIPv6 WG that talks about how to support those requirements. I am working with the authors to try to understand what it requires and how it relates to 2401. I find it confusing enough to focus on that for now :-) > >1) MN is at home, talks to CN. CN could be web server or mailbox that > requires some IPSEC for access. We have policy > > remote CN -> CN-SA() > >2) MN moves away from home. Suddenly MN needs IPSEC with HA agent > > remote HA -> HA-SA() > >3) MN still wants to communicate with CN. MIPv6 calls for tunneling > the traffic via HA. From IPSEC viewpoint HA is like a SG, and the > whole internet is the protected network. > > Now, the packets at MN need to look like > > Outgoing: Incoming: > --------- --------- > IP: dst=HA dst=COA > src=COA src=HA > IPSEC with HA-SA IPSEC with HA-SA > IP: dst=CN dst=HOME > src=HOME src=CN > IPSEC with CN-SA IPSEC with CN-SA > Payload Payload > >SOMEHOW, above MUST be achieved. Surely there are many ways. BUT, in >MY IPSEC policy I could express the requirement and rule to achieve >above as (roughly, not going here into detail of how I separate "at >home" and "at away", trust me I can do it :-) MUST is a very strong term :-) It may be very desirable, but whether it must be supported is yet to be decided. As we have discussed in our off-list message exchanges, your ideas about policy expression may go beyond 2401. As part of revising 2401 it is possible that the SPD policy expression may be expanded to accommodate more complex policies, BUT the WG will have to decide if the added complexity is something we want to impose on all IPsec implementations. Also, you and I disagree over whether it is necessary for IPsec peers to notify one another of the policy that will be applied to packets as part of the IKE negotiation. I believe that, in general, IKE v2 has moved in the direction of providing this info, even more so than IKE v1. For example, in v2 the initiator sends SPD selector data showing the range of values associated with an SA that is being created, to enable the peer to know the range of traffic that can be carried on the SA. Your proposals seem to head in the other direction, i.e., not wanting peers to exchange this data in IKE. > > remote CN -> CN-SA(), HA-SA(tunnel to HA) > >I don't want this solution to become "non-conformant". It works for >me! I don't understand the example well enough to comment, but I will say that just because someone has implemented some features does not mean that the features are conformant today. >Now, this looks like a "bundle": a selector and two SA's, and this is >how it's handled in IPSEC packet processing. Packets matching "remote >CN" must have both CN-SA and HA-SA(tunnel) successfully applied for >incoming and outgoing. > >However, as far as key management (IKEv1 or IKEv2) are concerned, this >is really two different Phase1 associations, one negotiated between >HOME and CN, and other negotiated between HOME and HA. Again, we seem to have a mismatch between a desire to decouple SA parameters in each peer from what IKE negotiates. In general, I think the WG has adopted the position that this is not a good idea. Rather, it seems desirable to have each peer understand the other's view of the SA, to avoid confusion. >------------ > >Above is prime example why I don't like IKE (or any key management) to >mess/check policy in phase2. Policy is just too complex for them to >handle. I want to be able to work on policy definitions and >echancements independently of key negotiation implementation. If one looks at what IKE does (both v1 and v2) it is clear that most of the complexity resides in the SA management aspects of the task, not in the key management aspects. So, what I think you are saying is that you would like to have a protocol that focuses mostly on key management, and a separate protocol that addresses other aspects of SA management, including policy aspects. This sounds like what JFK was doing, but the WG elected to not pursue that path. I think in part this is because the WG realized that policy support is critical and if we don't deal with it now, we will have implementations that create SAs but fail because of a lack of a standard way to express policy over what traffic is supposed to flow over the SAs. >Similar example can occur even without mobile IP, say > > | > A -|--- SG ====== B > >where A has some highly classified data. You don't want to pass it >clear, even within internal net. Thus any communication with A needs >IPSEC. Now, if B wants to access A outside, it needs IPSEC with SG and >A simultaneously! I have trouble following your text, but this sounds like the nested SA example (case 4) that 2401 calls out. Unfortunately, we've not had a means to specify this in IKE v1, so it seems that it is hard to make work in practice. If the WG feels that we need this capability, we can retain it in 2401bis, but we need to be able to say how the nesting is specified, from a management perspective. Steve From owner-ipsec@lists.tislabs.com Mon Apr 14 15:19:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EMJGbP089797; Mon, 14 Apr 2003 15:19:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22466 Mon, 14 Apr 2003 17:50:36 -0400 (EDT) Date: Tue, 15 Apr 2003 00:54:47 +0300 Message-Id: <200304142154.h3ELslw2009295@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com CC: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Mon, 14 Apr 2003 16:42:03 -0400) Subject: Re: Question on SA Bundle References: <200304141936.h3EJaoI3008229@burp.tkv.asdf.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Stephen Kent > BUT the WG will have to decide if the added complexity is something > we want to impose on all IPsec implementations. This exactly why I want to separate policy from IKE. Policy syntax and features would be just local implementation choice. This is then mapped into standard "SA+TS" construct. IKE should operate with this, without knowing anything about the original policy. > For example, in v2 the initiator sends SPD selector data showing the > range of values associated with an SA that is being created, to > enable the peer to know the range of traffic that can be carried on > the SA. I want the same, except that what is sent over is NOT the SPD selector data, but something that is extracted from the packet triggering the negotiation. I think we have "terminology problem". An example, I can have a policy "protocol = tcp" -> "use different SA-pair for each connection" In my terminology, from above it follows: SPD selector: "protocol = tcp" TS for SA: protocol=tcp, src_port=x, dst=port=y My claim is just: IKE does not need the "SPD selector". It just needs the "TS for SA" -part. And, that it should just negotiate this single unidiretional SA, and let the other end trigger negotiation of the other SA of the pair. I think, TS as defined in IKEv2 is fine. Just don't equate it with SPD policy selector. From owner-ipsec@lists.tislabs.com Mon Apr 14 15:25:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EMPkbP000792; Mon, 14 Apr 2003 15:25:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22534 Mon, 14 Apr 2003 17:56:48 -0400 (EDT) From: jknowles@SonicWALL.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Date: Mon, 14 Apr 2003 15:00:26 -0700 Message-ID: <385918F84B55DC4E9542E0A4812F413106E28E@us0exb01.us.sonicwall.com> Thread-Topic: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Thread-Index: AcMCtNELX7+dF5rQQumsS2X7lUwUxAAFG+Dg To: , Cc: , X-OriginalArrivalTime: 14 Apr 2003 22:00:27.0103 (UTC) FILETIME=[41C006F0:01C302D1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA22521 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Charlie, > Having read Tero's DHCP over IKE proposal, I continue to > believe that while > either DHCP or CP could be made to work that CP is the better > choice for > reasons of simplicity. (If I were king, I'd pick a protocol that was > simpler than either). OK, Charlie for King! > While it's attractive to reference DHCP rather than define a > subset of it > in order to shorten the spec, Tero's drafts make it clear > that using DHCP > won't shorten the spec because of the integration issues that > would need to > be added. DHCP was designed to run over an unreliable > datagram protocol > with broadcast capabilities for server discovery. IKE is a reliable > request/response protocol to a single peer. So running DHCP over IKE > requires that we specify how DHCP timeouts get handled and > how to deal with > the case where the responder has a packet but it's not his > turn to talk. > Tero's proposal describes how to deal with all these cases, but it's > awkward. Seems fair to say there is added complexity due to IKE/DHCP interaction. Since IKE is "reliable", I'm not sure how much added complexity there is, other than dealing with timeouts. I think DHCP and CP are not too far apart in terms of message structure complexity. > The strongest case for DHCP is when optimizing for the > configuration where > the IKE responder doesn't itself allocate IP addresses to the > IKE initiator > but rather acts as a DHCP relay to some DHCP server it accesses over a > network. Then there would be pretty much a one-to-one mapping > between the > messages on the wire and the DHCP payloads in the IKE > messages. But the IKE > endpoint would still be doing more processing than a DHCP > relay since it > would have to parse the DHCP messages as it passed them > through to learn > what address was assigned in order to put that address in the traffic > selectors. There will be parsing when doing DHCP proxy, as suggested by the CP authors, right? We need DHCP support one way or another (some of us at least). > When the IKE responder is allocating addresses out of its own pool or > getting them using RADIUS, it appears to me that processing > would be more > complex translating them to DHCP than translating them to CP. > My intuition > is that having the IKE responder lease addresses from its own > pool will be > the common case, since if the address is acquired from > elsewhere the IKE > responder will have to take some action to get traffic to the > allocated > address routed to it (most likely by responding to ARPs). Routing issues have to be dealt with no matter who allocates the address. Regarding the common case, certainly DHCP interaction is "a" common case, though maybe not "the" common case. > > So I continue to "not get it" in trying to understand the > advantages of > DHCP. Do we envision using the advanced capabilities of DHCP > to do things > like booting over the IPsec connection? If so, encapsulating all the > messages in IKE seems even more cumbersome. I would think the boot rom > would want to set up the IPsec connection, get an IP address, > and then run > DHCP over ESP. I'm not envisioning advanced capabilities, although having a standard way to offer them is nice. By "advantages of DHCP", I assume you mean "DHCP in IKE". The main advantage I see is that there are standard mechanisms for a remote client to issue DHCP requests and no standard mechanism for CP requests, (I'm speaking about OS capablities, not IKE client capabilities) so I don't have to translate the DHCP at all if I'm using a DHCP server. Of course, using RADIUS, LDAP, or internal gateway address space will require translation. Maybe the entire argument comes down to your point above about the "common" case. Lately, I've been wondering if we can't just add an optional DHCP CP payload type. Not sure if that would make everybody happy or make everybody mad. > > --Charlie > > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or > otherwise). Regards, Jim From owner-ipsec@lists.tislabs.com Mon Apr 14 15:25:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EMPnbP000803; Mon, 14 Apr 2003 15:25:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22558 Mon, 14 Apr 2003 18:00:55 -0400 (EDT) Date: Tue, 15 Apr 2003 01:04:46 +0300 Message-Id: <200304142204.h3EM4koT009631@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com CC: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Mon, 14 Apr 2003 16:42:03 -0400) Subject: Re: Question on SA Bundle References: <200304141936.h3EJaoI3008229@burp.tkv.asdf.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Oh, I need to expand my example a bit. I said "protocol = tcp" -> "use different SA-pair for each connection" and got from values extracted from the packet TS for SA: protocol=tcp, src_port=x, dst=port=y Before someone says: "but IKEv2 has address and port ranges! Your implementation does not support those, if it just extracts values from packet!" Answer: it's all in the local policy definition. It can use any suitable method of mapping the packet into TS data. Even, actually using the SPD selector ranges. "address-range" -> "use SA with matched address-range" and TS would contain the address range (instead of single address). But the key issue is: IKE does not need to know about this. It would just see the TS. From owner-ipsec@lists.tislabs.com Mon Apr 14 18:22:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3F1MJbP016390; Mon, 14 Apr 2003 18:22:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA23167 Mon, 14 Apr 2003 20:50:02 -0400 (EDT) Message-Id: <200304150053.h3F0rt0a004696@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload In-reply-to: Your message of "Mon, 14 Apr 2003 12:13:00 PDT." <16027.2108.76439.979793@thomasm-u1.cisco.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 14 Apr 2003 20:53:55 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie> DHCP. Do we envision using the advanced capabilities of DHCP to do Charlie> things like booting over the IPsec connection? If so, Charlie> encapsulating Very few devices (by installed base) use DHCP to boot. Yet, when the DHCP server went down at IETF on Sunday, it was a crisis. The whole point of DHCP is that what Michael Thomas says: Michael> pretty hopeless. Thus to my mind, lesser of evils Michael> is to beg, borrow and steal and punt as much work Michael> as possible to other wg's that actually care about Michael> this sort of thing... ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Mon Apr 14 19:59:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3F2x7bP023680; Mon, 14 Apr 2003 19:59:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA23447 Mon, 14 Apr 2003 22:31:58 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <20030411193135.GE30438@think> Subject: Re: IKE V2 Open Issues To: "Theodore Ts'o" Cc: Derek Atkins , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, Uri Blumenthal X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Mon, 14 Apr 2003 21:26:25 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04072003NP|April 07, 2003) at 04/14/2003 10:36:17 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Theodore Ts'o" wrote: > On Fri, Apr 11, 2003 at 10:16:13AM -0400, Uri Blumenthal wrote: > > > > > >However, another benefit for using two payload types: it makes it > > >easier for protocol analyzers like tcpdump or ethereal. They can > > >differentiate the cookie request N(COOKIE_REQUIRED{cookie}) from a > > >cookie response N(COOKIE{cookie}) to aid in analysis and debugging... > > >A small benefit indeed, but a tangible one for, IMHO, little > > >additional coding. You have to have the code to parse the packet > > >either way -- whether you look for IKEV2_NOTIFY_COOKIE or > > >..._COOKIE_REQUIRED is a one-line change. > > > > OK, sold. I'm convinced in the value of COOKIE_REQUIRED and > > support it. > > > > There hasn't been much other discussion on the list, but in the > absence of other comments, it seems to make sense to go with this > proposal, although it does require defining a new number for > COOKIE_REQUIRED. Done! --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Mon Apr 14 19:59:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3F2xCbP023687; Mon, 14 Apr 2003 19:59:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA23444 Mon, 14 Apr 2003 22:31:55 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <000601c30289$706f3fe0$5a00a8c0@personeta.com> Subject: Re: [rohc] FW: ESP and header compression (ROHC) To: "Yaron Sheffer" Cc: "IPSec List" , "Lars-Erik Jonsson \(EAB\)" , owner-ipsec@lists.tislabs.com, rohc@ietf.org X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Mon, 14 Apr 2003 22:29:38 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04072003NP|April 07, 2003) at 04/14/2003 10:36:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I may have been misunderstood. To clarify, I am discussing the following > stack: > > PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload > > In some cases, depending on the nature of the flows that use the ESP tunnel, > ESP plays the role of a link. In those cases, it makes sense to compress the > "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP > conversation there will be a single RTP flow within the tunnel, and ROHC is > beneficial for the internal headers. > > In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for > IP(2)+UDP+RTP. I am not familiar with the details of ROHC, so these comments may be completely out to lunch. If so, just ignore me. Assuming ROHC is designed to compress an unreliable reorderable packet stream, it would seem the most natural way to do this would be to define a new IPcomp compression algorithm based on ROHC. Then the stack would look like: PPP | IP(1) | ESP | {IPcomp | {IP(2) | UDP | RTP | Payload}compressed }encrypted If ROHC compresses an unreliable but ordered packet stream, it would be still be possible to implement it, though it would force the decompressing end to either discard out of order packets or increase latency trying to reconstruct the original order. If it compresses a reliable packet stream, it seems inappropriate to use it inside ESP. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Mon Apr 14 20:02:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3F329bP023789; Mon, 14 Apr 2003 20:02:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA23443 Mon, 14 Apr 2003 22:31:55 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: Interoperability - Overlapping requests To: "Zimmerman, Mark" Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Mon, 14 Apr 2003 21:35:21 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04072003NP|April 07, 2003) at 04/14/2003 10:36:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > A question regarding Section 2.3 of ikev2-06. > Perhaps I am not understanding the verbage correctly, but I could foresee > differing interpretations > being made by different developers. > > The first paragraph states: > > In order to maximize IKE throughput, an IKE endpoint MAY issue > multiple requests before getting a response to any of them. For > simplicity, an IKE implementation MAY choose to process requests > strictly in order and/or wait for a response to one request before > issuing another. Certain rules must be followed to assure > interoperability between implementations using different strategies. I agree it is confusing. I added "if the other endpoint has indicated its ability to handle such requests" to the end of the first sentence. Does that make it clear? --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Mon Apr 14 20:02:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3F32LbP023807; Mon, 14 Apr 2003 20:02:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA23442 Mon, 14 Apr 2003 22:31:52 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <3E9AE3C9.C7026779@airespace.com> Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload To: X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Mon, 14 Apr 2003 21:02:29 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04072003NP|April 07, 2003) at 04/14/2003 10:36:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some comments on others' postings: "Theodore Ts'o" wrote: > We note that in San Francisco the wg had decided that in the > absence of strong support, the default would be to stay with the > existing text in the ikev2 document (Configuration Payload). I'm concerned that in the past such a statement has caused the people who agree with the current state to ignore the debate but energize those who disagree. People who care should speak up! "Scott G. Kelly" wrote: > I think Darren's summary is pretty accurate. It's kind of a toss up. > However, one difference that I note is that with the dhcp approach, all > client config is (potentially) done prior to the instantiation of the > child sa. I'm not sure if this is a benefit or not, but it might be. This will be a blessing in some circumstances and a curse in others. While doing client config early makes for a simpler boot rom, it means that a site must be willing to give out client config information to anonymous requestors (or else place additional requirements on ordering of authentication messages and state machines within IKE processing. In most scenarios, I wouldn't expect it to matter. Michael Thomas wrote: > I'm not entirely sure how impolitic this is wrt my > employer's hive mind, but the thing that really > tips my feeling about this is that DHCP-in-IKE > keeps the IPsec wg out of the business of dealing > with... configuration. That seems like a huge boon > in my mind from a wheel-reinvention standpoint. > > So, mark my preference as DHCP-in-IKE. There are two ways CP might evolve in the future. CP has a syntax clearly designed for extensibility, and hence is an "infection site" for architects who want to add configuration options in the future in one more different way. I find that prospect scary. But it doesn't have to happen. If our successors show restraint, they will not enhance CP to include information that could better be sent over DHCP. DHCP can be effectively tunnelled over ESP, and could (and should) be used for such extensions. The configuration step of allocating an IP address is special because it results in information necessary for configuring the ESP SA. It therefore can't be done over the ESP SA without significant kludgery (though someone did make it work with IKEv1). --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Tue Apr 15 00:43:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3F7gwt2021893; Tue, 15 Apr 2003 00:43:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA24238 Tue, 15 Apr 2003 03:11:21 -0400 (EDT) Message-ID: <3E9BB0D7.3030604@cefriel.it> Date: Tue, 15 Apr 2003 09:12:23 +0200 From: Antonio Forzieri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; it-IT; rv:1.3) Gecko/20030312 X-Accept-Language: it, en, en-us MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <20030411192548.GC30438@think> In-Reply-To: <20030411192548.GC30438@think> X-Enigmail-Version: 0.74.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Posting-Agent: Hamster/2.0.0.0 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Ts'o ha scritto: > Paul's proposed revision seems clearer and reflects the discussion in > San Francisco. Does anybody have any problems with this text, or > should we just go with it? Paul's revision seems good to me. Let's go with it. -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ------------------------------------------------ From owner-ipsec@lists.tislabs.com Tue Apr 15 01:48:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3F8m6t2032085; Tue, 15 Apr 2003 01:48:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA24409 Tue, 15 Apr 2003 04:19:54 -0400 (EDT) Message-Id: <200304150823.h3F8NZof071773@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: sommerfeld@east.sun.com cc: Michael Thomas , Charlie_Kaufman@notesdev.ibm.com, "Theodore Ts'o" , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload In-reply-to: Your message of Mon, 14 Apr 2003 16:02:59 EDT. <200304142002.h3EK2xwm000983@thunk.east.sun.com> Date: Tue, 15 Apr 2003 10:23:35 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Indeed. My sense is that configuration is not an area of expertise for the members of this WG, and incorporating DHCP as-is is a better solution than trying to reinvent a wheel here. => I agree: for instance the CP stuff is not the proper solution for IPv6 and nobody'd like to spend some years to fix it (remember DHCPv6 :-). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Apr 15 04:16:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FBGBt2047787; Tue, 15 Apr 2003 04:16:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA24935 Tue, 15 Apr 2003 06:46:12 -0400 (EDT) To: "Lars-Erik Jonsson (EAB)" Cc: "'Yaron Sheffer'" , IPSec List , rohc@ietf.org Subject: Re: [rohc] FW: ESP and header compression (ROHC) References: From: Bjoern Groenvall Date: 15 Apr 2003 12:50:28 +0200 In-Reply-To: "Lars-Erik Jonsson's message of "Tue, 15 Apr 2003 10:22:30 +0200" Message-ID: Lines: 25 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Lars-Erik" == Lars-Erik Jonsson (EAB) writes: >> Taking the 'ROHC over re-ordering channels' question more >> generally; RFC 3095 does not work in such an environment. However, >> we are (I believe) trying to address this issue as part of ROHC for >> TCP... Lars-Erik> This was a design decision we made for 3095, but personally Lars-Erik> I think the modifications needed to make it work also in Lars-Erik> case of mis-ordering are small. If someone wants to look at Lars-Erik> this and write some input on it, I would be more than Lars-Erik> happy. The ESP and AH headers also have a "Sequence Number"-field that may be used to detect reordering and packet losses. /Björn -- _ _ ,_______________. Bjorn Gronvall (Björn Grönvall) /_______________/| Swedish Institute of Computer Science | || PO Box 1263, S-164 29 Kista, Sweden | Schroedingers || Email: bg@sics.se, Phone +46 -8 633 15 25 | Cat |/ Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30 `---------------' From owner-ipsec@lists.tislabs.com Tue Apr 15 06:11:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FDBbt2061637; Tue, 15 Apr 2003 06:11:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25271 Tue, 15 Apr 2003 08:42:25 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.3 Date: Tue, 15 Apr 2003 09:30:10 +0800 From: "Wang Haiguang" To: , , , Subject: Re: [rohc] FW: ESP and header compression (ROHC) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id VAA23295 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have also considered this scheme before, that is, compress the header behind the ESP before encryption and decompress it after decription in the end-to-end scenario. What I am not clear is the effect of header compression to security. If I am not wrong, the IPSec has add some padding bytes at the end of the packet in order to hide the length of packet. If we compress the padding bytes, will it endanger the security of the connection? Best regards. Haiguang >>> Yaron Sheffer 04/14/03 09:26pm >>> Hi Lars-Erik, I may have been misunderstood. To clarify, I am discussing the following stack: PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload In some cases, depending on the nature of the flows that use the ESP tunnel, ESP plays the role of a link. In those cases, it makes sense to compress the "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP conversation there will be a single RTP flow within the tunnel, and ROHC is beneficial for the internal headers. In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for IP(2)+UDP+RTP. Regards, Yaron ----- Original Message ----- From: "Lars-Erik Jonsson (EAB)" To: "'Yaron Sheffer'" ; "IPSec List" ; Sent: Monday, April 14, 2003 10:04 Subject: RE: [rohc] FW: ESP and header compression (ROHC) > Hi all, > > A few notes: > 1) ROHC is applied on a per-link basis, e.g. over PPP > 2) Based on the above point, there are ROHC compression profiles > defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) > > Compressing the network layer header is most important to gain > anything, but that can only be done on a per-link basis. Header > compression is thus applied per-link to compress network and > transport layer headers (and by heuristics also the application > layer RTP header). It is also simpler to do compression per-link, > as one can optimize for certain assumed characteristics (such as > in-order delivery). Further, it makes most sense as header > compression is an optimization for "narrow links". > > Therefore, I can not see why/how one could do "ROHC over ESP". > > BR > /Lars-Erik > > > > > > -----Original Message----- > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > Sent: den 13 april 2003 21:26 > > To: IPSec List; rohc@ietf.org > > Subject: [rohc] FW: ESP and header compression (ROHC) > > > > > > (please reply to both lists) > > > > Below is my question to Steve Kent (author of the new rev of ESP, and > > co-author of the original RFC) and his reply. I understand > > that IPCOMP is > > inferior to ROHC for RTP streams, and I'd like to hear other opinions > > regarding the usefulness of an "ROHC" indicator in ESP. > > > > This might certaily add complexity to IPSec, but if you make it > > non-negotiable and non-mandatory, it cannot be too terrible. > > > > Thanks, > > Yaron > > > > -----Original Message----- > > From: Stephen Kent [mailto:kent@bbn.com] > > Sent: Thursday, April 10, 2003 12:06 AM > > To: Yaron Sheffer > > Cc: Sara Bitan; kent@bbn.com > > Subject: Re: ESP and header compression (ROHC) > > > > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > > >Hi Steve, > > > > > >I have lately looked at issues with IPSec encryption of RTP > > streams (I am > > >aware of SRTP but I think we will want RTP over IPSec for > > some time to > > >come). A major issue is packet overhead. You can use Robust Header > > >Compression (ROHC) on the external IP+ESP headers - this is > > defined by the > > >ROHC RFC. But if you want to header-compress the RTP packets > > before it is > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > > because there's no > > >way to detect ROHC packets in the ESP header. I'd expect ESP > > to contain a > > >marker for ROHC packets, similarly to PPP. Has this option > > been considered > > >for the new version of ESP? > > > > > >Thanks, > > > Yaron > > > > No, the WG has not considered that option. The WG has been striving > > to make IPsec simpler and thus adding support for ROHC is contrary to > > that theme. For example, ROHC would have be be implemented within > > IPsec, after the SA lookup was performed, and ROHC decompression > > would have to be implemented in IPsec at the receiver, since the > > receiver has to check the headers against the SAD. IPsec already > > supports IPCOMP as a compression method for whole packets, not just > > headers, and thus it might be hard to persuade the WG to add ROHC > > support too. > > > > But, that's just my impression. You can always raise the > > question on the > > list. > > > > Steve > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From owner-ipsec@lists.tislabs.com Tue Apr 15 06:12:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FDC3t2061737; Tue, 15 Apr 2003 06:12:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25221 Tue, 15 Apr 2003 08:39:18 -0400 (EDT) Message-ID: <76C92FBBFB58D411AE760090271ED41806AC0D99@rsys002a.roke.co.uk> From: "West, Mark" To: "Lars-Erik Jonsson (EAB)" , "'Yaron Sheffer'" , IPSec List , rohc@ietf.org Subject: RE: [rohc] FW: ESP and header compression (ROHC) Date: Tue, 15 Apr 2003 09:01:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi all, Taking the 'ROHC over re-ordering channels' question more generally; RFC 3095 does not work in such an environment. However, we are (I believe) trying to address this issue as part of ROHC for TCP... Anyway, tunnels (and especially IPsec) can simply be treated as a link. In which case, rohc can be applied on that link. In the case of IPsec/ESP it may make a great deal of sense to compress the headers inside of the tunnel encapsulation. The VPN endpoints are probably disjoint from any particular physical link that benefits from compression and so, to me, it makes sense to do the compression in the two different places. Cheers, Mark. -- Mark A. West, Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 -----Original Message----- From: Lars-Erik Jonsson (EAB) [mailto:Lars-Erik.Jonsson@epl.ericsson.se] Sent: 14 April 2003 14:47 To: 'Yaron Sheffer'; IPSec List; rohc@ietf.org Subject: RE: [rohc] FW: ESP and header compression (ROHC) Yaron, That clarified the scenario, just note that "ROHC over tunnels" has not yet been addressed in the ROHC WG. I do not say that that there must be problems with that, but it should be noted that the link assumptions made for ROHC might not match a tunneling case. Anyway, I am not sure you need anything special in the ESP header, but can do per-link compression of the whole chain. You would have an outer and an inner IP header, and the ESP header would be part of a compressed chain (RFC 3095 section 5.8, 5.8.4.3). However, if the inner headers are encrypted, you can of course not compress all headers on a per-link basis. Is that the case you are considering? Cheers, /L-E > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf@gmx.net] > Sent: den 14 april 2003 15:26 > To: Lars-Erik Jonsson (EAB); IPSec List; rohc@ietf.org > Subject: Re: [rohc] FW: ESP and header compression (ROHC) > > > Hi Lars-Erik, > > I may have been misunderstood. To clarify, I am discussing > the following > stack: > > PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload > > In some cases, depending on the nature of the flows that use > the ESP tunnel, > ESP plays the role of a link. In those cases, it makes sense > to compress the > "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP > conversation there will be a single RTP flow within the > tunnel, and ROHC is > beneficial for the internal headers. > > In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for > IP(2)+UDP+RTP. > > Regards, > Yaron > > ----- Original Message ----- > From: "Lars-Erik Jonsson (EAB)" > To: "'Yaron Sheffer'" ; "IPSec List" > ; > Sent: Monday, April 14, 2003 10:04 > Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > > > Hi all, > > > > A few notes: > > 1) ROHC is applied on a per-link basis, e.g. over PPP > > 2) Based on the above point, there are ROHC compression profiles > > defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) > > > > Compressing the network layer header is most important to gain > > anything, but that can only be done on a per-link basis. Header > > compression is thus applied per-link to compress network and > > transport layer headers (and by heuristics also the application > > layer RTP header). It is also simpler to do compression per-link, > > as one can optimize for certain assumed characteristics (such as > > in-order delivery). Further, it makes most sense as header > > compression is an optimization for "narrow links". > > > > Therefore, I can not see why/how one could do "ROHC over ESP". > > > > BR > > /Lars-Erik > > > > > > > > > > > -----Original Message----- > > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > > Sent: den 13 april 2003 21:26 > > > To: IPSec List; rohc@ietf.org > > > Subject: [rohc] FW: ESP and header compression (ROHC) > > > > > > > > > (please reply to both lists) > > > > > > Below is my question to Steve Kent (author of the new rev > of ESP, and > > > co-author of the original RFC) and his reply. I understand > > > that IPCOMP is > > > inferior to ROHC for RTP streams, and I'd like to hear > other opinions > > > regarding the usefulness of an "ROHC" indicator in ESP. > > > > > > This might certaily add complexity to IPSec, but if you make it > > > non-negotiable and non-mandatory, it cannot be too terrible. > > > > > > Thanks, > > > Yaron > > > > > > -----Original Message----- > > > From: Stephen Kent [mailto:kent@bbn.com] > > > Sent: Thursday, April 10, 2003 12:06 AM > > > To: Yaron Sheffer > > > Cc: Sara Bitan; kent@bbn.com > > > Subject: Re: ESP and header compression (ROHC) > > > > > > > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > > > >Hi Steve, > > > > > > > >I have lately looked at issues with IPSec encryption of RTP > > > streams (I am > > > >aware of SRTP but I think we will want RTP over IPSec for > > > some time to > > > >come). A major issue is packet overhead. You can use > Robust Header > > > >Compression (ROHC) on the external IP+ESP headers - this is > > > defined by the > > > >ROHC RFC. But if you want to header-compress the RTP packets > > > before it is > > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > > > because there's no > > > >way to detect ROHC packets in the ESP header. I'd expect ESP > > > to contain a > > > >marker for ROHC packets, similarly to PPP. Has this option > > > been considered > > > >for the new version of ESP? > > > > > > > >Thanks, > > > > Yaron > > > > > > No, the WG has not considered that option. The WG has > been striving > > > to make IPsec simpler and thus adding support for ROHC is > contrary to > > > that theme. For example, ROHC would have be be implemented within > > > IPsec, after the SA lookup was performed, and ROHC decompression > > > would have to be implemented in IPsec at the receiver, since the > > > receiver has to check the headers against the SAD. IPsec already > > > supports IPCOMP as a compression method for whole > packets, not just > > > headers, and thus it might be hard to persuade the WG to add ROHC > > > support too. > > > > > > But, that's just my impression. You can always raise the > > > question on the > > > list. > > > > > > Steve > > > > > > _______________________________________________ > > > Rohc mailing list > > > Rohc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- From owner-ipsec@lists.tislabs.com Tue Apr 15 06:12:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FDC8t2061787; Tue, 15 Apr 2003 06:12:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25229 Tue, 15 Apr 2003 08:40:17 -0400 (EDT) Message-ID: <76C92FBBFB58D411AE760090271ED41806636942@rsys002a.roke.co.uk> From: "West, Mark" To: "'Tmima Koren'" , "Lars-Erik Jonsson (EAB)" , "'Yaron Sheffer'" , IPSec List , rohc@ietf.org Subject: RE: [rohc] FW: ESP and header compression (ROHC) Date: Tue, 15 Apr 2003 11:31:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Tmima, Whoops - you're quite right! I really must learn to proof-read my e-mails... I was muddling up two thoughts here; let me try again: a tunnel is a link and can be considered as such by rohc-type-compression-schemes. A rohc-type-compression-scheme could then be applied where its assumptions about channel characteristics match those of the link. FWIW, I agree with Lars-Erik that the modifications to do robust header compression over re-ordering channels are small. I may even contribute some text along these lines (once I've sorted out all the other text I already owe...) Cheers, Mark. -----Original Message----- From: Tmima Koren [mailto:tmima@cisco.com] Sent: 15 April 2003 09:41 To: West, Mark; Lars-Erik Jonsson (EAB); 'Yaron Sheffer'; IPSec List; rohc@ietf.org Subject: RE: [rohc] FW: ESP and header compression (ROHC) At 09:01 AM 4/15/2003 +0100, West, Mark wrote: >Hi all, > >Taking the 'ROHC over re-ordering channels' question more generally; RFC >3095 does not work in such an environment. However, we are (I believe) >trying to address this issue as part of ROHC for TCP... > >Anyway, tunnels (and especially IPsec) can simply be treated as a >link. In which case, rohc can be applied on that link. But a tunnel is a re-ordering channel Tmima >In the case of IPsec/ESP it may make a great deal of sense to compress the >headers inside of the tunnel encapsulation. The VPN endpoints are >probably disjoint from any particular physical link that benefits from >compression and so, to me, it makes sense to do the compression in the two >different places. > >Cheers, > >Mark. > > >-- >Mark A. West, Consultant Engineer >Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN >Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 > > > >-----Original Message----- >From: Lars-Erik Jonsson (EAB) [mailto:Lars-Erik.Jonsson@epl.ericsson.se] >Sent: 14 April 2003 14:47 >To: 'Yaron Sheffer'; IPSec List; rohc@ietf.org >Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > >Yaron, > >That clarified the scenario, just note that "ROHC over tunnels" >has not yet been addressed in the ROHC WG. I do not say that >that there must be problems with that, but it should be noted >that the link assumptions made for ROHC might not match a >tunneling case. > >Anyway, I am not sure you need anything special in the ESP >header, but can do per-link compression of the whole chain. You >would have an outer and an inner IP header, and the ESP header >would be part of a compressed chain (RFC 3095 section 5.8, 5.8.4.3). > >However, if the inner headers are encrypted, you can of course >not compress all headers on a per-link basis. Is that the case >you are considering? > >Cheers, >/L-E > > > > -----Original Message----- > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > Sent: den 14 april 2003 15:26 > > To: Lars-Erik Jonsson (EAB); IPSec List; rohc@ietf.org > > Subject: Re: [rohc] FW: ESP and header compression (ROHC) > > > > > > Hi Lars-Erik, > > > > I may have been misunderstood. To clarify, I am discussing > > the following > > stack: > > > > PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload > > > > In some cases, depending on the nature of the flows that use > > the ESP tunnel, > > ESP plays the role of a link. In those cases, it makes sense > > to compress the > > "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP > > conversation there will be a single RTP flow within the > > tunnel, and ROHC is > > beneficial for the internal headers. > > > > In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for > > IP(2)+UDP+RTP. > > > > Regards, > > Yaron > > > > ----- Original Message ----- > > From: "Lars-Erik Jonsson (EAB)" > > To: "'Yaron Sheffer'" ; "IPSec List" > > ; > > Sent: Monday, April 14, 2003 10:04 > > Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > > > > > > Hi all, > > > > > > A few notes: > > > 1) ROHC is applied on a per-link basis, e.g. over PPP > > > 2) Based on the above point, there are ROHC compression profiles > > > defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) > > > > > > Compressing the network layer header is most important to gain > > > anything, but that can only be done on a per-link basis. Header > > > compression is thus applied per-link to compress network and > > > transport layer headers (and by heuristics also the application > > > layer RTP header). It is also simpler to do compression per-link, > > > as one can optimize for certain assumed characteristics (such as > > > in-order delivery). Further, it makes most sense as header > > > compression is an optimization for "narrow links". > > > > > > Therefore, I can not see why/how one could do "ROHC over ESP". > > > > > > BR > > > /Lars-Erik > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > > > Sent: den 13 april 2003 21:26 > > > > To: IPSec List; rohc@ietf.org > > > > Subject: [rohc] FW: ESP and header compression (ROHC) > > > > > > > > > > > > (please reply to both lists) > > > > > > > > Below is my question to Steve Kent (author of the new rev > > of ESP, and > > > > co-author of the original RFC) and his reply. I understand > > > > that IPCOMP is > > > > inferior to ROHC for RTP streams, and I'd like to hear > > other opinions > > > > regarding the usefulness of an "ROHC" indicator in ESP. > > > > > > > > This might certaily add complexity to IPSec, but if you make it > > > > non-negotiable and non-mandatory, it cannot be too terrible. > > > > > > > > Thanks, > > > > Yaron > > > > > > > > -----Original Message----- > > > > From: Stephen Kent [mailto:kent@bbn.com] > > > > Sent: Thursday, April 10, 2003 12:06 AM > > > > To: Yaron Sheffer > > > > Cc: Sara Bitan; kent@bbn.com > > > > Subject: Re: ESP and header compression (ROHC) > > > > > > > > > > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > > > > >Hi Steve, > > > > > > > > > >I have lately looked at issues with IPSec encryption of RTP > > > > streams (I am > > > > >aware of SRTP but I think we will want RTP over IPSec for > > > > some time to > > > > >come). A major issue is packet overhead. You can use > > Robust Header > > > > >Compression (ROHC) on the external IP+ESP headers - this is > > > > defined by the > > > > >ROHC RFC. But if you want to header-compress the RTP packets > > > > before it is > > > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > > > > because there's no > > > > >way to detect ROHC packets in the ESP header. I'd expect ESP > > > > to contain a > > > > >marker for ROHC packets, similarly to PPP. Has this option > > > > been considered > > > > >for the new version of ESP? > > > > > > > > > >Thanks, > > > > > Yaron > > > > > > > > No, the WG has not considered that option. The WG has > > been striving > > > > to make IPsec simpler and thus adding support for ROHC is > > contrary to > > > > that theme. For example, ROHC would have be be implemented within > > > > IPsec, after the SA lookup was performed, and ROHC decompression > > > > would have to be implemented in IPsec at the receiver, since the > > > > receiver has to check the headers against the SAD. IPsec already > > > > supports IPCOMP as a compression method for whole > > packets, not just > > > > headers, and thus it might be hard to persuade the WG to add ROHC > > > > support too. > > > > > > > > But, that's just my impression. You can always raise the > > > > question on the > > > > list. > > > > > > > > Steve > > > > > > > > _______________________________________________ > > > > Rohc mailing list > > > > Rohc@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > > > > >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- From owner-ipsec@lists.tislabs.com Tue Apr 15 06:13:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FDDgt2062060; Tue, 15 Apr 2003 06:13:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25310 Tue, 15 Apr 2003 08:45:29 -0400 (EDT) Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'Yaron Sheffer'" , IPSec List , rohc@ietf.org Subject: RE: [rohc] FW: ESP and header compression (ROHC) Date: Tue, 15 Apr 2003 10:22:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Taking the 'ROHC over re-ordering channels' question more > generally; RFC 3095 does not work in such an environment. > However, we are (I believe) trying to address this issue as > part of ROHC for TCP... This was a design decision we made for 3095, but personally I think the modifications needed to make it work also in case of mis-ordering are small. If someone wants to look at this and write some input on it, I would be more than happy. > Anyway, tunnels (and especially IPsec) can simply be treated > as a link. In which case, rohc can be applied on that link. Yes, a "ROHC over tunnels" document could potentially be justifiable. > In the case of IPsec/ESP it may make a great deal of sense to > compress the headers inside of the tunnel encapsulation. The > VPN endpoints are probably disjoint from any particular > physical link that benefits from compression and so, to me, > it makes sense to do the compression in the two different places. Yes, that is what you would have to do if encryption is applied over the tunnel. /L-E From owner-ipsec@lists.tislabs.com Tue Apr 15 06:14:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FDEGt2062150; Tue, 15 Apr 2003 06:14:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25321 Tue, 15 Apr 2003 08:46:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20030415013913.026d5b38@mira-sjcm-2.cisco.com> X-Sender: tmima@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 01:40:50 -0700 To: "West, Mark" , "Lars-Erik Jonsson (EAB)" , "'Yaron Sheffer'" , IPSec List , rohc@ietf.org From: Tmima Koren Subject: RE: [rohc] FW: ESP and header compression (ROHC) In-Reply-To: <76C92FBBFB58D411AE760090271ED41806AC0D99@rsys002a.roke.co. uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:01 AM 4/15/2003 +0100, West, Mark wrote: >Hi all, > >Taking the 'ROHC over re-ordering channels' question more generally; RFC >3095 does not work in such an environment. However, we are (I believe) >trying to address this issue as part of ROHC for TCP... > >Anyway, tunnels (and especially IPsec) can simply be treated as a >link. In which case, rohc can be applied on that link. But a tunnel is a re-ordering channel Tmima >In the case of IPsec/ESP it may make a great deal of sense to compress the >headers inside of the tunnel encapsulation. The VPN endpoints are >probably disjoint from any particular physical link that benefits from >compression and so, to me, it makes sense to do the compression in the two >different places. > >Cheers, > >Mark. > > >-- >Mark A. West, Consultant Engineer >Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN >Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 > > > >-----Original Message----- >From: Lars-Erik Jonsson (EAB) [mailto:Lars-Erik.Jonsson@epl.ericsson.se] >Sent: 14 April 2003 14:47 >To: 'Yaron Sheffer'; IPSec List; rohc@ietf.org >Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > >Yaron, > >That clarified the scenario, just note that "ROHC over tunnels" >has not yet been addressed in the ROHC WG. I do not say that >that there must be problems with that, but it should be noted >that the link assumptions made for ROHC might not match a >tunneling case. > >Anyway, I am not sure you need anything special in the ESP >header, but can do per-link compression of the whole chain. You >would have an outer and an inner IP header, and the ESP header >would be part of a compressed chain (RFC 3095 section 5.8, 5.8.4.3). > >However, if the inner headers are encrypted, you can of course >not compress all headers on a per-link basis. Is that the case >you are considering? > >Cheers, >/L-E > > > > -----Original Message----- > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > Sent: den 14 april 2003 15:26 > > To: Lars-Erik Jonsson (EAB); IPSec List; rohc@ietf.org > > Subject: Re: [rohc] FW: ESP and header compression (ROHC) > > > > > > Hi Lars-Erik, > > > > I may have been misunderstood. To clarify, I am discussing > > the following > > stack: > > > > PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload > > > > In some cases, depending on the nature of the flows that use > > the ESP tunnel, > > ESP plays the role of a link. In those cases, it makes sense > > to compress the > > "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP > > conversation there will be a single RTP flow within the > > tunnel, and ROHC is > > beneficial for the internal headers. > > > > In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for > > IP(2)+UDP+RTP. > > > > Regards, > > Yaron > > > > ----- Original Message ----- > > From: "Lars-Erik Jonsson (EAB)" > > To: "'Yaron Sheffer'" ; "IPSec List" > > ; > > Sent: Monday, April 14, 2003 10:04 > > Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > > > > > > Hi all, > > > > > > A few notes: > > > 1) ROHC is applied on a per-link basis, e.g. over PPP > > > 2) Based on the above point, there are ROHC compression profiles > > > defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) > > > > > > Compressing the network layer header is most important to gain > > > anything, but that can only be done on a per-link basis. Header > > > compression is thus applied per-link to compress network and > > > transport layer headers (and by heuristics also the application > > > layer RTP header). It is also simpler to do compression per-link, > > > as one can optimize for certain assumed characteristics (such as > > > in-order delivery). Further, it makes most sense as header > > > compression is an optimization for "narrow links". > > > > > > Therefore, I can not see why/how one could do "ROHC over ESP". > > > > > > BR > > > /Lars-Erik > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > > > Sent: den 13 april 2003 21:26 > > > > To: IPSec List; rohc@ietf.org > > > > Subject: [rohc] FW: ESP and header compression (ROHC) > > > > > > > > > > > > (please reply to both lists) > > > > > > > > Below is my question to Steve Kent (author of the new rev > > of ESP, and > > > > co-author of the original RFC) and his reply. I understand > > > > that IPCOMP is > > > > inferior to ROHC for RTP streams, and I'd like to hear > > other opinions > > > > regarding the usefulness of an "ROHC" indicator in ESP. > > > > > > > > This might certaily add complexity to IPSec, but if you make it > > > > non-negotiable and non-mandatory, it cannot be too terrible. > > > > > > > > Thanks, > > > > Yaron > > > > > > > > -----Original Message----- > > > > From: Stephen Kent [mailto:kent@bbn.com] > > > > Sent: Thursday, April 10, 2003 12:06 AM > > > > To: Yaron Sheffer > > > > Cc: Sara Bitan; kent@bbn.com > > > > Subject: Re: ESP and header compression (ROHC) > > > > > > > > > > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > > > > >Hi Steve, > > > > > > > > > >I have lately looked at issues with IPSec encryption of RTP > > > > streams (I am > > > > >aware of SRTP but I think we will want RTP over IPSec for > > > > some time to > > > > >come). A major issue is packet overhead. You can use > > Robust Header > > > > >Compression (ROHC) on the external IP+ESP headers - this is > > > > defined by the > > > > >ROHC RFC. But if you want to header-compress the RTP packets > > > > before it is > > > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > > > > because there's no > > > > >way to detect ROHC packets in the ESP header. I'd expect ESP > > > > to contain a > > > > >marker for ROHC packets, similarly to PPP. Has this option > > > > been considered > > > > >for the new version of ESP? > > > > > > > > > >Thanks, > > > > > Yaron > > > > > > > > No, the WG has not considered that option. The WG has > > been striving > > > > to make IPsec simpler and thus adding support for ROHC is > > contrary to > > > > that theme. For example, ROHC would have be be implemented within > > > > IPsec, after the SA lookup was performed, and ROHC decompression > > > > would have to be implemented in IPsec at the receiver, since the > > > > receiver has to check the headers against the SAD. IPsec already > > > > supports IPCOMP as a compression method for whole > > packets, not just > > > > headers, and thus it might be hard to persuade the WG to add ROHC > > > > support too. > > > > > > > > But, that's just my impression. You can always raise the > > > > question on the > > > > list. > > > > > > > > Steve > > > > > > > > _______________________________________________ > > > > Rohc mailing list > > > > Rohc@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > > > > >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc From owner-ipsec@lists.tislabs.com Tue Apr 15 06:33:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FDXbt2064089; Tue, 15 Apr 2003 06:33:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25411 Tue, 15 Apr 2003 09:01:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20030415055212.00b72e20@mira-sjcm-1.cisco.com> X-Sender: mcgrew@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 06:04:34 -0700 To: "West, Mark" From: David Mcgrew Subject: RE: [rohc] FW: ESP and header compression (ROHC) Cc: "Lars-Erik Jonsson (EAB)" , "'Yaron Sheffer'" , IPSec List , rohc@ietf.org In-Reply-To: <76C92FBBFB58D411AE760090271ED41806AC0D99@rsys002a.roke.co. uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, At 09:01 AM 4/15/2003 +0100, West, Mark wrote: >Hi all, > >Taking the 'ROHC over re-ordering channels' question more generally; RFC >3095 does not work in such an environment. However, we are (I believe) >trying to address this issue as part of ROHC for TCP... > >Anyway, tunnels (and especially IPsec) can simply be treated as a >link. In which case, rohc can be applied on that link. > >In the case of IPsec/ESP it may make a great deal of sense to compress the >headers inside of the tunnel encapsulation. The VPN endpoints are >probably disjoint from any particular physical link that benefits from >compression and so, to me, it makes sense to do the compression in the two >different places. yes, I think that's right. It seems to be the case that inner-tunnel header compression is worthwhile for telephony. Do you think that it would be worth doing for wireless links as well? I guess that the answer might depend on the traffic that's going over the VPN link. There are some subtle security issues with this sort of scheme, but I don't think that they're insuperable. David >Cheers, > >Mark. > > >-- >Mark A. West, Consultant Engineer >Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN >Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 > > > >-----Original Message----- >From: Lars-Erik Jonsson (EAB) [mailto:Lars-Erik.Jonsson@epl.ericsson.se] >Sent: 14 April 2003 14:47 >To: 'Yaron Sheffer'; IPSec List; rohc@ietf.org >Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > >Yaron, > >That clarified the scenario, just note that "ROHC over tunnels" >has not yet been addressed in the ROHC WG. I do not say that >that there must be problems with that, but it should be noted >that the link assumptions made for ROHC might not match a >tunneling case. > >Anyway, I am not sure you need anything special in the ESP >header, but can do per-link compression of the whole chain. You >would have an outer and an inner IP header, and the ESP header >would be part of a compressed chain (RFC 3095 section 5.8, 5.8.4.3). > >However, if the inner headers are encrypted, you can of course >not compress all headers on a per-link basis. Is that the case >you are considering? > >Cheers, >/L-E > > > > -----Original Message----- > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > Sent: den 14 april 2003 15:26 > > To: Lars-Erik Jonsson (EAB); IPSec List; rohc@ietf.org > > Subject: Re: [rohc] FW: ESP and header compression (ROHC) > > > > > > Hi Lars-Erik, > > > > I may have been misunderstood. To clarify, I am discussing > > the following > > stack: > > > > PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload > > > > In some cases, depending on the nature of the flows that use > > the ESP tunnel, > > ESP plays the role of a link. In those cases, it makes sense > > to compress the > > "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP > > conversation there will be a single RTP flow within the > > tunnel, and ROHC is > > beneficial for the internal headers. > > > > In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for > > IP(2)+UDP+RTP. > > > > Regards, > > Yaron > > > > ----- Original Message ----- > > From: "Lars-Erik Jonsson (EAB)" > > To: "'Yaron Sheffer'" ; "IPSec List" > > ; > > Sent: Monday, April 14, 2003 10:04 > > Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > > > > > > Hi all, > > > > > > A few notes: > > > 1) ROHC is applied on a per-link basis, e.g. over PPP > > > 2) Based on the above point, there are ROHC compression profiles > > > defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) > > > > > > Compressing the network layer header is most important to gain > > > anything, but that can only be done on a per-link basis. Header > > > compression is thus applied per-link to compress network and > > > transport layer headers (and by heuristics also the application > > > layer RTP header). It is also simpler to do compression per-link, > > > as one can optimize for certain assumed characteristics (such as > > > in-order delivery). Further, it makes most sense as header > > > compression is an optimization for "narrow links". > > > > > > Therefore, I can not see why/how one could do "ROHC over ESP". > > > > > > BR > > > /Lars-Erik > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > > > Sent: den 13 april 2003 21:26 > > > > To: IPSec List; rohc@ietf.org > > > > Subject: [rohc] FW: ESP and header compression (ROHC) > > > > > > > > > > > > (please reply to both lists) > > > > > > > > Below is my question to Steve Kent (author of the new rev > > of ESP, and > > > > co-author of the original RFC) and his reply. I understand > > > > that IPCOMP is > > > > inferior to ROHC for RTP streams, and I'd like to hear > > other opinions > > > > regarding the usefulness of an "ROHC" indicator in ESP. > > > > > > > > This might certaily add complexity to IPSec, but if you make it > > > > non-negotiable and non-mandatory, it cannot be too terrible. > > > > > > > > Thanks, > > > > Yaron > > > > > > > > -----Original Message----- > > > > From: Stephen Kent [mailto:kent@bbn.com] > > > > Sent: Thursday, April 10, 2003 12:06 AM > > > > To: Yaron Sheffer > > > > Cc: Sara Bitan; kent@bbn.com > > > > Subject: Re: ESP and header compression (ROHC) > > > > > > > > > > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > > > > >Hi Steve, > > > > > > > > > >I have lately looked at issues with IPSec encryption of RTP > > > > streams (I am > > > > >aware of SRTP but I think we will want RTP over IPSec for > > > > some time to > > > > >come). A major issue is packet overhead. You can use > > Robust Header > > > > >Compression (ROHC) on the external IP+ESP headers - this is > > > > defined by the > > > > >ROHC RFC. But if you want to header-compress the RTP packets > > > > before it is > > > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > > > > because there's no > > > > >way to detect ROHC packets in the ESP header. I'd expect ESP > > > > to contain a > > > > >marker for ROHC packets, similarly to PPP. Has this option > > > > been considered > > > > >for the new version of ESP? > > > > > > > > > >Thanks, > > > > > Yaron > > > > > > > > No, the WG has not considered that option. The WG has > > been striving > > > > to make IPsec simpler and thus adding support for ROHC is > > contrary to > > > > that theme. For example, ROHC would have be be implemented within > > > > IPsec, after the SA lookup was performed, and ROHC decompression > > > > would have to be implemented in IPsec at the receiver, since the > > > > receiver has to check the headers against the SAD. IPsec already > > > > supports IPCOMP as a compression method for whole > > packets, not just > > > > headers, and thus it might be hard to persuade the WG to add ROHC > > > > support too. > > > > > > > > But, that's just my impression. You can always raise the > > > > question on the > > > > list. > > > > > > > > Steve > > > > > > > > _______________________________________________ > > > > Rohc mailing list > > > > Rohc@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > > > > >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc From owner-ipsec@lists.tislabs.com Tue Apr 15 07:00:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FDxvt2064648; Tue, 15 Apr 2003 07:00:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25606 Tue, 15 Apr 2003 09:26:31 -0400 (EDT) Message-Id: <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> X-Sender: mcgrew@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 06:29:45 -0700 To: "Wang Haiguang" From: David Mcgrew Subject: (in)security of ESP with header compression Cc: , , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Wang, length-hiding is an ESP option. If it is not used, then the traffic protected by ESP might be more susceptible to traffic analysis. For some applications, this is not a big deal. For example: no adversary is going to be surprised that an IP telephone sends 50 voice packets a second, nor would any adversary be fooled by the padding. To my mind, length-hiding is probably incompatible with header compression, though I don't see any security issues that would result from using them in conjunction. There are other security issues, though. The fact that the header compression is stateful (i.e., the decompression of a packet depends on the packets that have been received before) means that an adversary can force the receiver into decompressing incorrectly by re-ordering packets. The use of message authentication and replay protection doesn't stop this attack. ESP was designed to be tolerant of packet reorder, so using it with a stateful decompressor is problematic. There are two ways out of this bind: use a decompressor that won't cause any security failures due to reorder (which requires lots of careful analysis), or authenticate the message *before* it is compressed, rather than after it is compressed (which requires some encapsulation other than ESP). Jan Vilhuber and I have been working on both of these approaches. If there is interest, we could bring this work to the IETF, though I'm not sure that WG would be appropriate. David At 09:30 AM 4/15/2003 +0800, Wang Haiguang wrote: >To: , , , > >Subject: Re: [rohc] FW: ESP and header compression (ROHC) > >Hi, > >I have also considered this scheme before, that is, compress the header >behind the ESP before encryption and decompress it after decription in the >end-to-end scenario. > >What I am not clear is the effect of header compression to security. >If I am not wrong, the IPSec has add some padding bytes at the >end of the packet in order to hide the length of packet. > >If we compress the padding bytes, will it endanger the security of the >connection? > >Best regards. > >Haiguang From owner-ipsec@lists.tislabs.com Tue Apr 15 10:09:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FH9Xt2077803; Tue, 15 Apr 2003 10:09:34 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26583 Tue, 15 Apr 2003 12:31:44 -0400 (EDT) To: Michael Richardson Cc: ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload References: <200304112152.h3BLq5ux021015@marajade.sandelman.ottawa.on.ca> Date: 15 Apr 2003 12:36:11 -0400 In-Reply-To: <200304112152.h3BLq5ux021015@marajade.sandelman.ottawa.on.ca> Message-ID: Lines: 57 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > >>>>> "Derek" == Derek Atkins writes: > Derek> issues point at one towards the other. I think Config Payload > Derek> wins on performance, and DHCP-over-IKE wins on extensibility. > Derek> DHCP certainly wins in terms of using end-to-end DHCP > Derek> authentication, but that implies the use of a DHCP infrastructure. > > The use of DHCP syntax on the wire does not imply that a DHCP > infrastructure must exist. The converse is just as true.. Not using DHCP syntax on the wire dos not imply that a DHCP cannot exist.... It's all just a translation issue at the security gateway -- a gateway which must be involved in the configuration path anyways in order to read the address and set traffic selectors. > If you want to build a self-contained gateway box that manages its own > address pool (on the box irself), then you can do that. > If you want to translate to other infrasture (radius), Tero has documented > how to do that. Sure, but it works in reverse, too -- the IKE Daemon on the security gateway needs to be able to translate from whatever Foo-over-IKE we choose to whatever actual configuration protocols are in use. So what? It's no easier to implement a DHCP to RADIUS converter as it is to implement a CP to RADIUS converter. Similarly, are there actual DHCP libraries available? The ISC DHCP software certainly doesn't install "libdhcp" anywhere on my system. Are there other DHCP client libraries that are available, so IKE implementors don't need to implement DHCP as well as IKE? > Tero also argues that if you are using Radius with EAP, that your round > trip count is already larger than 4, so DHCP does not add to it. Yea, sure, but is that necessarily that "common case" when using IKE Configuration? In other words, do we expect that IKE Configuration will be used simultaneously with EAP the vast majority of the time? Or do we think that it will be used just as often with other forms of authentication, like RSA certs? On another note, can you even start the configuration process before EAP finishes? I'm not convinced you can run it concurrently with EAP, which implies that the extra messages from EAP and then DHCP would have to be serialized, making the exchange even longer! I say this because I don't see how a server can respond with a DHCPOFFER until the client has authenticated (e.g. EAP finished). Am I missing something? -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Tue Apr 15 10:32:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FHWNt2080871; Tue, 15 Apr 2003 10:32:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26617 Tue, 15 Apr 2003 12:50:52 -0400 (EDT) To: David Mcgrew Cc: "West, Mark" , "Lars-Erik Jonsson (EAB)" , "'Yaron Sheffer'" , IPSec List , rohc@ietf.org From: Derek Atkins Subject: Re: [rohc] FW: ESP and header compression (ROHC) References: <4.3.2.7.2.20030415055212.00b72e20@mira-sjcm-1.cisco.com> Date: 15 Apr 2003 12:54:33 -0400 In-Reply-To: <4.3.2.7.2.20030415055212.00b72e20@mira-sjcm-1.cisco.com> Message-ID: Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David Mcgrew writes: > > In the case of IPsec/ESP it may make a great deal of sense to > > compress the headers inside of the tunnel encapsulation. The VPN > > endpoints are probably disjoint from any particular physical link > > that benefits from compression and so, to me, it makes sense to do > > the compression in the two different places. > > yes, I think that's right. It seems to be the case that inner-tunnel > header compression is worthwhile for telephony. Do you think that it > would be worth doing for wireless links as well? I guess that the > answer might depend on the traffic that's going over the VPN link. > > There are some subtle security issues with this sort of scheme, but I > don't think that they're insuperable. It sounds like this is a job for a new IPCOMP algorithm type. Define an IPCOMP Algorithm that performs 'ROHC' operations inside the tunnel, so you get: IP ESP IPCOMP IP UDP RTP ... You could even perform ROHC on the outside packet, too. Indeed, one could even use the IPCOMP SA state to pre-configure known compression points (for example, if the internal network is an IPv4 /24, you could always reduce one address to a single 8-bit number because the other 24 bits are "understood". Similar for port numbers, if you have a limited SA you can put the information into the SA and then strip it out of the actual packet. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Tue Apr 15 11:30:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FIUKt2084827; Tue, 15 Apr 2003 11:30:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26832 Tue, 15 Apr 2003 13:57:44 -0400 (EDT) Message-Id: <200304151801.h3FI1BFj003568@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Paul Knight" Cc: smb@research.att.com, ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-sctp-06.txt In-reply-to: Your message of "Thu, 10 Apr 2003 12:27:52 EDT." <6204FDDE129D364D8040A98BCCB290EF052203FD@zbl6c004.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Apr 2003 14:01:11 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You're right, said paragraph will be deleted. The rationale behind it was to try to minimize the risk of address-imprersonation attacks inside a tunnel, but this is in fact taken care of at the IKE{,v2} level by establishing the appropriate SPD entries. -Angelos In message <6204FDDE129D364D8040A98BCCB290EF052203FD@zbl6c004.corpeast.baynetwo rks.com>, "Paul Knight" writes: >This message is in MIME format. Since your mail reader does not understand >this format, some or all of this message may not be legible. > >------_=_NextPart_001_01C2FF7E.221FB260 >Content-Type: text/plain > >Hi Steve and all, > >The draft (in the end of Section 2, below) appears to propose a new >requirement that remote access tunnel mode IPsec users MUST use an inner IP >address equivalent to their outer address (or else it reclassifies such >users as "security gateways"). This seems to directly contradict all the >work with DHCP over IKE and the entire Configuration Payload discussion, all >of which is based on assigning an inner tunnel address which can be a part >of a VPN address domain (i.e., different from the outer address). > >Am I missing something (besides my second cup of coffee)? > >Regards, >Paul Knight > >>From Section 2: > When operating in tunnel mode, the question of what to use as the > tunnel destination address (for the "outer" header) arises. We > distinguish three cases: where the end hosts are also the tunnel > endpoints; where neither host is a tunnel endpoint (the tunnel > endpoints are security gateways); and where only one of the hosts is > a tunnel endpoint (the usual case for the "road warrior" talking to > a security gateway). In the first case, the outer addresses MUST be > the same as the inner addresses of the tunnel. In the second case > (security gateways) there is no special processing; address > selection proceeds as it would for two distinct sets of end hosts. > In the third case, the "road warrior" uses the security gateway's > address as the tunnel destination address, and MUST use the same > source address as that of the inner packet. Symmetrically, the > security gateway uses its own address as the source address of the > tunnel, and MUST use the the same destination address in the outer > header as that of the inner packet. An implementation will probably > structure the code so that if, during SA setup, the inner and outer > address of either side is the same, rather than explicitly store the > corresponding address of the tunnel, it sets a flag that marks the SA > to use the same address in the tunnel header as in the inner header. > >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: Wednesday, April 09, 2003 7:18 AM >> To: IETF-Announce; @tislabs.com >> Cc: ipsec@lists.tislabs.com >> Subject: I-D ACTION:draft-ietf-ipsec-sctp-06.txt >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. This draft is a work item of the >> IP Security Protocol Working Group of the IETF. >> >> Title : On the Use of SCTP with IPsec >> Author(s) : S. Bellovin et al. >> Filename : draft-ietf-ipsec-sctp-06.txt >> Pages : 0 >> Date : 2003-4-8 >> >> This document describes functional requirements for IPsec >> [RFC2401] and IKE [RFC2409] to facilitate their use for >> securing SCTP [RFC2960] traffic. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sctp-06.t >xt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, type >"cd internet-drafts" and then > "get draft-ietf-ipsec-sctp-06.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-ipsec-sctp-06.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >------_=_NextPart_001_01C2FF7E.221FB260 >Content-Type: text/html >Content-Transfer-Encoding: quoted-printable > > > > >charset=3Dus-ascii"> >5.5.2656.31"> >RE: I-D ACTION:draft-ietf-ipsec-sctp-06.txt > > > >

Hi Steve and all, >

> >

The draft (in the end of Section 2, below) appears to = >propose a new requirement that remote access tunnel mode IPsec users = >MUST use an inner IP address equivalent to their outer address (or else = >it reclassifies such users as "security gateways").  = >This seems to directly contradict all the work with DHCP over IKE and = >the entire Configuration Payload discussion, all of which is based on = >assigning an inner tunnel address which can be a part of a VPN address = >domain (i.e., different from the outer address).

> >

Am I missing something (besides my second cup of = >coffee)? >

> >

Regards, >
Paul Knight >

> >

From Section 2: >
   When operating in tunnel mode, the = >question of what to use as the >
   tunnel destination address (for the = >"outer" header) arises.  We >
   distinguish three cases: where the end = >hosts are also the tunnel >
   endpoints; where neither host is a = >tunnel endpoint (the tunnel >
   endpoints are security gateways); and = >where only one of the hosts is >
   a tunnel endpoint (the usual case for = >the "road warrior" talking to >
   a security gateway).  In the first = >case, the outer addresses MUST be >
   the same as the inner addresses of the = >tunnel.  In the second case >
   (security gateways) there is no special = >processing; address >
   selection proceeds as it would for two = >distinct sets of end hosts. >
   In the third case, the "road = >warrior" uses the security gateway's >
   address as the tunnel destination = >address, and MUST use the same >
   source address as that of the inner = >packet.  Symmetrically, the >
   security gateway uses its own address = >as the source address of the >
   tunnel, and MUST use the the same = >destination address in the outer >
   header as that of the inner = >packet.  An implementation will probably >
   structure the code so that if, during = >SA setup, the inner and outer >
   address of either side is the same, = >rather than explicitly store the >
   corresponding address of the tunnel, it = >sets a flag that marks the SA >
   to use the same address in the tunnel = >header as in the inner header. >

> >

> -----Original Message----- >
> From: Internet-Drafts@ietf.org [HREF=3D"mailto:Internet-Drafts@ietf.org">mailto:Internet-Drafts@ietf.org= >] >
> Sent: Wednesday, April 09, 2003 7:18 AM >
> To: IETF-Announce; @tislabs.com >
> Cc: ipsec@lists.tislabs.com >
> Subject: I-D = >ACTION:draft-ietf-ipsec-sctp-06.txt >
> >
> >
> A New Internet-Draft is available from the = >on-line >
> Internet-Drafts directories. This draft is a = >work item of the >
> IP Security Protocol Working Group of the = >IETF. >
> >
>       = >Title           : On the = >Use of SCTP with IPsec >
>       = >Author(s)       : S. Bellovin et = >al. >
>       = >Filename        : = >draft-ietf-ipsec-sctp-06.txt >
>       = >Pages           : 0 >
>       = >Date            : = >2003-4-8 >
>       >
> This document describes functional requirements = >for IPsec >
> [RFC2401] and IKE [RFC2409] to facilitate their = >use for >
> securing SCTP [RFC2960] traffic. >
> >
> A URL for this Internet-Draft is: >
> HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sctp-06.t" = >TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-ipsec-s= >ctp-06.t >
xt >

> >

To remove yourself from the IETF Announcement list, = >send a message to >
ietf-announce-request with the word unsubscribe in = >the body of the message. >

> >

Internet-Drafts are also available by anonymous FTP. = >Login with the username "anonymous" and a password of your = >e-mail address. After logging in, type "cd internet-drafts" = >and then

> >

        "get = >draft-ietf-ipsec-sctp-06.txt". >

> >

A list of Internet-Drafts directories can be found in = >TARGET=3D"_blank">http://www.ietf.org/shadow.html >
or HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" = >TARGET=3D"_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt >

>
> >

Internet-Drafts can also be obtained by = >e-mail. >

> >

Send a message to: >
        SIZE=3D2>mailserv@ietf.org. >
In the body type: >
        SIZE=3D2>"FILE = >/internet-drafts/draft-ietf-ipsec-sctp-06.txt". >
       =20 >
NOTE:   The mail server at ietf.org can = >return the document in >
        SIZE=3D2>MIME-encoded form by using the "mpack" = >utility.  To use this >
        feature, = >insert the command "ENCODING mime" before the = >"FILE" >
        SIZE=3D2>command.  To decode the response(s), you will need = >"munpack" or >
        a = >MIME-compliant mail reader.  Different MIME-compliant mail = >readers >
        exhibit = >different behavior, especially when dealing with >
        SIZE=3D2>"multipart" MIME messages (i.e. documents which have = >been split >
        up into = >multiple messages), so check your local documentation on >
        how to = >manipulate these messages. >
        = >       =20 >
        = >       =20 >
Below is the data which will enable a MIME compliant = >mail reader implementation to automatically retrieve the ASCII version = >of the Internet-Draft.

> > > >------_=_NextPart_001_01C2FF7E.221FB260-- From owner-ipsec@lists.tislabs.com Tue Apr 15 11:53:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FIrEt2085257; Tue, 15 Apr 2003 11:53:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26921 Tue, 15 Apr 2003 14:20:14 -0400 (EDT) Message-ID: <6204FDDE129D364D8040A98BCCB290EF0538AB96@zbl6c004.corpeast.baynetworks.com> From: "Jing Xiang" To: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Cc: jxiang@nortelnetworks.com Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Date: Tue, 15 Apr 2003 11:54:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30367.4BBB3260" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C30367.4BBB3260 Content-Type: text/plain; charset="iso-8859-1" I would prefer that we stay with CP for its simplicity & performance. I don't have any technical arguments against DHCP. It's just I failed to see any added benefits for its complexity if all we are using is just an ip address configuration in most cases. /Jing Jing Xiang (jxiang@nortelnetworks) Nortel Networks Contivity Engineering (978)288-8985 -----Original Message----- From: Charlie_Kaufman@notesdev.ibm.com [mailto:Charlie_Kaufman@notesdev.ibm.com] Sent: Monday, April 14, 2003 9:02 PM To: ipsec@lists.tislabs.com Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Some comments on others' postings: "Theodore Ts'o" wrote: > We note that in San Francisco the wg had decided that in the > absence of strong support, the default would be to stay with the > existing text in the ikev2 document (Configuration Payload). I'm concerned that in the past such a statement has caused the people who agree with the current state to ignore the debate but energize those who disagree. People who care should speak up! "Scott G. Kelly" wrote: > I think Darren's summary is pretty accurate. It's kind of a toss up. > However, one difference that I note is that with the dhcp approach, all > client config is (potentially) done prior to the instantiation of the > child sa. I'm not sure if this is a benefit or not, but it might be. This will be a blessing in some circumstances and a curse in others. While doing client config early makes for a simpler boot rom, it means that a site must be willing to give out client config information to anonymous requestors (or else place additional requirements on ordering of authentication messages and state machines within IKE processing. In most scenarios, I wouldn't expect it to matter. Michael Thomas wrote: > I'm not entirely sure how impolitic this is wrt my > employer's hive mind, but the thing that really > tips my feeling about this is that DHCP-in-IKE > keeps the IPsec wg out of the business of dealing > with... configuration. That seems like a huge boon > in my mind from a wheel-reinvention standpoint. > > So, mark my preference as DHCP-in-IKE. There are two ways CP might evolve in the future. CP has a syntax clearly designed for extensibility, and hence is an "infection site" for architects who want to add configuration options in the future in one more different way. I find that prospect scary. But it doesn't have to happen. If our successors show restraint, they will not enhance CP to include information that could better be sent over DHCP. DHCP can be effectively tunnelled over ESP, and could (and should) be used for such extensions. The configuration step of allocating an IP address is special because it results in information necessary for configuring the ESP SA. It therefore can't be done over the ESP SA without significant kludgery (though someone did make it work with IKEv1). --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ------_=_NextPart_001_01C30367.4BBB3260 Content-Type: text/html; charset="iso-8859-1" RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload

I would prefer that we stay with CP for its simplicity & performance.

I don't have any technical arguments against DHCP. It's just I failed to see
any added benefits for its complexity if all we are using is just an ip address
configuration in most cases.


/Jing

Jing Xiang (jxiang@nortelnetworks)
Nortel Networks
Contivity Engineering
(978)288-8985

-----Original Message-----
From: Charlie_Kaufman@notesdev.ibm.com
[mailto:Charlie_Kaufman@notesdev.ibm.com]
Sent: Monday, April 14, 2003 9:02 PM
To: ipsec@lists.tislabs.com
Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload






Some comments on others' postings:

"Theodore Ts'o" <tytso@mit.edu> wrote:
> We note that in San Francisco the wg had decided that in the
> absence of strong support, the default would be to stay with the
> existing text in the ikev2 document (Configuration Payload).

I'm concerned that in the past such a statement has caused the
people who agree with the current state to ignore the debate but
energize those who disagree. People who care should speak up!

"Scott G. Kelly" <scott@airespace.com> wrote:
> I think Darren's summary is pretty accurate. It's kind of a toss up.
> However, one difference that I note is that with the dhcp approach, all
> client config is (potentially) done prior to the instantiation of the
> child sa. I'm not sure if this is a benefit or not, but it might be.

This will be a blessing in some circumstances and a curse in others.
While doing client config early makes for a simpler boot rom, it
means that a site must be willing to give out client config information
to anonymous requestors (or else place additional requirements on
ordering of authentication messages and state machines within IKE
processing. In most scenarios, I wouldn't expect it to matter.

Michael Thomas <mat@cisco.com> wrote:
> I'm not entirely sure how impolitic this is wrt my
> employer's hive mind, but the thing that really
> tips my feeling about this is that DHCP-in-IKE
> keeps the IPsec wg out of the business of dealing
> with... configuration. That seems like a huge boon
> in my mind from a wheel-reinvention standpoint.
>
> So, mark my preference as DHCP-in-IKE.

There are two ways CP might evolve in the future. CP has
a syntax clearly designed for extensibility, and hence is
an "infection site" for architects who want to add
configuration options in the future in one more
different way. I find that
prospect scary. But it doesn't have to happen. If our
successors show restraint, they will not enhance CP to
include information that could better be sent over DHCP.
DHCP can be effectively tunnelled over ESP, and could (and
should) be used for such extensions. The configuration step
of allocating an IP address is special because it results
in information necessary for configuring the ESP SA. It
therefore can't be done over the ESP SA without significant
kludgery (though someone did make it work with IKEv1).

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

------_=_NextPart_001_01C30367.4BBB3260-- From owner-ipsec@lists.tislabs.com Tue Apr 15 11:55:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FIt2t2085317; Tue, 15 Apr 2003 11:55:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26951 Tue, 15 Apr 2003 14:24:20 -0400 (EDT) Date: Tue, 15 Apr 2003 14:27:02 -0400 From: "Theodore Ts'o" To: Charlie_Kaufman@notesdev.ibm.com Cc: "Zimmerman, Mark" , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: Interoperability - Overlapping requests Message-ID: <20030415182702.GA13607@think> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Apr 14, 2003 at 09:35:21PM -0400, Charlie_Kaufman@notesdev.ibm.com wrote: > I agree it is confusing. I added "if the other endpoint has indicated > its ability to handle such requests" to the end of the first > sentence. Does that make it clear? To make things clearer, I suggest that in paragraph three of that section: An IKE endpoint MUST wait for a response to each of its messages before sending a subsequent message unless it has received a Notify message from its peer informing it that the peer is prepared to maintain state for multiple outstanding messages in order to allow greater throughput. You change it to read ... unless it has received a SET_WINDOW_SIZE Notify message... The explicit name of the notify message is not specified in section 2.3 at all, and while a reader can guess which notify message by skipping ahead to section 3.10.1 and reading through all of the possible notify message types, it's probably better to be explicit about things. - Ted From owner-ipsec@lists.tislabs.com Tue Apr 15 12:04:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FJ4Tt2085566; Tue, 15 Apr 2003 12:04:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27001 Tue, 15 Apr 2003 14:34:56 -0400 (EDT) Reply-To: From: "Darren Dukes" To: "Derek Atkins" , "Michael Richardson" Cc: Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Date: Tue, 15 Apr 2003 14:37:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Tero also argues that if you are using Radius with EAP, that > your round > > trip count is already larger than 4, so DHCP does not add to it. > > Yea, sure, but is that necessarily that "common case" when using IKE > Configuration? In other words, do we expect that IKE Configuration > will be used simultaneously with EAP the vast majority of the time? > Or do we think that it will be used just as often with other forms of > authentication, like RSA certs? > > On another note, can you even start the configuration process before > EAP finishes? I'm not convinced you can run it concurrently with EAP, > which implies that the extra messages from EAP and then DHCP would > have to be serialized, making the exchange even longer! I say this > because I don't see how a server can respond with a DHCPOFFER until > the client has authenticated (e.g. EAP finished). > > Am I missing something? Nope, you are correct. DHCP should be done after EAP, the same as CP is done after/with the last EAP message. I think implementations could get clever and block DHCPREQUESTs until after the client authenticates, but it seems simpler to require the client side to start the DHCP-over-IKE exchange after EAP completes and the client is authenticated. Darren > > -derek > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Tue Apr 15 15:09:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FM9Ht2095372; Tue, 15 Apr 2003 15:09:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27665 Tue, 15 Apr 2003 17:28:23 -0400 (EDT) X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16028.31210.863997.640532@tero.kivinen.iki.fi> Date: Wed, 16 Apr 2003 05:30:18 +0800 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: derek@ihtfp.com (Derek Atkins), Michael Richardson Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload X-Mailer: VM 7.04 under Emacs 20.7.1 X-Edit-Time: 13 min X-Total-Time: 13 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk derek@ihtfp.com (Derek Atkins) writes: > Sure, but it works in reverse, too -- the IKE Daemon on the security > gateway needs to be able to translate from whatever Foo-over-IKE we > choose to whatever actual configuration protocols are in use. So > what? It's no easier to implement a DHCP to RADIUS converter as it is > to implement a CP to RADIUS converter. It is harder to generate CP to DHCP converter, because some of the necessary information is not available in the CP. On the other hand if we do add all the information that DHCP have to the CP, then we have just duplicated the DHCP... > Similarly, are there actual DHCP libraries available? The ISC DHCP > software certainly doesn't install "libdhcp" anywhere on my system. > Are there other DHCP client libraries that are available, so IKE > implementors don't need to implement DHCP as well as IKE? The easy way to do is to create virtual interface and allow normal operating system to run dhcp over it. When those dhcp packets arrive to the ipsec processing engine it will cause trig to the usermode and usually it will also send the packet along to the usermode. Then the usermode IKE can take this dhcp packet and stuff it inside the IKE and send it forward. When the reply DHCP packet comes then the usermode IKE forwards those packets back to the tunnel and to the real dhcp client, which will then reply to them and again the engine will pass those to the usermode IKE to be sent inside the IKE. This kind of stealing all dhcp packets from the tunnel is needed anyway, thus using that to get the initial bootstrap dhcp packets is also very easy way to do. The actual implementation in the IPsec engine is very small (when dhcp packets are seen, send them to IKE, when IKE asks the engine to send packet to local tunnel send them to there). The implementation in the IKE is even simplier, simply take the dhcp packets coming from the engine and stuff them in the next IKE packet you are going to send, and if the other end send dhcp packet inside the IKE, then send them to local stack. Zero dhcp packet processing is needed there... :-) > > Tero also argues that if you are using Radius with EAP, that your round > > trip count is already larger than 4, so DHCP does not add to it. > Yea, sure, but is that necessarily that "common case" when using IKE > Configuration? In other words, do we expect that IKE Configuration > will be used simultaneously with EAP the vast majority of the time? Some people say that definately, some say that never... :-) I don't know. > On another note, can you even start the configuration process before > EAP finishes? With dhcp backend yes, and it can even finish before that. With radius backend, it depends. Some radius servers might give out the configuration information before the EAP finishes, some might. With internal backend yes or no depending on the policy. In case of real dhcp backend the gateway might want to release the lease if the client has already finished the dhcp, but then the EAP fails, or it might be so that dhcp server is using short enough leases that it does not matter if they are given out for some time even without real authentication. > I'm not convinced you can run it concurrently with EAP, > which implies that the extra messages from EAP and then DHCP would > have to be serialized, making the exchange even longer! In some radius servers that will happen. On the other hand you can configure the radius server to allow responding to the configuration requests before authentication if needed. > I say this > because I don't see how a server can respond with a DHCPOFFER until > the client has authenticated (e.g. EAP finished). As far as I understand radius then it can respond to configuration attributes at any packets, thus it can give the configuration attributes out when the first radius packet is done (i.e when the EAP starts). After that the sgw will know all configuration thus it can create the needed dhcp packets simultaneously to the EAP process. I do not know if any actual radius servers/clients can be configured to do so, but I would assume that they allow that kind of operation too. Ps. I will be on the vacation for about two weeks starting tomorrow, so I might not be able to reply to questions before that. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Apr 15 15:33:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FMXot2097042; Tue, 15 Apr 2003 15:33:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27745 Tue, 15 Apr 2003 17:58:16 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 15 Apr 2003 17:58:21 -0400 To: "Wang Haiguang" From: Stephen Kent Subject: Re: [rohc] FW: ESP and header compression (ROHC) Cc: , , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:30 AM +0800 4/15/03, Wang Haiguang wrote: >Hi, > >I have also considered this scheme before, that is, compress the header >behind the ESP before encryption and decompress it after decription in the >end-to-end scenario. > >What I am not clear is the effect of header compression to security. >If I am not wrong, the IPSec has add some padding bytes at the >end of the packet in order to hide the length of packet. > >If we compress the padding bytes, will it endanger the security of >the connection? > >Best regards. > >Haiguang I do not believe this is a concern. From owner-ipsec@lists.tislabs.com Tue Apr 15 15:44:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FMiCt2097375; Tue, 15 Apr 2003 15:44:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27771 Tue, 15 Apr 2003 18:07:32 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> References: <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> Date: Tue, 15 Apr 2003 18:07:46 -0400 To: David Mcgrew From: Stephen Kent Subject: Re: (in)security of ESP with header compression Cc: "Wang Haiguang" , , , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:29 AM -0700 4/15/03, David Mcgrew wrote: >Wang, > >length-hiding is an ESP option. If it is not used, then the traffic >protected by ESP might be more susceptible to traffic analysis. For >some applications, this is not a big deal. For example: no >adversary is going to be surprised that an IP telephone sends 50 >voice packets a second, nor would any adversary be fooled by the >padding. To my mind, length-hiding is probably incompatible with >header compression, though I don't see any security issues that >would result from using them in conjunction. > >There are other security issues, though. The fact that the header >compression is stateful (i.e., the decompression of a packet depends >on the packets that have been received before) means that an >adversary can force the receiver into decompressing incorrectly by >re-ordering packets. The use of message authentication and replay >protection doesn't stop this attack. ESP was designed to be >tolerant of packet reorder, so using it with a stateful decompressor >is problematic. > >There are two ways out of this bind: use a decompressor that won't >cause any security failures due to reorder (which requires lots of >careful analysis), or authenticate the message *before* it is >compressed, rather than after it is compressed (which requires some >encapsulation other than ESP). Jan Vilhuber and I have been working >on both of these approaches. If there is interest, we could bring >this work to the IETF, though I'm not sure that WG would be >appropriate. > >David David, If we provide support for ROHC within ESP, then for outbound processing, the security checks (matching against the traffic selectors) have to be performed prior to compression. This is a natural order of processing, since one must match against the selectors in order to select the right SA, and then determine that the SA in question calls for compression. At the receiver, similar checks must be performed on the received packet, after decompression. But, these checks are performed after authentication anyway, so this constraint does not impose an ordering requirement on authentication vs. decompression. If we stick with the IPCOMP model, as Charlie proposed, then authentication would occur first, then decompression, and I think that is a reasonable ordering approach, which also addresses the concerns you cite above. The big question for IPsec is whether ROHC can it be considered an IPCOMP instance and thus fit within the existing framework. Steve From owner-ipsec@lists.tislabs.com Tue Apr 15 16:09:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FN9bt2098048; Tue, 15 Apr 2003 16:09:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27901 Tue, 15 Apr 2003 18:36:22 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200304142154.h3ELslw2009295@burp.tkv.asdf.org> References: <200304141936.h3EJaoI3008229@burp.tkv.asdf.org> <200304142154.h3ELslw2009295@burp.tkv.asdf.org> Date: Tue, 15 Apr 2003 18:33:33 -0400 To: Markku Savela From: Stephen Kent Subject: Re: Question on SA Bundle Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:54 AM +0300 4/15/03, Markku Savela wrote: > > From: Stephen Kent > >> BUT the WG will have to decide if the added complexity is something >> we want to impose on all IPsec implementations. > >This exactly why I want to separate policy from IKE. Policy syntax and >features would be just local implementation choice. This is then >mapped into standard "SA+TS" construct. IKE should operate with >this, without knowing anything about the original policy. > >> For example, in v2 the initiator sends SPD selector data showing the >> range of values associated with an SA that is being created, to >> enable the peer to know the range of traffic that can be carried on >> the SA. > >I want the same, except that what is sent over is NOT the SPD selector >data, but something that is extracted from the packet triggering the >negotiation. I think we have "terminology problem". An example, I can >have a policy > > "protocol = tcp" -> "use different SA-pair for each connection" > >In my terminology, from above it follows: > > SPD selector: "protocol = tcp" > > TS for SA: protocol=tcp, src_port=x, dst=port=y > >My claim is just: IKE does not need the "SPD selector". It just needs >the "TS for SA" -part. And, that it should just negotiate this single >unidiretional SA, and let the other end trigger negotiation of the >other SA of the pair. > >I think, TS as defined in IKEv2 is fine. Just don't equate it with SPD >policy selector. If one just sends over data from the packet that triggers creation of an SA, the responder does not know what range of traffic can be sent over the newly created SA. Only if both peers have identical SPD entries for the packet in question would this be sufficient. Otherwise, the responder, not knowing the initiator's policy, might either create unnecessary SAs for other traffic he wanst to send, (which is a waste of resources) or the responder may send traffic over the SA that will be rejected by the initiator (which causes trouble shooting problems, another form of wasted resources). By sending over the SPD data relevant to the SA being created, the initiator avoids these problems. In the past, we insisted on perfectly matched SPD entries for SAs, and I am told that it creates lots of config management problems. So, the goal going forward is to allow communication to occur when there is an overlap in the acceptable traffic relative to a proposal, and to communicate that in the IKE exchange. This will alleviate some config management problems and yet not create any problems with the two forms of resource waste noted above. I guess I don't really understand your motivation for not having IKE convey the policy info from the SPDs to avoid future problems. Do you envision other ways to convey this data, or do you not believe that it is worthwhile to avoid the sort of problems noted above? Steve From owner-ipsec@lists.tislabs.com Tue Apr 15 16:16:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FNGpt2098351; Tue, 15 Apr 2003 16:16:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27946 Tue, 15 Apr 2003 18:45:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20030411192548.GC30438@think> References: <20030411192548.GC30438@think> Date: Tue, 15 Apr 2003 18:51:02 -0400 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: Confirm decision on identity handling. Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:25 PM -0400 4/11/03, Theodore Ts'o wrote: >On Wed, Apr 09, 2003 at 05:53:10PM -0700, Paul Hoffman / VPNC wrote: >> >> We are better off with just the first sentence and a revision of the >> one proposed here by Ted: >> >> The Identification Payload, denoted ID in this memo, allows peers to >> assert an identify to one another. This identity may be used for policy >> lookup, but does not necessarily have to match anything in the CERT >> payload; both fields may be used by an implementation to perform >> access control decisions. > >Paul's proposed revision seems clearer and reflects the discussion in >San Francisco. Does anybody have any problems with this text, or >should we just go with it? > > - Ted I do have a problem with the proposed text. If we leave the interpretation of this payload as a local matter, then we have not basis for predictable interoperability, other than the trivial case that Paul describes as what "sensible" implementations will do, which is to ignore the payload value. If we believe there is a use for the payload, the we need to nail down how to use it. I am sensitive to the arguments that Paul made in SF about how hard it is today to decide how to match cert data against this field. I trust his characterization of the difficult of the problem. But, that just says that we failed to do the job the first time around (in IKE v1 and in 2401) and as a result we have a mess. If we adopt the language Paul has proposed, we perpetuate the problem. Is it fair to say that the problem here is that we are in a hurry to get IKE done, resolution of this issue will take some time and effort, and nobody has volunteered to address the problem in a timely fashion? Steve From owner-ipsec@lists.tislabs.com Tue Apr 15 16:31:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FNVot2098798; Tue, 15 Apr 2003 16:31:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28029 Tue, 15 Apr 2003 19:01:18 -0400 (EDT) X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16028.36898.778373.788474@tero.kivinen.iki.fi> Date: Wed, 16 Apr 2003 07:05:06 +0800 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Subject: Re: peer address protection References: <200304101719.h3AHJnof054361@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.04 under Emacs 20.7.1 X-Edit-Time: 14 min X-Total-Time: 15 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis.Dupont@enst-bretagne.fr (Francis Dupont) writes: > The peer addresses are not protected in IKEv2 and are not clearly > protected in IKEv1 (in fact many implementations loosely bind them > to the ID or to a CERT subject name so attacks work only in the > road warrior case which of course conflicts...). I do not think there is any need to protect them in IKEv2. > - Fourth/last case: no NAT is detected: IKE and IPsec SAs SHOULD be > run over UDP port 500 and peer addresses MUST be protected using > PEER_ADDRESS_SOURCE and PEER_ADDRESS_DESTINATION notifications > included in the encrypted payload of all messages. If we do not have NAT between (meaning that NAT-T is disabled), then this also means that the host changing ip address will know when it does so (it is mobile node, which gets new ip address or it is multihoming device which decides to use another interface for the traffic). This means that to update any of the IPsec or IKE SA peer addresses, it MUST send the SOURCE-ADDRESS-CHANGED notification telling that this will be its new source IP address/port. It SHOULD do this immediately when it can receive from the new address/port, and I think it MAY send it from the old address/port. This notification will tell the new source IP address and port. If some attacker will modify some IP header source address or port of the IKE packet that does not affect anything else, than that the responce is sent back to this modified address. It does not affect to the future packets sent in the IKE SA nor does it change the tunnel endpoint addresses used for the IPSec SAs. The future IKE packets still use the same official IKE SA IP address, which was used in the beginning, or which was changed using SOURCE-ADDRESS-CHANGED notification. For the tunnel endpoints the IKE will also use the same official IKE SA IP address, thus even if the packet seemed to come from different address the tunnel endpoint address is taken from the IP address associated with the IKE SA. Only way to change this IP address associated with the IKE SA is to use SOURCE-ADDRESS-CHANGED (this whole discussion is discussing case where we do NOT have NAT, i.e when the NAT-T is not enabled). I.e only thing attacker can gain by modifying the source address is to get one reply packet to be sent to wrong address. This not really a attack, as he could have sent the packet directly there (i.e it is one extra packet to wrong address per one modified packet). I do not thing we need PEER_ADDRESS_SOURCE, PEER_ADDRESS_DESTINATION or PEER_ADDRESS_ALERT notifications. The SOURCE-ADDRESS-CHANGED is the only thing we need. I cannot see any pseudo NAT attack that will work with this protocol. If you can see something, can you explain it to mee (with exact packet examples, please). Ps. I will be on the vacation for about two weeks starting tomorrow, so I might not be able to read replies before that. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Apr 15 16:36:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FNavt2098955; Tue, 15 Apr 2003 16:36:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28057 Tue, 15 Apr 2003 19:07:29 -0400 (EDT) X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16028.37193.164975.747768@tero.kivinen.iki.fi> Date: Wed, 16 Apr 2003 07:10:01 +0800 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: Francis.Dupont@enst-bretagne.fr Subject: Re: peer address update payload References: <200304111516.h3BFGmof058143@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.04 under Emacs 20.7.1 X-Edit-Time: 5 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis.Dupont@enst-bretagne.fr (Francis Dupont) writes: > Here is a proposal for the peer address update payload if > we decide to include it in the next IKEv2 draft. The modifs > are: I am still not sure we need to have the ability to have different IP address per each CHILD SA of the IKE SA. I think we should simply say that if you want to modify the IP addresses of the CHILD SAs independently then create them using separate IKE SAs. If you happen to have all of the CHILD SAs created by one IKE SA and you want to split them to two different classes, create another IKE SA and recreate those CHILD SAs you want to move inside this new IKE SA and delete them from the old IKE SA. Or you can create each CHILD SA with separate IKE SA. I think it is simplier, and offeres same features than peer address update payload. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Apr 16 07:05:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GE50t2060460; Wed, 16 Apr 2003 07:05:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00722 Wed, 16 Apr 2003 09:38:41 -0400 (EDT) Message-Id: <200304161221.IAA26971@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-dhcp-over-ike-dhcpd-00.txt Date: Wed, 16 Apr 2003 08:21:44 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Using DHCP server/client backend for DHCP over IKE Author(s) : T. Kivinen Filename : draft-ietf-ipsec-dhcp-over-ike-dhcpd-00.txt Pages : 5 Date : 2003-4-15 This document describes method of using dynamic host configuration pro- tocol (DHCP) as a backend for the internet key exchange (IKE) version 2 host configuration protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-over-ike-dhcpd-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-dhcp-over-ike-dhcpd-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-dhcp-over-ike-dhcpd-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-16083648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-over-ike-dhcpd-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhcp-over-ike-dhcpd-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-16083648.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Apr 16 07:05:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GE5ut2060491; Wed, 16 Apr 2003 07:05:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00701 Wed, 16 Apr 2003 09:35:40 -0400 (EDT) Message-Id: <200304161221.IAA26987@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-dhcp-over-ike-radius-00.txt Date: Wed, 16 Apr 2003 08:21:50 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Using RADIUS backend for DHCP over IKE Author(s) : T. Kivinen Filename : draft-ietf-ipsec-dhcp-over-ike-radius-00.txt Pages : 4 Date : 2003-4-15 This document describes method of using Remote Authentication Dial In User Service (RADIUS) as a backend for the internet key exchange (IKE) version 2 host configuration protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-over-ike-radius-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-dhcp-over-ike-radius-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-dhcp-over-ike-radius-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-16083658.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-over-ike-radius-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhcp-over-ike-radius-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-16083658.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Apr 16 07:06:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GE63t2060502; Wed, 16 Apr 2003 07:06:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00661 Wed, 16 Apr 2003 09:27:35 -0400 (EDT) Message-Id: <200304161221.IAA26939@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-monitor-mib-04.txt Date: Wed, 16 Apr 2003 08:21:36 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Key Exchange (IKE) Monitoring MIB Author(s) : P. Hoffman Filename : draft-ietf-ipsec-ike-monitor-mib-04.txt Pages : 75 Date : 2003-4-15 This document defines monitoring and status MIBs for use when the (Internet Key Exchange) IKE protocol [IKE] is used to create IPsec security associations (SAs). As such, the MIBs provide the linkage between IKE (phase 1) SAs and the IPsec (phase 2) SAs created by those SAs. It does not define MIBs that may be used for configuring IPsec implementations or for providing low-level diagnostic or debugging information. It assumes no specific use of IPsec SAs, except that they were created using IKE. Further, it does not provide policy information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-monitor-mib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ike-monitor-mib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-monitor-mib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-16083613.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-monitor-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-monitor-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-16083613.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Apr 16 07:06:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GE6Lt2060515; Wed, 16 Apr 2003 07:06:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00708 Wed, 16 Apr 2003 09:36:41 -0400 (EDT) Message-Id: <200304161221.IAA26921@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-dhcp-over-ike-00.txt Date: Wed, 16 Apr 2003 08:21:31 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : DHCP over IKE Author(s) : T. Kivinen Filename : draft-ietf-ipsec-dhcp-over-ike-00.txt Pages : 13 Date : 2003-4-15 This document describes method of getting the IP security (IPsec) remote access client configuration information from the security gateway by tunneling dynamic host configuration protocol (DHCP) packets inside the internet key exchange (IKE) version 2 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-over-ike-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-dhcp-over-ike-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-dhcp-over-ike-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-16083603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-over-ike-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhcp-over-ike-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-16083603.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Apr 16 07:06:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GE6St2060528; Wed, 16 Apr 2003 07:06:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00667 Wed, 16 Apr 2003 09:28:36 -0400 (EDT) Message-Id: <200304161221.IAA26955@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-di-mon-mib-05.txt Date: Wed, 16 Apr 2003 08:21:40 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : ISAKMP DOI-Independent Monitoring MIB Author(s) : P. Hoffman Filename : draft-ietf-ipsec-isakmp-di-mon-mib-05.txt Pages : 27 Date : 2003-4-15 This document defines a DOI (domain of interpretation) independent monitoring MIB for ISAKMP. The purpose of this MIB is to be used as the basis for protocol specific MIBs that use ISAKMP as the basis for key exchanges or security association negotiation. As such, it has no DOI-dependent objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-di-mon-mib-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-di-mon-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-di-mon-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-16083634.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-di-mon-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-di-mon-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-16083634.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Apr 16 07:08:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GE8St2060590; Wed, 16 Apr 2003 07:08:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00738 Wed, 16 Apr 2003 09:39:41 -0400 (EDT) Message-Id: <200304161222.IAA27068@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-monitor-mib-06.txt Date: Wed, 16 Apr 2003 08:22:17 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPSec Monitoring MIB Author(s) : P. Hoffman Filename : draft-ietf-ipsec-monitor-mib-06.txt Pages : 77 Date : 2003-4-15 This document defines low level monitoring and status MIBs for IPsec security associations (SAs). It does not define MIBs that may be used for configuring IPsec implementations or for providing low-level diagnostic or debugging information. It assumes no specific use of IPsec. Further, it does not provide policy information. The purpose of the MIBs is to allow system administrators to determine operating conditions and perform system operational level monitoring of the IPsec portion of their network. Statistics are provided as well. Additionally, it may be used as the basis for application specific MIBs for specific uses of IPsec SAs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-monitor-mib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-monitor-mib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-monitor-mib-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-16083624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-monitor-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-monitor-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-16083624.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Apr 16 08:32:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GFWSt2064877; Wed, 16 Apr 2003 08:32:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01177 Wed, 16 Apr 2003 11:00:45 -0400 (EDT) Message-Id: <4.3.2.7.2.20030416070333.00b30688@mira-sjcm-1.cisco.com> X-Sender: mcgrew@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Apr 2003 08:04:25 -0700 To: Stephen Kent From: David Mcgrew Subject: Re: (in)security of ESP with header compression Cc: "Wang Haiguang" , , , , In-Reply-To: References: <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, At 06:07 PM 4/15/2003 -0400, Stephen Kent wrote: >At 6:29 AM -0700 4/15/03, David Mcgrew wrote: >>Wang, >> >>length-hiding is an ESP option. If it is not used, then the traffic >>protected by ESP might be more susceptible to traffic analysis. For some >>applications, this is not a big deal. For example: no adversary is going >>to be surprised that an IP telephone sends 50 voice packets a second, nor >>would any adversary be fooled by the padding. To my mind, length-hiding >>is probably incompatible with header compression, though I don't see any >>security issues that would result from using them in conjunction. >> >>There are other security issues, though. The fact that the header >>compression is stateful (i.e., the decompression of a packet depends on >>the packets that have been received before) means that an adversary can >>force the receiver into decompressing incorrectly by >>re-ordering packets. The use of message authentication and replay >>protection doesn't stop this attack. ESP was designed to be tolerant of >>packet reorder, so using it with a stateful decompressor is problematic. >> >>There are two ways out of this bind: use a decompressor that won't cause >>any security failures due to reorder (which requires lots of careful >>analysis), or authenticate the message *before* it is compressed, rather >>than after it is compressed (which requires some encapsulation other than >>ESP). Jan Vilhuber and I have been working on both of these >>approaches. If there is interest, we could bring this work to the IETF, >>though I'm not sure that WG would be appropriate. >> >>David > >David, > >If we provide support for ROHC within ESP, then for outbound processing, >the security checks (matching against the traffic selectors) have to be >performed prior to compression. This is a natural order of processing, >since one must match against the selectors in order to select the right >SA, and then determine that the SA in question calls for compression. agreed. >At the receiver, similar checks must be performed on the received packet, >after decompression. But, these checks are performed after authentication >anyway, so this constraint does not impose an ordering requirement on >authentication vs. decompression. > >If we stick with the IPCOMP model, as Charlie proposed, then >authentication would occur first, then decompression, and I think that is >a reasonable ordering approach, which also addresses the concerns you cite >above. No, the IPCOMP model doesn't solve the problem, I fear that I've not been clear enough when I said 'authenticate before compression'. The use of a compression algorithm that maintains state between packets is a potential security problem because the reordering of packets can confuse the state machine in the decompressor. Since it's a design goal of ESP to tolerate packet reorder, there is nothing stopping an attacker from reordering packets in order to confuse the receiver. One way to thwart this attack is to apply the message authentication to the uncompressed data, rather than the compressed data. So the processing on the sender would be authenticate/compress/encrypt, while on the receiver it would be decrypt/decompress/authenticate. Since the receiver performs the authentication check after the decompression, this check catches decompression errors. This point is what I'd meant by 'auth before comp'. >The big question for IPsec is whether ROHC can it be considered an IPCOMP >instance and thus fit within the existing framework. The IPCOMP spec is only intended for stateless compression algorithms. It doesn't say if this is because of the security issue due to packet reorder or not; this might just be an assumption of the authors. Another point about IPCOMP is that it would be useful in exactly the same situations that header compression would be useful. It is probably desirable to allow the use of both mechanisms simultaneously. I am not sure if IPCOMP allows multiple compression methods, but I suspect that it does not. IPHC is also of interest as well, though I don't think that it raises any issues that ROHC doesn't. David >Steve From owner-ipsec@lists.tislabs.com Wed Apr 16 10:33:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GHXZt2070182; Wed, 16 Apr 2003 10:33:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01576 Wed, 16 Apr 2003 12:59:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <4.3.2.7.2.20030416070333.00b30688@mira-sjcm-1.cisco.com> References: <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> <4.3.2.7.2.20030416070333.00b30688@mira-sjcm-1.cisco.com> Date: Wed, 16 Apr 2003 12:56:37 -0400 To: David Mcgrew From: Stephen Kent Subject: Re: (in)security of ESP with header compression Cc: "Wang Haiguang" , , , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David, The ESP processing order at the receiver is authenticate then decrypt, IF there are separate authentication and encryption algorithms employed, i.e., the common case today. The structure of the payload requires this, since the integrity check is applied to the ciphertext, not the plaintext, by the sender. That says that the transmitter processing order is: - map to SA (the outbound access control check) - compress if appropriate - encrypt - integrity check At the receiver the processing is defined as: - map to SA using SPI ( a demuxing operation, not a security check) - validate sequence number - integrity check - decrypt - decompress if appropriate - check against selectors (the inbound access control check) Sorry for any confusion re my previous response in not spelling out all the steps and why they are performed in the order indicated. Given this ordering of processing steps, it would seem that the main issue for a stateful compression algorithm like ROHC is to be smart about reacting to out of order arrival, a fact of life if it is to be used in the IPsec context. Steve From owner-ipsec@lists.tislabs.com Wed Apr 16 10:56:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GHu0t2070655; Wed, 16 Apr 2003 10:56:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01654 Wed, 16 Apr 2003 13:23:17 -0400 (EDT) To: David Mcgrew Cc: Stephen Kent , "Wang Haiguang" , , , , From: Derek Atkins Subject: Re: (in)security of ESP with header compression References: <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> <4.3.2.7.2.20030416070333.00b30688@mira-sjcm-1.cisco.com> Date: 16 Apr 2003 13:21:06 -0400 In-Reply-To: <4.3.2.7.2.20030416070333.00b30688@mira-sjcm-1.cisco.com> Message-ID: Lines: 38 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David Mcgrew writes: > > The big question for IPsec is whether ROHC can it be considered an > > IPCOMP instance and thus fit within the existing framework. > > The IPCOMP spec is only intended for stateless compression algorithms. > It doesn't say if this is because of the security issue due to packet > reorder or not; this might just be an assumption of the authors. It depends on your definition of "stateless." I believe that you can have "state" (just like you require cryptographic "state" in order to process ESP or AH). However, the key is that there is no inter-packet state. That requirements stems from 2401 (IIRC), due to the IPsec architecture treating each packet individually. So, I don't see why IPCOMP should be any different than ESP or AH in terms of packet independence. If ROHC is truly dependent on packet ordering, then I think this is a bug in ROHC and needs to be addressed there. It certainly limits the types of links in which ROHC can be used. > Another point about IPCOMP is that it would be useful in exactly the > same situations that header compression would be useful. It is > probably desirable to allow the use of both mechanisms simultaneously. > I am not sure if IPCOMP allows multiple compression methods, but I > suspect that it does not. > > IPHC is also of interest as well, though I don't think that it raises > any issues that ROHC doesn't. > > David -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Wed Apr 16 12:20:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GJKEt2072741; Wed, 16 Apr 2003 12:20:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02091 Wed, 16 Apr 2003 14:41:56 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 16 Apr 2003 11:46:21 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ipsec@lists.tislabs.com cc: Paul Hoffman / VPNC Subject: Re: I-D ACTION:draft-ietf-ipsec-ike-monitor-mib-04.txt In-Reply-To: <200304161221.IAA26939@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 16 Apr 2003 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the IP > Security Protocol Working Group of the IETF. > > Title : Internet Key Exchange (IKE) Monitoring MIB > Author(s) : P. Hoffman > Filename : draft-ietf-ipsec-ike-monitor-mib-04.txt > Pages : 75 > Date : 2003-4-15 I noticed several formatting problems in this document when comparing it to the previous version. Specifically, it seems that in a lot of the places where the old page headers and footers were removed the adjacent lines got merged together. For example: ! 1 IKE SA. ! ! ! Jenkins & Shriver [Page 11] ! ^L ! Internet Draft IKE Monitoring MIB October 3, 2001 ! ! ! This table augments the phase 1 security associations table (but ! again, not using the AUGMENTS clause of SNMP). --- 474,475 ---- ! 1 IKE SA. This table augments the phase 1 security associations table ! (but again, not using the AUGMENTS clause of SNMP). and: ! MAX-ACCESS not-accessible ! ! ! Jenkins & Shriver [Page 20] ! ^L ! Internet Draft IKE Monitoring MIB October 3, 2001 ! ! ! STATUS current --- 890 ---- ! MAX-ACCESS not-accessible STATUS current There was a lot of stuff like the last example. I would suggest that this probably needs to be fixed before submission to a MIB reviewer, and certainly before publication. The other MIB module drafts didn't seem to suffer from this problem. Some other comments apply equally to this draft and the companion documents draft-ietf-ipsec-isakmp-di-mon-mib-05.txt and draft-ietf-ipsec-monitor-mib-06.txt: - The MIB boilerplate and SNMP-related references are out of date. See http://www.ops.ietf.org/mib-boilerplate.html for current stuff. - The Security Considerations section should probably be brought into line with http://www.ops.ietf.org/mib-security.html (the basic content is probably OK but some of the "boilerplate" stuff is out of date) - Please import mib-2 from SNMPv2-SMI and not RFC1213-MIB. - MIB module revision clauses are only supposed to document versions that are published as RFCs. See section 4.5 of (in fact doing a general review to see if these MIB modules conform to those guidelines can save you and the MIB reviewer a lot of time). - It seems a little odd to me that the documents which define the protocols that are being instrumented by these MIB modules are listed as non-normative references. I would think that a MIB module implementor would need to be familiar with those documents in order to correctly implement the managed objects. If that's true, then they should be normative references. //cmh From owner-ipsec@lists.tislabs.com Wed Apr 16 12:53:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GJrpt2073726; Wed, 16 Apr 2003 12:53:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02264 Wed, 16 Apr 2003 15:26:52 -0400 (EDT) X-Originating-IP: [64.114.95.129] X-Originating-Email: [askrywan@hotmail.com] From: "Andrew Krywaniuk" To: ipsec@lists.tislabs.com, kivinen@ssh.fi Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Date: Wed, 16 Apr 2003 13:28:04 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Apr 2003 17:28:04.0826 (UTC) FILETIME=[89D1F3A0:01C3043D] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >In some radius servers that will happen. On the other hand you can >configure the radius server to allow responding to the configuration >requests before authentication if needed. There's some danger involved in having the IKE daemon blindly forward DHCP packets from the peer onto the protected network, particularly if the DHCP happens *before* the user is authenticated. If there is a known exploit on the DHCP server then the DHCP packet could install a trojan. Also, the DHCP forwarding policy creates an extra channel for a pre-existing trojan on the protected network to communicate with arbitrary peers (not that there's likely to be any shortage of those). Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ From owner-ipsec@lists.tislabs.com Wed Apr 16 13:33:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GKXkt2074972; Wed, 16 Apr 2003 13:33:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02339 Wed, 16 Apr 2003 15:57:39 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 16 Apr 2003 13:01:35 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: IPsec WG cc: "Wijnen, Bert (Bert)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ authors of draft-ietf-ipsp-ipsec-conf-mib-06.txt bcc'd; ] [ please direct all discussion to ipsec@lists.tislabs.com ] Summary of the discussion so far: I have pointed out to the WG that all of the enumerated INTEGER TCs in the IPSEC-ISAKMP-IKE-DOI-TC MIB module in (except for IsakmpCertificateEncoding) are intended to represent data items that have a certain range of values reserved for "private use amongst cooperating systems." Since values in these ranges are not subject to standardization, there will be no enumerations for them. However, SMIv2 rules require (and MIB users/authors expect) that objects defined with an enumerated INTEGER syntax will assume only those values that are named in the enumeration list. I have therefore advised the WG (in my role as MIB reviewer) that the SYNTAX value of all of the enumerated INTEGER TCs in the IPSEC-ISAKMP-IKE-DOI-TC MIB module be changed to the appropriate Unsigned32 subrange with the usages of the various ranges spelled out in the DESCRIPTION clause (as is done now) and a pointer to the IANA registry included. This approach, which is the also used in the SnmpSecurityModel TC from the SNMP-FRAMEWORK-MIB in RFC 3411, has the added advantage of not imposing any extra workload on the IANA to supplement or reorganize the existing IPsec and ISAKMP registries. The disadvantage of this approach is that applications such as MIB browsers that don't have any built-in knowledge of the underlying MIB objects can only display the integer value and not the enumeration label, which makes the MIB modules harder to use. This discussion has been dormant for about a week, and I do need to proceed with finalization of my MIB review comments for the ADs. So unless I hear some very convincing arguments to the contrary before Tuesday, 22 April 2003, my review comments will advise that all the enumerated INTEGER TCs in the IPSEC-ISAKMP-IKE-DOI-TC have the SYNTAX value changed to the appropriate Unsigned32 subrange, and that the MIB module be maintained by the WG, not by IANA. I am aware of the following Internet Drafts that contain MIB modules which use one or more of the TCs defined in IPSEC-ISAKMP-IKE-DOI-TC: draft-ietf-ipsec-ike-monitor-mib-04.txt draft-ietf-ipsec-isakmp-di-mon-mib-05.txt draft-ietf-ipsec-monitor-mib-06.txt draft-ietf-ipsp-ipsec-conf-mib-06.txt Of these, it appears that only the last one would be affected by the changes I intend to recommend. It would be necessary to change the object definition ipspSaPreActActionType OBJECT-TYPE SYNTAX IpsecDoiEncapsulationMode MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the encapsulation mode to use for the preconfigured SA: tunnel or transport mode." DEFVAL { tunnel } ::= { ipspSaPreconfiguredActionEntry 9 } to ipspSaPreActActionType OBJECT-TYPE SYNTAX IpsecDoiEncapsulationMode MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the encapsulation mode to use for the preconfigured SA: tunnel or transport mode." DEFVAL { 1 } -- tunnel ::= { ipspSaPreconfiguredActionEntry 9 } Regards, Mike Heard From owner-ipsec@lists.tislabs.com Wed Apr 16 13:38:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GKcFt2075111; Wed, 16 Apr 2003 13:38:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02401 Wed, 16 Apr 2003 16:05:55 -0400 (EDT) Message-Id: <4.3.2.7.2.20030416121454.00b74328@mira-sjcm-1.cisco.com> X-Sender: mcgrew@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Apr 2003 13:08:40 -0700 To: Derek Atkins From: David Mcgrew Subject: Re: (in)security of ESP with header compression Cc: Stephen Kent , "Wang Haiguang" , , , , In-Reply-To: References: <4.3.2.7.2.20030416070333.00b30688@mira-sjcm-1.cisco.com> <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> <4.3.2.7.2.20030416070333.00b30688@mira-sjcm-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, At 01:21 PM 4/16/2003 -0400, Derek Atkins wrote: >David Mcgrew writes: > > > > The big question for IPsec is whether ROHC can it be considered an > > > IPCOMP instance and thus fit within the existing framework. > > > > The IPCOMP spec is only intended for stateless compression algorithms. > > It doesn't say if this is because of the security issue due to packet > > reorder or not; this might just be an assumption of the authors. > >It depends on your definition of "stateless." I believe that you can >have "state" (just like you require cryptographic "state" in order to >process ESP or AH). However, the key is that there is no inter-packet >state. That requirements stems from 2401 (IIRC), due to the IPsec >architecture treating each packet individually. That makes sense. For the record, the IPCOMP definition concerns inter-packet state, it says that "each IP datagram is compressed and decompressed by itself without any relation to other datagrams". >So, I don't see why IPCOMP should be any different than ESP or AH in >terms of packet independence. If ROHC is truly dependent on packet >ordering, then I think this is a bug in ROHC and needs to be addressed >there. It certainly limits the types of links in which ROHC can be >used. IPHC and ROHC were designed with links in mind, but there is now interest in adapting them for use at the internetwork layer. The AVT WG enhanced compressed RTP is one of these efforts. I think that there's similar interest in ROHC WG, though I am less familiar with that work and should let someone from that group comment. I don't think that it's a bug that the compression methods assume a reliable link, since compression is much easier when you can make that assumption. But certainly a more robust compression scheme would be more generally useful. thanks, David > > Another point about IPCOMP is that it would be useful in exactly the > > same situations that header compression would be useful. It is > > probably desirable to allow the use of both mechanisms simultaneously. > > I am not sure if IPCOMP allows multiple compression methods, but I > > suspect that it does not. > > > > IPHC is also of interest as well, though I don't think that it raises > > any issues that ROHC doesn't. > > > > David > >-derek > >-- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Wed Apr 16 14:08:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GL8ut2076264; Wed, 16 Apr 2003 14:08:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02497 Wed, 16 Apr 2003 16:36:39 -0400 (EDT) Date: Wed, 16 Apr 2003 16:39:38 -0400 (EDT) From: Henry Spencer To: IP Security List cc: rohc@ietf.org Subject: Re: (in)security of ESP with header compression In-Reply-To: <4.3.2.7.2.20030416121454.00b74328@mira-sjcm-1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 16 Apr 2003, David Mcgrew wrote: > >...[IPComp] the key is that there is no inter-packet state... > > That makes sense. For the record, the IPCOMP definition concerns > inter-packet state, it says that "each IP datagram is compressed and > decompressed by itself without any relation to other datagrams". And in fact, a careful reading of the specification tells you that this is a bit mis-stated: compression implementations are not just permitted but encouraged to keep inter-packet state, e.g. to decide whether it is worth trying to compress the next packet. It's *decompression*, and only decompression, which must not keep inter-packet state. (And that is both necessary and sufficient to make IPComp robust against loss or reordering of packets.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Apr 16 14:16:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GLGDt2076826; Wed, 16 Apr 2003 14:16:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02508 Wed, 16 Apr 2003 16:38:42 -0400 (EDT) Date: Wed, 16 Apr 2003 23:42:59 +0300 Message-Id: <200304162042.h3GKgxSm031065@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com CC: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Tue, 15 Apr 2003 18:33:33 -0400) Subject: Re: Question on SA Bundle References: <200304141936.h3EJaoI3008229@burp.tkv.asdf.org> <200304142154.h3ELslw2009295@burp.tkv.asdf.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Stephen Kent > > I guess I don't really understand your motivation for not having IKE > convey the policy info from the SPDs to avoid future problems. Do you > envision other ways to convey this data, or do you not believe that > it is worthwhile to avoid the sort of problems noted above? The current IPSEC/IKE architecture seems to be something like +-------------------------+ | TCP/IP Stack + | | IPSEC processing | | ^ (AH/ESP/RFC-2401) | +---|----------|----------+ | | Key API | | Policy ---> IKE I believe the "Policy --> IKE" link should not be there (not for PHASE2 SA's at least). For IKE all that is needed, is KEY API. This would be simpler architeru, with clean interfaces between modulesK: +-------------------------+ | TCP/IP Stack + | | IPSEC processing | | ^ (AH/ESP/RFC-2401) | +---|----------|----------+ | | Key API | | Policy IKE IPSEC asks the keys via Key API (in my case, this is PFKEYv2). The "ACQUIRE" just contains the requested TS parameters. With this architecture, building IKE and IPSEC can be done independently. If you have two IPSEC implementations for the host, you could swap IKE implementations freely between them, and still have a working system. From owner-ipsec@lists.tislabs.com Wed Apr 16 16:28:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GNSPt2081002; Wed, 16 Apr 2003 16:28:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03118 Wed, 16 Apr 2003 18:47:49 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16029.56955.166274.95231@thomasm-u1.cisco.com> Date: Wed, 16 Apr 2003 15:51:39 -0700 (PDT) To: Henry Spencer Cc: IP Security List , rohc@ietf.org Subject: Re: (in)security of ESP with header compression In-Reply-To: References: <4.3.2.7.2.20030416121454.00b74328@mira-sjcm-1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > On Wed, 16 Apr 2003, David Mcgrew wrote: > > >...[IPComp] the key is that there is no inter-packet state... > > > > That makes sense. For the record, the IPCOMP definition concerns > > inter-packet state, it says that "each IP datagram is compressed and > > decompressed by itself without any relation to other datagrams". > > And in fact, a careful reading of the specification tells you that this is > a bit mis-stated: compression implementations are not just permitted but > encouraged to keep inter-packet state, e.g. to decide whether it is worth > trying to compress the next packet. It's *decompression*, and only > decompression, which must not keep inter-packet state. (And that is both > necessary and sufficient to make IPComp robust against loss or reordering > of packets.) Well, I dunno what difference it makes because ROHC is pretty stateful on both sides... Mike From owner-ipsec@lists.tislabs.com Wed Apr 16 18:16:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H1GEt2083699; Wed, 16 Apr 2003 18:16:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03508 Wed, 16 Apr 2003 20:45:50 -0400 (EDT) Message-ID: From: "Lars-Erik Jonsson (EAB)" To: Derek Atkins Cc: rohc@ietf.org, ipsec@lists.tislabs.com Subject: RE: (in)security of ESP with header compression Date: Wed, 16 Apr 2003 22:17:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > So, I don't see why IPCOMP should be any different than ESP or AH in > terms of packet independence. If ROHC is truly dependent on packet > ordering, then I think this is a bug in ROHC and needs to be addressed > there. It certainly limits the types of links in which ROHC can be > used. The RFC 3095 profiles are defined with an assumption on in-order delivery from compressor to decompressor, but modified profiles could easily be defined to tolerate packet misordering. The ROHC WG just has not yet addressed this issue, but we would appreciate input on the subject, especially motivations for us to look at it. BR /L-E From owner-ipsec@lists.tislabs.com Wed Apr 16 19:04:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H24Bt2084984; Wed, 16 Apr 2003 19:04:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA03756 Wed, 16 Apr 2003 21:35:57 -0400 (EDT) To: "Lars-Erik Jonsson (EAB)" Cc: rohc@ietf.org, ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: (in)security of ESP with header compression References: Date: 16 Apr 2003 21:39:52 -0400 In-Reply-To: Message-ID: Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Lars, "Lars-Erik Jonsson (EAB)" writes: > > So, I don't see why IPCOMP should be any different than ESP or AH in > > terms of packet independence. If ROHC is truly dependent on packet > > ordering, then I think this is a bug in ROHC and needs to be addressed > > there. It certainly limits the types of links in which ROHC can be > > used. > > The RFC 3095 profiles are defined with an assumption on in-order delivery > from compressor to decompressor, but modified profiles could easily be > defined to tolerate packet misordering. The ROHC WG just has not yet > addressed this issue, but we would appreciate input on the subject, > especially motivations for us to look at it. And this thread isn't sufficient motivation? Summerizing the thread, it would be useful to use ROHC to compress ESP tunnels, but that implies the potential for out-of-order reception. > BR > /L-E -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Thu Apr 17 06:02:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HD2pt2042170; Thu, 17 Apr 2003 06:02:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05169 Thu, 17 Apr 2003 08:25:55 -0400 (EDT) Message-ID: <3E9E53E4.5030903@polito.it> Date: Thu, 17 Apr 2003 09:12:36 +0200 From: Antonio Lioy Organization: Politecnico di Torino User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: todd glassey CC: ietf-pkix@imc.org, housley@vigilsec.com, "Lynn St.Amour" , poised@lists.tislabs.com Subject: Re: RFC3161(TSP): doubts about tcp protocol References: <3E9BE38E.80208@multicert.com> <005801c3036e$e5232f00$020aff0a@tsg1> <01ce01c67926$a1131ba0$020aff0a@tsg1> In-Reply-To: <01ce01c67926$a1131ba0$020aff0a@tsg1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk todd glassey wrote: > Look Dr. Kent - the issue here is that you do not invalidate what I am > saying you just attack me personally. If I am wrong I humbly apologize but > so far this is 100% dead-on by my take. So lets get to debunking your > commentary from the last response - > > What are all these numbers the rest of you folks might ask - Steve already > knows what they are - they are some of the many patents that any of you may > violate by building something out of 3161's technology and these are just > the ones listed on the references section of the eOriginals Patent filed in > 2001. And - this is just a partial list - there are more, like mine > (EP808997A) > for instance, so rather than attacking me personally Steve - lets try this > again - how about disproving anything I said??? I don't think you can... > > 4200770 4405829 4625076 4853961 4893338 > 4981370 4995082 5005200 5136646 5136647 > 5163091 5164988 5191613 5214703 5231668 > 5276737 5315658 5323146 5339361 5363448 > 5371794 5373561 5377270 5390247 5524073 > 5534855 5555307 5615268 5699431 5748738 > 5987429 6023509 6070239 > > But lets keep this up anyway. As far as receipts based on the RFC3161 > protocol, my take there is that the Pitney Bowes patent probably covers that > too, but if you think I am wrong then maybe PKIX should get a lawyer, or > better yet a Judge to say that in an opinion. Or maybe in this case the > authors of RFC3161 and their company's should be paying for having a legal > opinion rendered since they and you claim that the use of their technology > does not violate these larger-picture patents - Eh Carlisle - how > about it? Does Sharon have budget for this? All this discussion appears to be strongly biased towards the US approach to patents. However, Internet is an international entity and RFC-3161 has a much wider application than just to US companies. I note that in Europe at least EESSI, ETSI and the Italian government are suggesting or mandating the use of timestamps and RFC-3161 is the de-facto standard in this field. In general, the US patents are not valid in other countries unless they have been registered *prior* to pubblication (as well shown by the RSA patent in the last 30 years). So we strongly think that RFC-3161 is providing a good service for all these other countries and we leave to US citizens, companies and courts the discussion if the mentioned patents hold or not. For the vast majority of Internet the answer is simply NO! So please Todd, take this case to courts and leave Internet be free to set up a good technical standard to be used at least in that part of the world outside US. Cheers, Antonio Lioy From owner-ipsec@lists.tislabs.com Thu Apr 17 06:02:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HD2rt2042189; Thu, 17 Apr 2003 06:02:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05158 Thu, 17 Apr 2003 08:24:53 -0400 (EDT) Message-ID: From: "Lars-Erik Jonsson (EAB)" To: Derek Atkins Cc: rohc@ietf.org, ipsec@lists.tislabs.com Subject: RE: (in)security of ESP with header compression Date: Thu, 17 Apr 2003 10:56:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > The ROHC WG just has not yet addressed this issue, but we would > > appreciate input on the subject, especially motivations for us > > to look at it. > > And this thread isn't sufficient motivation? Summerizing the thread, > it would be useful to use ROHC to compress ESP tunnels, but that > implies the potential for out-of-order reception. Neither "it can be done" nor "I want it to be done" are really actual arguments for doing anything. However, there are usually real arguments behind the latter, and those would be useful to hear. Further, we need people to look at it to figure out what should be done to address the problem identified (there might be several potential ways to address an issue), and then we need people to do the actual work of writing documents. I personally think it will be useful to have "ROHC over tunnels" clarified/defined, but as a WG chair I need some concrete needs, as well as working resources (people interested in contributing). Drafts are welcome! BR /Lars-Erik From owner-ipsec@lists.tislabs.com Thu Apr 17 10:19:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HHJ3t2053809; Thu, 17 Apr 2003 10:19:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05534 Thu, 17 Apr 2003 12:40:24 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs X-Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h3HGOeT09712; Thu, 17 Apr 2003 09:24:40 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 17 Apr 2003 09:24:36 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: IPsec WG cc: "Wijnen, Bert (Bert)" Subject: Apparent duplication of TCs in draft-ietf-ipsec-flowmon-mib-tc-00.txt In-Reply-To: <4.3.2.7.2.20030417080237.024cef90@mira-sjc5-4.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, John Shriver has already pointed this out but there has been no response, and the question is an important one. It appears to me that the IPSEC-FLOW-MIB-TC MIB module in is mostly a duplication of functionality that's already in the IPSEC-ISAKMP-IKE-DOI-TC MIB module in . The table below lists the TCs in IPSEC-FLOW-MIB-TC and shows the functionally equivalent TC in IPSEC-ISAKMP-IKE-DOI-TC where one exists: IPSEC-FLOW-MIB-TC IPSEC-ISAKMP-IKE-DOI-TC ControlProtocol -- no equivalent -- Phase1PeerIdentityType IpsecDoiIdentType (*) IkeNegoMode IkeExchangeType IkeHashAlgo IkeHashAlgorithm IkeAuthMethod IkeAuthMethod DiffHellmanGrp IkeGroupDescription EncapMode IpsecDoiEncapsulationMode EncryptAlgo IpsecDoiEspTransform Spi -- no equivalent -- AuthAlgo IpsecDoiAuthAlgorithm CompAlgo IpsecDoiIpcompTransform EndPtType IpsecDoiIdentType (*) for some reason Phase1PeerIdentityType reshuffles the enum values as compared to EndPtType. The latter has the same enum values as IpsecDoiIdentType, which in turn uses the IANA-assigned Ident Type values. My question to the authors of the flow mon MIB module is: why is there this apparent duplication? Why doesn't the flow mon MIB use the TCs from the DOI TC MIB module instead? Note that the other three IPsec MIB modules do so, as does the IPSP MIB module. I do hope that the authors of the flow mon TC draft have been following the discussion on the thread entitled ``Important question about draft-ietf-ipsec-doi-tc-mib-07.txt'' because the same criticisms that I have made about that draft apply equally to the flow mon TC draft. I do not want to have to go through the same review process for two TC MIB modules that have substantially similar capabilities; it would be much better from my perspective to consolidate the two efforts and publish only one TC MIB module. Is there a compelling reason not to do so? Mike Heard From owner-ipsec@lists.tislabs.com Thu Apr 17 10:19:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HHJ4t2053817; Thu, 17 Apr 2003 10:19:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05691 Thu, 17 Apr 2003 12:46:29 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs X-Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h3HGOeT09712; Thu, 17 Apr 2003 09:24:40 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 17 Apr 2003 09:24:36 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: IPsec WG cc: "Wijnen, Bert (Bert)" Subject: Apparent duplication of TCs in draft-ietf-ipsec-flowmon-mib-tc-00.txt In-Reply-To: <4.3.2.7.2.20030417080237.024cef90@mira-sjc5-4.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, John Shriver has already pointed this out but there has been no response, and the question is an important one. It appears to me that the IPSEC-FLOW-MIB-TC MIB module in is mostly a duplication of functionality that's already in the IPSEC-ISAKMP-IKE-DOI-TC MIB module in . The table below lists the TCs in IPSEC-FLOW-MIB-TC and shows the functionally equivalent TC in IPSEC-ISAKMP-IKE-DOI-TC where one exists: IPSEC-FLOW-MIB-TC IPSEC-ISAKMP-IKE-DOI-TC ControlProtocol -- no equivalent -- Phase1PeerIdentityType IpsecDoiIdentType (*) IkeNegoMode IkeExchangeType IkeHashAlgo IkeHashAlgorithm IkeAuthMethod IkeAuthMethod DiffHellmanGrp IkeGroupDescription EncapMode IpsecDoiEncapsulationMode EncryptAlgo IpsecDoiEspTransform Spi -- no equivalent -- AuthAlgo IpsecDoiAuthAlgorithm CompAlgo IpsecDoiIpcompTransform EndPtType IpsecDoiIdentType (*) for some reason Phase1PeerIdentityType reshuffles the enum values as compared to EndPtType. The latter has the same enum values as IpsecDoiIdentType, which in turn uses the IANA-assigned Ident Type values. My question to the authors of the flow mon MIB module is: why is there this apparent duplication? Why doesn't the flow mon MIB use the TCs from the DOI TC MIB module instead? Note that the other three IPsec MIB modules do so, as does the IPSP MIB module. I do hope that the authors of the flow mon TC draft have been following the discussion on the thread entitled ``Important question about draft-ietf-ipsec-doi-tc-mib-07.txt'' because the same criticisms that I have made about that draft apply equally to the flow mon TC draft. I do not want to have to go through the same review process for two TC MIB modules that have substantially similar capabilities; it would be much better from my perspective to consolidate the two efforts and publish only one TC MIB module. Is there a compelling reason not to do so? Mike Heard From owner-ipsec@lists.tislabs.com Thu Apr 17 10:19:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HHJat2053879; Thu, 17 Apr 2003 10:19:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05533 Thu, 17 Apr 2003 12:40:22 -0400 (EDT) To: ipsec@lists.tislabs.com cc: byfraser@cisco.com Subject: Resolution of IKEV2 Open Issues From: tytso@mit.edu Message-Id: Date: Thu, 17 Apr 2003 12:44:11 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A week ago, Barbara and I sent out a list of the open issues remaining with IKEv2 after the San Francisco IETF meeting. After looking at the discussion on the mailing list, this is how we believe these issues were resolved: A. Issues settled at San Francisco to be confirmed on the mailing list. 1. Use of a la carte negotiation. No discussion, CONFIRMED 2. Not killing Me Tarzan, You Jane. No discussion, CONFIRMED 3. Identity handling. Discussion on the list produced the following wording (suggested by Paul Hoffmann) to replace the first paragraph of seciton 3.5 of ikev2-06 with: The Identification Payload, denoted ID in this memo, allows peers to assert an identify to one another. This identity may be used for policy lookup, but does not necessarily have to match anything in the CERT payload; both fields may be used by an implementation to perform access control decisions. B. DHCP over IKE versus CP. Tero submitted I-D's for consideration, and we invited comment on Tero's proposal as a substitute for Configuration payload. In the discussion which followed, a number of people on the list asserted that they believed that either would work. Darren Dukes provided a good summary of the tradeoffs in his message of April 10, 2003, for which there was little dispute. The only thing which does seem to be in dispute is how to weigh the advantages and disadvantages of the two solutions. Although this is not a vote, it is instructive to look at the positions of the people who contributed to the discussion: Flip a coin: Derek Atkins, Scott Kelley DHCP/IKE: Michael Richardson, Bill Summerfeld (don't re-invent DHCP, easier reuse of non-IPSEC network infrastructure), Francis Dupont (doesn't believe CP is proper solution for IPv6), Michael Thomas, Tero Kivinen CP: Darren Dukes (slight preference. flip a coin, but prefer CP because it's in the spec), Ravi Kumar, Charlie Kaufman (because it's simpler), Jim Knowles, Jing Xian (simplicity and performance), Andrew Krywaniuk (worried about danger of blindly forwawrding an unauthenticated packet to DHCP server into the intranet) At the San Francisco IETF, the decision criteria which we set was that Configuration Payload was the default answer, and in order to replace CP with an alternate proposal, strong support was needed. This was a tough call, but ultimately, Barbara and I have to conclude that this bar was not met. Although many well-respected wg participants argued in favor of DHCP over IKE, many other wg participants were in favor of keeping the existing Configuration Payload. It should be noted that this does not permanently preclude use of DHCP as a configuration mechanism for IKE; this decision only affects what will be in the IKEv2 specification. For those people who continue to believe that DHCP is needed for their application, they are invited to approach the Security AD's and pursuade them that there is a sufficient constituency for this work to persue standardization in of a DHCP-style solution (either using a RFC 3456-style approach, or a DHCP over IKE approach) as a stand-alone document. This work could either take place in a new working group, or be assigned to the IPSRA working group. C. Issues that have arisen on the mailing list since San Francisco 1. Protection of initiator's identity against active attacks for EAP case. As we stated earlier, this issue was raised previous to the San Francisco meeting, and did not then receive sufficient support. We believe the changes necessary to provide this functionality are sufficiently invasive and sufficient complexity (by essentially making legacy authentication an entirely new protocol with payloads appearing in different order and with different levels of protection) that we believe that we can not pursue functionality at this late date. 2. Tero's proposal for a new source-address changed notification payload. While soluable, some issues were raised about how to best accomplish this functionality. So we believe this work should be deferred to separate, stand-alone specification. 3. Uri's AES PRF proposal. Not at this time; waiting for more intensive cryptographic review by the Cryptography Research Working Group. 4. Michael Richardson's proposal to define separate payload numbers for IDi and IDr. Let's just do it. 5. Lack of definition of COOKIE_REQUIRED payload. Use Charlie's suggestion to delete COOKIE_REQUIRED and to simply use the COOKIE payload. 6. Remove language about required cryptographic algorithms. This question of which algorithms are mandatory to implement is to be deferred to another specification, which Jeff Schiller is authoring. 7. Peer address protection and NAT traversal issues. The issues which Francis Dupont has been raising, have for the most part, failed to achieve resonance with the working group. In particular, there seems to be no conensus that the "pseudo-NAT attack" is one which should raise concern, and there seems to be no consensus that the NAT traversal functionality should be capable of being administratively prohibited. That being said, we would like Charlie to examine Francis's e-mail message of April 10, 2003, with the subject "IKEv2 draft 6 (details)", as there were a few spelling errors and other clarifications which do seem appropriate. NEXT STEPS ========== With these issues addressed, Barbara and I believe that the next step is to ask Charlie to make these final edits to ikev6 I-D. Once the -07 draft is published by the secretariat, we will initiate a working group last call. This will be a final opportunity for people to make comments on the draft. However, during working group last call, the bar required for the working group to take action will be higher than during this previous phase of discussion. Once the working group last call is finished, and any necessary comments are addressed, we will forward the IKEv2 specification to the IESG, and the entire ipsec working group can give itself a well-deserved pat on the back for achieving this milestone. Ted and Barbara From owner-ipsec@lists.tislabs.com Thu Apr 17 10:20:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HHK5t2053904; Thu, 17 Apr 2003 10:20:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05698 Thu, 17 Apr 2003 12:48:29 -0400 (EDT) To: "C. M. Heard" Cc: IPsec WG , "Wijnen, Bert (Bert)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories References: Date: Thu, 17 Apr 2003 09:13:17 -0700 In-Reply-To: ("C. M. Heard"'s message of "Wed, 16 Apr 2003 13:01:35 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> On Wed, 16 Apr 2003 13:01:35 -0700 (PDT), "C. M. Heard" said: C> This discussion has been dormant for about a week, and I do need to C> proceed with finalization of my MIB review comments for the ADs. So C> unless I hear some very convincing arguments to the contrary before C> Tuesday, 22 April 2003, my review comments will advise that all the C> enumerated INTEGER TCs in the IPSEC-ISAKMP-IKE-DOI-TC have the C> SYNTAX value changed to the appropriate Unsigned32 subrange, and C> that the MIB module be maintained by the WG, not by IANA. Well, sorry for the delay (out of town) in input from me (I'm one of the authors of the IPSEC-POLICY-MIB that will be affected by this in the end). In short, I certainly understand the problem. However, I'm not convinced we're going the right way with the decision. So a quick recap of common knowledge at this point: A) enumerated TCs, like those in this MIB, are used for a few purposes: i) standardizing and maintaining a standardized definition list. ii) Enabling automated parsing of the MIB so that automatic translations can be used where possible by management applications. This, in my opinion, is the biggest win for using an enumerated TC. B) The problem is that the IPsec protocols have various places where an integer is used on-the-wire with a "range" of standardized values that do not fall into the maximum allow within the coding of the packet itself. The rest of the values fall into "enterprise" specific values and will not ever be assigned by a standards body (read: IANA). We'll come back to this. C) MIBs containing standardized TCs get updated frequently. Management applications MUST be able to handle values that fall outside of enum ranges already. MIBs get updated to add new TCs all the time, and management applications must realize that the copy "they" have may not be up to date compared to the copy the agent is implementing. A perfect example of this is the IANAifType-MIB, which defines the IANAifType TC that gets frequent updates (there were 4 REVISIONS statements in 2002). The problem stems from the wording in the text of the of the IPSEC-ISAKMP-IKE-DOI-TC mib that says certain ranges of the values are "reserved" for private use. So, there are three options: 1) Leave things as is. 2) The proposed switch to an Unsigned32 with descriptions/references in the DESCRIPTION and REFERENCEs clauses or in SMIv2 "--" comments. 3) Reword the "out of scope" statement so it's more friendly and less controversial. This is my new thought and suggestion. The problem with 1 is that no one likes the wording and it's generally believed to be "illegal" by the MIB experts. The problem with number 2 is that it decreases the benefit ("A ii" from above) when it comes to actually using the TC in the first place. Can anyone honestly name a *technical* reason why a value that falls out of scope of a defined enum list would cause a technical problem in a management application or agent? I'd argue that due to C above that in the end the applications that implement this TC won't care either way. Either way they'll have to deal with unknown values. That means that the only real gain here by a Unsigned32 is for human reasons (and maybe the administrative burden of maintaining two lists [eg, RFC2407 and the RFC this will be published in] is a real problem, I don't know. I don't work for IANA and don't know the type of document tracking and editing tools available to them). The real loss is the automated parsing of the enums by management applications that want to display something other than "10" after Espv7 comes out and gets assigned to the number 10 on the wire, eg. So my suggestion is not to retype but to change the wording in the MIB to make it more friendly to IANA and the IETF while still allowing for enums to be used for all the values defined by the IETF. Instead of: The values 249-255 are reserved for private use amongst cooperating systems. I suggest something like: As described in RFC 2407 section 4.4.1, the range of values that will be assigned by IANA for use in this TEXTUAL-CONVENTION and the IPSEC DOI will fall between 0 and 248. Values in the range 249-255 will not be utilized within IETF standardization documents. Any chance this would be a better technical and human middle ground? -- Wes Hardaker Network Associates Laboratories From owner-ipsec@lists.tislabs.com Thu Apr 17 11:31:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIVPt2056302; Thu, 17 Apr 2003 11:31:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05936 Thu, 17 Apr 2003 13:58:56 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 17 Apr 2003 11:03:01 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Wes Hardaker cc: IPsec WG , "Wijnen, Bert (Bert)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 17 Apr 2003, Wes Hardaker wrote: > I'm not convinced we're going the right way with the decision. > So a quick recap of common knowledge at this point: > > A) enumerated TCs, like those in this MIB, are used for a few > purposes: > > i) standardizing and maintaining a standardized definition list. > ii) Enabling automated parsing of the MIB so that automatic > translations can be used where possible by management > applications. This, in my opinion, is the biggest win for using > an enumerated TC. I can easily understand how this is useful in a MIB browser whose understanding of the underlying data is limited to what it can parse from the MIB module. I have more trouble understanding how it helps very much for a more sophisticated application that has built-in knowledge of the underlying MIB objects. This is especially true, I should think, of a configuration application, such as might be built on top of the IPSEC-POLICY-MIB module. To be more specific, let's consider the IpsecDoiIdentType TC, which is used in some of the read-create objects in IPSEC-POLICY-MIB. The underlying data item in the protocol allows for IANA-assigned values in the range 1..248 (0 is reserved) and sets aside values in the range 249..255 for private use between consenting parties. Now, two of the enumerations are these: idDerAsn1Dn(9), -- the binary DER encoding of -- ASN1 X.500 -- DistinguishedName idDerAsn1Gn(10), -- the binary DER encoding of -- ASN1 X.500 GeneralName I can easily believe that the enum label might appear in a drop-down box or the like, and that would be nice. But, it's clearly not enough if you want to provide meaningful help text. for that it would be necessary to capture the stuff in the ASN.1 comments or something like it. And presumably you also want to allow users to set values by number, both in the IANA-assigned range (e.g., for new assignments that are not yet known to the software) and in the private use range (to accomodate customer protocols that might use such values), but you want to limit the range to valid values (1..255 or maybe 0..255). For this your management application needs more knowledge than can be obtained from the parseable information in an enumerated INTEGER TC. That has to be built in. The subranged Unsigned32 lacks the labels for the assignments, but it at least has the proper range limits. One could argue that this is even more important to have than the enum labels. > B) The problem is that the IPsec protocols have various places where > an integer is used on-the-wire with a "range" of standardized > values that do not fall into the maximum allow within the coding > of the packet itself. I'm not sure what you mean by this. The range of "standardized" values is always a subset of that can be coded in the packet. > The rest of the values fall into "enterprise" > specific values and will not ever be assigned by a standards body > (read: IANA). We'll come back to this. > > C) MIBs containing standardized TCs get updated frequently. > Management applications MUST be able to handle values that fall > outside of enum ranges already. MIBs get updated to add new TCs > all the time, and management applications must realize that the > copy "they" have may not be up to date compared to the copy the > agent is implementing. A perfect example of this is the > IANAifType-MIB, which defines the IANAifType TC that gets frequent > updates (there were 4 REVISIONS statements in 2002). This certainly is true. Both monitor apps and configuration apps have to accomodate this. The difference for something like IANAifType is that it conforms to SMI requirements and user expectations for enumerated INTEGERs , while something like IpsecDoiIdentType does not. > The problem stems from the wording in the text of the of the > IPSEC-ISAKMP-IKE-DOI-TC mib that says certain ranges of the > values are "reserved" for private use. That's not a problem in the DESCRIPTION clauses; they are actually correct in doing this because it properly reflects the underlying protocol specification. The problem, rather, is that the enumerated INTEGER SYNTAX is not (according to SMI rules and user expectations) consistent with such a description. > So, there are three options: > > 1) Leave things as is. > > 2) The proposed switch to an Unsigned32 with descriptions/references > in the DESCRIPTION and REFERENCEs clauses or in SMIv2 "--" > comments. There should be no commentary listing assigned values, but rather the there should be a pointer to the IANA registry (one version of the truth, please). > 3) Reword the "out of scope" statement so it's more friendly and less > controversial. This is my new thought and suggestion. > > The problem with 1 is that no one likes the wording and it's generally > believed to be "illegal" by the MIB experts. Agreed. > The problem with number 2 is that it decreases the benefit ("A > ii" from above) when it comes to actually using the TC in the > first place. Can anyone honestly name a *technical* reason why > a value that falls out of scope of a defined enum list would > cause a technical problem in a management application or agent? > I'd argue that due to C above that in the end the applications > that implement this TC won't care either way. Either way > they'll have to deal with unknown values. That means that the > only real gain here by a Unsigned32 is for human reasons (and > maybe the administrative burden of maintaining two lists [eg, > RFC2407 and the RFC this will be published in] is a real > problem, I don't know. I don't work for IANA and don't know the > type of document tracking and editing tools available to them). > The real loss is the automated parsing of the enums by > management applications that want to display something other > than "10" after Espv7 comes out and gets assigned to the number > 10 on the wire, eg. I think I've at least partly answered the arguments about the loss of functionality (i.e. that it's not as much as it appears to be for applications that have built-in MIB knowledge). The extra burden on IANA is a very real concern, and when I started the review of this MIB module most of the comments I wrote were related to changes that I thought would be necessary in order to make that tractable. One either needs to reorganize the IPsec registries so that this MIB module is the one version of the truth for the stuff it covers (problematic because it does not cover everything), or else one needs to update stuff in two places (undesirable for the obvious reasons). > So my suggestion is not to retype but to change the wording in the MIB > to make it more friendly to IANA and the IETF while still allowing for > enums to be used for all the values defined by the IETF. > > Instead of: > > The values 249-255 are reserved for private use > amongst cooperating systems. > > I suggest something like: > > As described in RFC 2407 section 4.4.1, the range of values that > will be assigned by IANA for use in this TEXTUAL-CONVENTION and > the IPSEC DOI will fall between 0 and 248. Values in the range > 249-255 will not be utilized within IETF standardization > documents. > > Any chance this would be a better technical and human middle ground? I think this would be a step backwards because it suggests that the managed objects won't contain values in the range 249-255, which is not the intent. The managed objects are supposed to contain a snapshot of what goes in an on-the-wire message, and the DESCRIPTION clause and SYNTAX value should make that fact as clear as they possibly can. //cmh From owner-ipsec@lists.tislabs.com Thu Apr 17 14:23:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLNdt2062689; Thu, 17 Apr 2003 14:23:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06458 Thu, 17 Apr 2003 16:51:19 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200304162042.h3GKgxSm031065@burp.tkv.asdf.org> References: <200304141936.h3EJaoI3008229@burp.tkv.asdf.org> <200304142154.h3ELslw2009295@burp.tkv.asdf.org> <200304162042.h3GKgxSm031065@burp.tkv.asdf.org> Date: Thu, 17 Apr 2003 16:47:28 -0400 To: Markku Savela From: Stephen Kent Subject: Re: Question on SA Bundle Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:42 PM +0300 4/16/03, Markku Savela wrote: > > From: Stephen Kent >> >> I guess I don't really understand your motivation for not having IKE >> convey the policy info from the SPDs to avoid future problems. Do you >> envision other ways to convey this data, or do you not believe that >> it is worthwhile to avoid the sort of problems noted above? > >The current IPSEC/IKE architecture seems to be something like > > +-------------------------+ > | TCP/IP Stack + | > | IPSEC processing | > | ^ (AH/ESP/RFC-2401) | > +---|----------|----------+ > | | Key API > | | > Policy ---> IKE > >I believe the "Policy --> IKE" link should not be there (not for >PHASE2 SA's at least). For IKE all that is needed, is KEY API. I would not draw the diagram that way. When I speak on IPsec I don't have a diagram that looks at all like that. I won't try to convert my PPT slides for outbound and inbound processing into ASCII diagrams now, but they will appear in the 2401bis I-D later this summer. Note that 2401 does not refer to a "Key API" nor does it say how in detail how the SPD is populated. Steve From owner-ipsec@lists.tislabs.com Thu Apr 17 15:27:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HMRKt2064592; Thu, 17 Apr 2003 15:27:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06594 Thu, 17 Apr 2003 17:58:42 -0400 (EDT) From: "Yaron Sheffer" To: "Lars-Erik Jonsson \(EAB\)" , "Derek Atkins" Cc: , Subject: RE: [rohc] RE: (in)security of ESP with header compression Date: Fri, 18 Apr 2003 00:59:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ESP includes a 32-bit sequence number. It is mandatory for the sender to set and increment it correctly, but optional for the receiver to verify it. It is there to prevent malicious replay of messages. In the case of ROHC over ESP, if the receiver's policy is to delete packets with an out-of-order ESP sequence number (possibly using a small reorder buffer), then packets reaching the decompressor are always in order. The channel is not reliable of course, since entire packets may be deleted. All in all, this channel becomes analogous to your plain vanilla PPP. Applicability: in general, IP (and ESP) packets may be drastically reordered, with packets coming in many seconds out of order. For Internet telephony, those packets are useless and can be discarded on arrival. Under these assumptions, I don't believe any change to the operating assumptions of ROHC, or a new ROHC profile, is needed. This is not "ROHC over tunnels" but only "ROHC over ESP", but it's still an interesting case. Thanks, Yaron -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of Lars-Erik Jonsson (EAB) Sent: Wednesday, April 16, 2003 10:18 PM To: Derek Atkins Cc: rohc@ietf.org; ipsec@lists.tislabs.com Subject: [rohc] RE: (in)security of ESP with header compression > So, I don't see why IPCOMP should be any different than ESP or AH in > terms of packet independence. If ROHC is truly dependent on packet > ordering, then I think this is a bug in ROHC and needs to be addressed > there. It certainly limits the types of links in which ROHC can be > used. The RFC 3095 profiles are defined with an assumption on in-order delivery from compressor to decompressor, but modified profiles could easily be defined to tolerate packet misordering. The ROHC WG just has not yet addressed this issue, but we would appreciate input on the subject, especially motivations for us to look at it. BR /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From owner-ipsec@lists.tislabs.com Thu Apr 17 18:01:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3I11tt2068584; Thu, 17 Apr 2003 18:01:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07077 Thu, 17 Apr 2003 20:05:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16031.16905.78000.172133@gargle.gargle.HOWL> Date: Thu, 17 Apr 2003 20:08:41 -0400 From: Paul Koning To: yaronf@gmx.net Cc: Lars-Erik.Jonsson@epl.ericsson.se, derek@ihtfp.com, rohc@ietf.org, ipsec@lists.tislabs.com Subject: RE: [rohc] RE: (in)security of ESP with header compression References: X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Yaron" == Yaron Sheffer writes: Yaron> ESP includes a 32-bit sequence number. It is mandatory for the Yaron> sender to set and increment it correctly, but optional for the Yaron> receiver to verify it. It is there to prevent malicious replay Yaron> of messages. Yaron> In the case of ROHC over ESP, if the receiver's policy is to Yaron> delete packets with an out-of-order ESP sequence number Yaron> (possibly using a small reorder buffer), then packets reaching Yaron> the decompressor are always in order. The channel is not Yaron> reliable of course, since entire packets may be deleted. All Yaron> in all, this channel becomes analogous to your plain vanilla Yaron> PPP. Yaron> Applicability: in general, IP (and ESP) packets may be Yaron> drastically reordered, with packets coming in many seconds out Yaron> of order. For Internet telephony, those packets are useless Yaron> and can be discarded on arrival. Yaron> Under these assumptions, I don't believe any change to the Yaron> operating assumptions of ROHC, or a new ROHC profile, is Yaron> needed. This is not "ROHC over tunnels" but only "ROHC over Yaron> ESP", but it's still an interesting case. Maybe. But your assumption is questionable. One could build ESP like that, but I've never heard of anyone doing it. The typical implementation will accept packets that are out of order WITHOUT putting them back in order, provided they are not out of order by more than a "window" amount. A typical window is 64, because that's the max size of an easy to do bitmap, but it's not significantly harder to make it bigger, and the cost is only a a bit per unit of distance. So your assumption that ESP (with integrity) is a lossy ordered channel is unlikely to be valid. paul From owner-ipsec@lists.tislabs.com Thu Apr 17 23:32:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3I6WRt2082330; Thu, 17 Apr 2003 23:32:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA07780 Fri, 18 Apr 2003 02:01:30 -0400 (EDT) To: "C. M. Heard" Cc: IPsec WG , "Wijnen, Bert (Bert)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories References: Date: Thu, 17 Apr 2003 23:05:41 -0700 In-Reply-To: ("C. M. Heard"'s message of "Thu, 17 Apr 2003 11:03:01 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> On Thu, 17 Apr 2003 11:03:01 -0700 (PDT), "C. M. Heard" said: W> ii) Enabling automated parsing of the MIB so that automatic W> translations can be used where possible by management W> applications. This, in my opinion, is the biggest win for using W> an enumerated TC. C> I can easily understand how this is useful in a MIB browser whose C> understanding of the underlying data is limited to what it can parse C> from the MIB module. Many such browsers exist, yes. C> I have more trouble understanding how it helps very much for a more C> sophisticated application that has built-in knowledge of the C> underlying MIB objects. This is especially true, I should think, C> of a configuration application, such as might be built on top of C> the IPSEC-POLICY-MIB module. There are both smart and generic tools, yes. Smart tools will likely display more information than the generic ones, as they will be preprogrammed with additional information (eg, more humanly understandable text to supplement or replace the enum labels). They will still benefit, however, from enum labels when the standard has advanced faster than the installed software base. Smart tools should use better text when possible, enum labels when updated MIBs are available but updated software is not, and finally generic numeric values when all else fails. This is true for both monitoring and for configuration, IMHO. (and specifically, don't forget that monitoring and display of configuration data is also useful so just because a variable is read-create or read-write doesn't mean you'll never do a GET or GETNEXT on it). Finally, generic tools will likely have only labels to deal with and/or raw numbers. ... C> idDerAsn1Dn(9), -- the binary DER encoding of C> -- ASN1 X.500 C> -- DistinguishedName C> idDerAsn1Gn(10), -- the binary DER encoding of C> -- ASN1 X.500 GeneralName ... C> I can easily believe that the enum label might appear in a drop-down C> box or the like, and that would be nice. But, it's clearly not C> enough if you want to provide meaningful help text. ... Everything you said in the deleted portions makes perfect sense. Smart applications need more information to display better help text for the user. It must get this from comments, description clauses and programmer knowledge. I agree absolutely. What I disagree with is that smart tools will never need to be updated (or that they'll be updated at the same time as the MIBs) and that we never need to worry about generic tools. I write both. I'd prefer an enum list for both sets of my tools. C> The subranged Unsigned32 lacks the labels for the assignments, but C> it at least has the proper range limits. One could argue that this C> is even more important to have than the enum labels. This is a definite trade off here. You can't have both an enum list and a range list. An over-site of SMIv2 that is a technical challenge because parsers would actually break if we use both. You could argue that ranges are more important, but I'd argue against it. Specifically, I'd put the ranges in the description clause (which even generic tools can display for the end user) but use enums so those pretty drop down lists can be auto-built when possible (and the smart tools can use it as a double check). W> B) The problem is that the IPsec protocols have various places where W> an integer is used on-the-wire with a "range" of standardized W> values that do not fall into the maximum allow within the coding W> of the packet itself. C> I'm not sure what you mean by this. The range of "standardized" C> values is always a subset of that can be coded in the packet. I think we said the same thing. In different ways. C> The problem, rather, is that the enumerated INTEGER SYNTAX is not C> (according to SMI rules and user expectations) consistent with such C> a description. I still can't find a technical argument (and maybe I'm just missing it) why it's a problem. What will application will break if a agent returns a value outside the assigned enum list? None, since they all have to deal with outside values now. What agent will break when a manager tries to set a value to an agent that it doesn't support? None, since they must all deal with this anyway. In fact, the agent that receives a value outside the legal range of values will already have to return the exact same error to the management app that sent an illegal value in the first place. C> I think I've at least partly answered the arguments about the loss C> of functionality (i.e. that it's not as much as it appears to be C> for applications that have built-in MIB knowledge). Final question: You keep coming back to this. Does this mean that there is no use for TCs of enums? IE, why do we have machine-readable enums in the first place if if all applications must have built in knowledge? It seems your trying to make a point that applications must have built-in MIB knowledge, in which case we never need machine-readable enums in the first place? C> The extra burden on IANA is a very real concern, and when I started C> the review of this MIB module most of the comments I wrote were C> related to changes that I thought would be necessary in order to C> make that tractable. If that is the reason you want to oppose the use of enums, then it is a more understandable argument from my eyes at least. Unfortunately, there is still functionality lost if this is the case. Does it mean we should never create enums in MIBs when it is supposed to match another standards document? We should always use references and no real values (in enums, description clauses or comments) in that case? I would argue that the administrative burden isn't as big a problem either. It's certainly going to be the case that the protocol documents will be updated with new values first. The MIB will never have new enums inserted into it before the protocol is defined that uses those new values. Thus, the MIB should always be a direct mirror of the protocol (a frequent case). If the MIB fails to get updated at the same time as the master standards document, there is no technical problem that I can see. In fact, it's just as if an Unsigned32 had been used for those unknown values that were being returned/sent. Now, the one administrative problem that I could see is that human errors always seem to sneak in. The worst of which would be a reordering of the values in question. W> I suggest something like: W> W> As described in RFC 2407 section 4.4.1, the range of values that W> will be assigned by IANA for use in this TEXTUAL-CONVENTION and W> the IPSEC DOI will fall between 0 and 248. Values in the range W> 249-255 will not be utilized within IETF standardization W> documents. C> I think this would be a step backwards because it suggests that the C> managed objects won't contain values in the range 249-255, which is C> not the intent. The managed objects are supposed to contain a C> snapshot of what goes in an on-the-wire message, and the DESCRIPTION C> clause and SYNTAX value should make that fact as clear as they C> possibly can. Ok, good point. How about: As described in RFC 2407 section 4.4.1, the range of values that will be assigned by IANA for use in this TEXTUAL-CONVENTION and the IPSEC DOI will fall between 0 and 248, while legal values on the wire may fall between 0 and 255. Values in the range 249-255 will not be utilized within IETF standardization documents. My whole goal here is to increase the usability of the MIB that tools will read. IMHO, enums are very useful and unless there is a technical reason why it causes a serious problem to use them in cases like this, I just don't get why we're removing functionality that is beneficial to some applications for no technical, engineering gain. Engineering involves making choices intelligently so things don't break, while attempting to provide the maximum possible benefit at the same time. IMHO, the best gain here is from using enums and I (at least) have yet to see a reason why things would break. -- Wes Hardaker Network Associates Laboratories From owner-ipsec@lists.tislabs.com Fri Apr 18 04:35:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IBZgt2016676; Fri, 18 Apr 2003 04:35:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA08728 Fri, 18 Apr 2003 07:01:38 -0400 (EDT) Message-ID: <3E9EF208.6090202@isi.edu> Date: Thu, 17 Apr 2003 11:27:20 -0700 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4a) Gecko/20030407 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec-vpn@puck.nether.net, ipsec@lists.tislabs.com, ppvpn@lyris.nortelnetworks.com Subject: ID update: draft-touch-ipsec-vpn-05.txt Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030305020806060603010903" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms030305020806060603010903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, we've updated our ID on "Use of IPsec Transport Mode for Dynamic Routing", and would appreciate comments. ftp://ftp.isi.edu/internet-drafts/draft-touch-ipsec-vpn-05.txt While the basic contents are identical, the latest update has been restructured for better readability and adds an extended discussion of alternative approaches. Thanks, Lars -- Lars Eggert USC Information Sciences Institute --------------ms030305020806060603010903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDQxNzE4MjcyMFowIwYJKoZIhvcNAQkEMRYEFP2wBK/GXuBjRvcf2Ewa HxKLj75gMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAIs8OD4xqGN0EVe59peEEen8Tv//6srFRUReq kEZZPnyNa+Ho4wmxaSJY7xq1SM5FFNQNLUNUp2Kq7Y3R3GwAALw6qDudBe0mMj/F8P53TP3Z Da4fwJGSSbOQ3RPCpFgGtXz1s9Lsw2LedTi29W95oJIbY65EVgxsp/vtvO7I9dyoNbfa6YOS lFPLSu1+6xBsXbV7HrToKx5FhUJ71D5gf5AMUHUk5NGfIpJvEKu4A/AL+Uz3gdsh8y8tIO3/ WpyC33WWqGX63yAuom+/83m6vhx2lYzgiAGql8isvCxPiguoCzB7jTdFjV60aZpp9hVNM08z EcUWSOU+ZicxEaY4vwAAAAAAAA== --------------ms030305020806060603010903-- From owner-ipsec@lists.tislabs.com Fri Apr 18 05:06:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IC66t2017317; Fri, 18 Apr 2003 05:06:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA08801 Fri, 18 Apr 2003 07:40:01 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 18 Apr 2003 04:44:04 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Wes Hardaker cc: IPsec WG , "Wijnen, Bert (Bert)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 17 Apr 2003, Wes Hardaker wrote: > What I disagree with is that smart tools will never need to be > updated (or that they'll be updated at the same time as the > MIBs) and that we never need to worry about generic tools. I > write both. I'd prefer an enum list for both sets of my tools. > > C> The subranged Unsigned32 lacks the labels for the assignments, but > C> it at least has the proper range limits. One could argue that this > C> is even more important to have than the enum labels. > > This is a definite trade off here. You can't have both an enum list > and a range list. An over-site of SMIv2 that is a technical challenge > because parsers would actually break if we use both. You could argue > that ranges are more important, but I'd argue against it. > Specifically, I'd put the ranges in the description clause (which even > generic tools can display for the end user) but use enums so those > pretty drop down lists can be auto-built when possible (and the smart > tools can use it as a double check). OK, this makes your position very clear (and I think it is in agreement with the sentiments expressed by the module author). > C> The problem, rather, is that the enumerated INTEGER SYNTAX is not > C> (according to SMI rules and user expectations) consistent with such > C> a description. > > I still can't find a technical argument (and maybe I'm just missing > it) why it's a problem. What will application will break if a agent > returns a value outside the assigned enum list? None, since they all > have to deal with outside values now. Agreed. > What agent will break when a manager tries to set a value to an > agent that it doesn't support? None, since they must all deal > with this anyway. Agreed. > In fact, the agent that receives a value outside the legal range > of values will already have to return the exact same error to > the management app that sent an illegal value in the first > place. Depending on what you mean by "the legal range of values" this can be a problem. If you mean "the values in the enum list that are know to the agent" (which is the behaviour mandated by RFC 2578 Section 7.1.1) then this IS a problem because for the DOI TCs the agent should ACCEPT any value that is within the range defined for the underlying protocol data item if (a) it does not require special knowledge on the part of the agent to process it or (b) it is in the "private use" range and the agent knows what to do with it. Note that in the latter case in particular, the value is _valid_ even though it does not appear in the enum list. Now, one could code around this problem, but that won't be conformant to RFC 2578 Section 7.1.1, which says that "only those named-numbers so enumerated may be present as a value." > Final question: You keep coming back to this. Does this mean that > there is no use for TCs of enums? IE, why do we have machine-readable > enums in the first place if if all applications must have built in > knowledge? It seems your trying to make a point that applications > must have built-in MIB knowledge, in which case we never need > machine-readable enums in the first place? The issue isn't whether machine-readable enums are appropriate in general, but whether they are appropriate for objects where some of the valid values will never appear in the enum list. > C> The extra burden on IANA is a very real concern, and when I started > C> the review of this MIB module most of the comments I wrote were > C> related to changes that I thought would be necessary in order to > C> make that tractable. > > If that is the reason you want to oppose the use of enums, then it > is a more understandable argument from my eyes at least. > Unfortunately, there is still functionality lost if this is the case. > Does it mean we should never create enums in MIBs when it is supposed > to match another standards document? We should always use references > and no real values (in enums, description clauses or comments) in that > case? > > I would argue that the administrative burden isn't as big a problem > either. You might not think so when you've seen the details that apply to this case. Unfortunately, I need to leave right now for an out-of-town trip, and I will have to defer the details of that discussion (and the other points in your e-mail) until next week. Mike From owner-ipsec@lists.tislabs.com Fri Apr 18 06:12:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IDCFt2019208; Fri, 18 Apr 2003 06:12:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09009 Fri, 18 Apr 2003 08:43:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 18 Apr 2003 08:41:50 -0400 To: "Yaron Sheffer" From: Stephen Kent Subject: RE: [rohc] RE: (in)security of ESP with header compression Cc: "Lars-Erik Jonsson \(EAB\)" , "Derek Atkins" , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:59 AM +0200 4/18/03, Yaron Sheffer wrote: >ESP includes a 32-bit sequence number. It is mandatory for the sender to set >and increment it correctly, but optional for the receiver to verify it. It >is there to prevent malicious replay of messages. > >In the case of ROHC over ESP, if the receiver's policy is to delete packets >with an out-of-order ESP sequence number (possibly using a small reorder >buffer), then packets reaching the decompressor are always in order. The >channel is not reliable of course, since entire packets may be deleted. All >in all, this channel becomes analogous to your plain vanilla PPP. > >Applicability: in general, IP (and ESP) packets may be drastically >reordered, with packets coming in many seconds out of order. For Internet >telephony, those packets are useless and can be discarded on arrival. > >Under these assumptions, I don't believe any change to the operating >assumptions of ROHC, or a new ROHC profile, is needed. This is not "ROHC >over tunnels" but only "ROHC over ESP", but it's still an interesting case. > >Thanks, > Yaron I may not have understood your argument, but any solution we would adopt for IPsec use of ROHC must be general, i.e., it cannot depend on specific receiver constraints re anti-replay window parameters. Also, your message suggests a possible misunderstanding re IPsec and anti-replay: I know of no IPsec implementation that reorders packets upon arrival and doing so is certainly outside the scope of what the RFCs call for. Steve From owner-ipsec@lists.tislabs.com Fri Apr 18 07:17:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IEH8t2024826; Fri, 18 Apr 2003 07:17:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09191 Fri, 18 Apr 2003 09:44:54 -0400 (EDT) To: "C. M. Heard" Cc: IPsec WG , "Wijnen, Bert (Bert)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories References: Date: Fri, 18 Apr 2003 06:49:02 -0700 In-Reply-To: ("C. M. Heard"'s message of "Fri, 18 Apr 2003 04:44:04 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> On Fri, 18 Apr 2003 04:44:04 -0700 (PDT), "C. M. Heard" said: Wes> In fact, the agent that receives a value outside the legal range Wes> of values will already have to return the exact same error to Wes> the management app that sent an illegal value in the first Wes> place. C> Depending on what you mean by "the legal range of values" this can C> be a problem. If you mean "the values in the enum list that are C> know to the agent" (which is the behaviour mandated by RFC 2578 C> Section 7.1.1) then this IS a problem because for the DOI TCs the C> agent should ACCEPT any value that is within the range defined for C> the underlying protocol data item if (a) it does not require special C> knowledge on the part of the agent to process it or (b) it is in the C> "private use" range and the agent knows what to do with it. Note C> that in the latter case in particular, the value is _valid_ even C> though it does not appear in the enum list. Now, one could code C> around this problem, but that won't be conformant to RFC 2578 C> Section 7.1.1, which says that "only those named-numbers so C> enumerated may be present as a value." Ok, then how about changing my suggestion to: As described in RFC 2407 section 4.4.1, the range of values that will be assigned by IANA for use in this TEXTUAL-CONVENTION and the IPsec DOI will fall between 0 and 248, while legal values on the wire may fall between 0 and 255. Values in the range 249-255 will not be utilized within IETF standardization documents as they have been reserved by the IPsec DOI for private use by cooperating devices. All use of deviations from the standardized list of enumerations, including those that fall in the 249-255 range, must be documented within the appropriate AGENT-CAPABILITIES statements. This documents that values from 249-255 won't be standardized, are intended for use by private organizations, and finally reminds the agent implementers that these other accepted/used values must be documented in the standard way in which all agents are supposed to document their deviation from a standardized SMIv2 document. -- Wes Hardaker Network Associates Laboratories From owner-ipsec@lists.tislabs.com Fri Apr 18 08:36:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IFakt2027105; Fri, 18 Apr 2003 08:36:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09417 Fri, 18 Apr 2003 11:03:19 -0400 (EDT) Message-Id: <5.2.0.9.2.20030417184743.02d454c8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 17 Apr 2003 18:53:15 -0400 To: "Theodore Ts'o" , Paul Hoffman / VPNC From: Russ Housley Subject: Re: IKE V2 Open Issues Cc: ipsec@lists.tislabs.com, Jeff Schiller , Charlie Kaufman In-Reply-To: <20030414124609.GB6909@think> References: <20030411192404.GB30438@think> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted: > > None of the "other assigned numbers" are dealt with in Jeff's > > document; these are. > > > > Implementers *have* to read both documents. They cannot implement the > > mandatory algorithms without reading Jeff's document. Thus, having > > the algorithm identifiers in the same document as the explanations of > > what is mandatory makes more sense than putting the numeric values in > > one document and the protocol description of the values (what is > > mandatory and what is not) in a different document. > >Implementors can start implementing IKEv2 without knowing exactly >which algorithms will be mandatory and which will be optional. In >most implementations which I've seen, the choice of such things is >kept in a modular design, and given that we've already said that what >will be mandatory will be changing over time, a wise implementor will >certainly make their product easy to update with respect to what >crypto algorithms are in use. > >Furthermore, I would like to reduce the number of interdependencies on >the ikev2 document, so that we don't end up having to hold up the >ikev2 document based on external dependencies. The good news is that >Jeff has finished the first cut at the document, so this is not to say >that I don't have faith that the second document won't be immediately >forthcoming. However, Barbara and I would like to be able to get >ikev2 off our hands and into the IESG's plate as soon as possible, and >so anything where we can remove dependencies is a good thing. > >Due to its complexity ikev2 will probably require extra time for the >IESG to consider, if past experience with IKE is any guide. So we can >finish polishing the required crypto algorithms document in parallel >with the IESG cogitating over ikev2, and once it's ready, we can ship >that off to the IESG, and given that the required crypto algorithms >document will be much simpler, I imagine that will be able to zip >through the IESG review stage very quickly. > >Having seen a first draft of Jeff's document, one compromise which I >think would work well is to have the initial definition of algorithms >and assigned numbers in both documents. Given that it is the IANA >registry which is authoratative, NOT either of these documents, having >the numbers in both places will be most convenient to the >implementors, and allows us to avoid having a forward dependency from >ikev2 to the "required algorithms" draft. I strongly disagree. The major motivation for segregating the algorithm discussion is to allow the protocol document to progress up the standards track hierarchy and not be pulled back down to Proposed Standard when an algorithm decision is made. >Russ, Steve --- procedurally, do you think any of the IESG >nit-pickers/process mavens will have a problem with this approach? I have a problem. I consider myself pragmatic, but I guess you can apply the other labels if you wish. In the S/MIME WG we went through this effort for CMS. RFC 2630 became RFC 3369 and 3370. Similarly, it was done for the certificate profile in PKIX. RFC 2459 became RFC 3279 and 3280. It was not that hard, so I think we should do it right the first time. Russ From owner-ipsec@lists.tislabs.com Fri Apr 18 12:20:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJKdt2035829; Fri, 18 Apr 2003 12:20:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09920 Fri, 18 Apr 2003 14:44:48 -0400 (EDT) From: "Yaron Sheffer" To: "Stephen Kent" Cc: "Lars-Erik Jonsson \(EAB\)" , "Derek Atkins" , , Subject: RE: [rohc] RE: (in)security of ESP with header compression Date: Fri, 18 Apr 2003 21:48:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, I see a trade-off here between tweaking ROHC to deal with reordering channels (it may be easy or hard, I don't know) and tweaking the ESP *implementation* to undo such reordering. I accept that the RFC doesn't mandate or even suggest it, and from an architectural perspective it's not clean. But it's a minor change to the implementation of sequence-number handling in ESP, which can be spelled out specifically in a "Header compression over ESP" draft. Otherwise you need to work very hard to implement ROHC (or CRTP, or ECRTP) securely over ESP, going through contortions like the proposed authentication-before-compression (sorry David). Re: your comment in a previous mail, on negotiating ROHC in IKE. IKEv2 has a IPCOMP_SUPPORTED notification, which can be extended (and renamed to COMPRESSION_SUPPORTED?) by adding ROHC, ECRTP etc. This DOES NOT mean that ROHC should be an IPComp profile, only that it's negotiated in an analogous manner. IPComp makes different assumptions regarding traffic (packet lengths) compared to ROHC, and therefore probably doesn't do the job here. But this is for the ROHC people to judge. I am being somewhat simplistic, you may need to negotiate some basic compression parameters as well, just like the existing IPCOMP_{OUI, DEFLATE, LZS} values of this field. Speaking about the IPSec architecture, it's a pity that compression parameters remain an integral part of IKE v2, rather than add-ons. Best regards, Yaron -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, April 18, 2003 2:42 PM To: Yaron Sheffer Cc: Lars-Erik Jonsson (EAB); Derek Atkins; rohc@ietf.org; ipsec@lists.tislabs.com Subject: RE: [rohc] RE: (in)security of ESP with header compression At 12:59 AM +0200 4/18/03, Yaron Sheffer wrote: >ESP includes a 32-bit sequence number. It is mandatory for the sender to set >and increment it correctly, but optional for the receiver to verify it. It >is there to prevent malicious replay of messages. > >In the case of ROHC over ESP, if the receiver's policy is to delete packets >with an out-of-order ESP sequence number (possibly using a small reorder >buffer), then packets reaching the decompressor are always in order. The >channel is not reliable of course, since entire packets may be deleted. All >in all, this channel becomes analogous to your plain vanilla PPP. > >Applicability: in general, IP (and ESP) packets may be drastically >reordered, with packets coming in many seconds out of order. For Internet >telephony, those packets are useless and can be discarded on arrival. > >Under these assumptions, I don't believe any change to the operating >assumptions of ROHC, or a new ROHC profile, is needed. This is not "ROHC >over tunnels" but only "ROHC over ESP", but it's still an interesting case. > >Thanks, > Yaron I may not have understood your argument, but any solution we would adopt for IPsec use of ROHC must be general, i.e., it cannot depend on specific receiver constraints re anti-replay window parameters. Also, your message suggests a possible misunderstanding re IPsec and anti-replay: I know of no IPsec implementation that reorders packets upon arrival and doing so is certainly outside the scope of what the RFCs call for. Steve From owner-ipsec@lists.tislabs.com Fri Apr 18 12:39:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJdAt2036181; Fri, 18 Apr 2003 12:39:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09970 Fri, 18 Apr 2003 15:11:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 18 Apr 2003 15:09:53 -0400 To: "Yaron Sheffer" From: Stephen Kent Subject: RE: [rohc] RE: (in)security of ESP with header compression Cc: "Lars-Erik Jonsson \(EAB\)" , "Derek Atkins" , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:48 PM +0200 4/18/03, Yaron Sheffer wrote: >Hi Steve, > >I see a trade-off here between tweaking ROHC to deal with reordering >channels (it may be easy or hard, I don't know) and tweaking the ESP >*implementation* to undo such reordering. I accept that the RFC doesn't >mandate or even suggest it, and from an architectural perspective it's not >clean. But it's a minor change to the implementation of sequence-number >handling in ESP, which can be spelled out specifically in a "Header >compression over ESP" draft. Otherwise you need to work very hard to >implement ROHC (or CRTP, or ECRTP) securely over ESP, going through >contortions like the proposed authentication-before-compression (sorry >David). Well, ESP has been around for a while; RFC 2406 was published in November of 1998. I don't think we can reasonably ask implementors to change their implementations to accommodate ROHC. Also, as you note, it is not architecturally attractive, since IP would not reorder the traffic and IPsec tries to minimize the differences between what the IP interface does and what IPsec does. We had to impose the notion of a receive window as a tradeoff in this regard, to make anti-replay feasible yet not too hard for an IPsec implementation. Also, as we go to higher speeds, asking an IPsec implementation to buffer inbound traffic places a significant burden on the implementation, since this would have to be done in hardware that is trying to operate at line rates. >Re: your comment in a previous mail, on negotiating ROHC in IKE. IKEv2 has a >IPCOMP_SUPPORTED notification, which can be extended (and renamed to >COMPRESSION_SUPPORTED?) by adding ROHC, ECRTP etc. This DOES NOT mean that >ROHC should be an IPComp profile, only that it's negotiated in an analogous >manner. IPComp makes different assumptions regarding traffic (packet >lengths) compared to ROHC, and therefore probably doesn't do the job here. >But this is for the ROHC people to judge. I understand. >I am being somewhat simplistic, you may need to negotiate some basic >compression parameters as well, just like the existing IPCOMP_{OUI, DEFLATE, >LZS} values of this field. > >Speaking about the IPSec architecture, it's a pity that compression >parameters remain an integral part of IKE v2, rather than add-ons. IKE is really a security association management protocol and if compression is part of the SA processing, then we have to negotiate its use and parameters when we establish an SA. Key management is the easy part :-). All the complexity is in the SA management part. Steve From owner-ipsec@lists.tislabs.com Fri Apr 18 13:53:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IKrHt2037700; Fri, 18 Apr 2003 13:53:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10139 Fri, 18 Apr 2003 16:21:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Fri, 18 Apr 2003 16:16:23 -0400 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: IKE V2 Open Issues Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted, I agree with Russ that it would be cleaner, and hopefully not too hard, to split off the algorithm specs for IKE to a separate document. We're doing this for AH and ESP, as per our latest drafts which, BTW, should be in WG last call now, right? Steve From owner-ipsec@lists.tislabs.com Fri Apr 18 14:07:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IL7lt2037963; Fri, 18 Apr 2003 14:07:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10212 Fri, 18 Apr 2003 16:40:58 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16032.25540.468724.228395@pkoning.dev.equallogic.com> Date: Fri, 18 Apr 2003 16:44:52 -0400 From: Paul Koning To: yaronf@gmx.net Cc: kent@bbn.com, Lars-Erik.Jonsson@epl.ericsson.se, derek@ihtfp.com, rohc@ietf.org, ipsec@lists.tislabs.com Subject: RE: [rohc] RE: (in)security of ESP with header compression References: X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Yaron" == Yaron Sheffer writes: Yaron> Hi Steve, I see a trade-off here between tweaking ROHC to deal Yaron> with reordering channels (it may be easy or hard, I don't Yaron> know) and tweaking the ESP *implementation* to undo such Yaron> reordering. I accept that the RFC doesn't mandate or even Yaron> suggest it, and from an architectural perspective it's not Yaron> clean. But it's a minor change to the implementation of Yaron> sequence-number handling in ESP... Nonsense. It's a very major change in the implementation of ESP. ESP processes IP packets one at a time. It does not care whether they are being reordered; it does not, repeat NOT, put them in any order different from the order in which they arrived. To do what you suggest would be a large redesign, which would also completely ruin performance. ("Fragmentation considered Harmful" by Jeff Mogul explains this nicely, for a different case where the same considerations are valid.) Note also that there are a bunch of ESP implementations done in silicon. For those, what you propose is even more unreasonable than it would be for a software implementation. But I don't think any implementer of either kind of implementation would consider your proposal. paul From owner-ipsec@lists.tislabs.com Fri Apr 18 14:59:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ILx5t2039247; Fri, 18 Apr 2003 14:59:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10429 Fri, 18 Apr 2003 17:28:54 -0400 (EDT) Delivered-To: gdt@ir.bbn.com Delivered-To: gdt@wolfe.bbn.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16032.25540.468724.228395@pkoning.dev.equallogic.com> Date: Fri, 18 Apr 2003 16:44:52 -0400 From: Paul Koning To: yaronf@gmx.net Cc: kent@bbn.com, Lars-Erik.Jonsson@epl.ericsson.se, derek@ihtfp.com, rohc@ietf.org, ipsec@lists.tislabs.com Subject: RE: [rohc] RE: (in)security of ESP with header compression References: X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Scanned-By: MIMEDefang 2.17 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-6.6 required=5.0 tests=REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Yaron" == Yaron Sheffer writes: Yaron> Hi Steve, I see a trade-off here between tweaking ROHC to deal Yaron> with reordering channels (it may be easy or hard, I don't Yaron> know) and tweaking the ESP *implementation* to undo such Yaron> reordering. I accept that the RFC doesn't mandate or even Yaron> suggest it, and from an architectural perspective it's not Yaron> clean. But it's a minor change to the implementation of Yaron> sequence-number handling in ESP... Nonsense. It's a very major change in the implementation of ESP. ESP processes IP packets one at a time. It does not care whether they are being reordered; it does not, repeat NOT, put them in any order different from the order in which they arrived. To do what you suggest would be a large redesign, which would also completely ruin performance. ("Fragmentation considered Harmful" by Jeff Mogul explains this nicely, for a different case where the same considerations are valid.) Note also that there are a bunch of ESP implementations done in silicon. For those, what you propose is even more unreasonable than it would be for a software implementation. But I don't think any implementer of either kind of implementation would consider your proposal. paul From owner-ipsec@lists.tislabs.com Fri Apr 18 14:59:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ILxDt2039258; Fri, 18 Apr 2003 14:59:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10421 Fri, 18 Apr 2003 17:28:47 -0400 (EDT) Delivered-To: gdt@ir.bbn.com Delivered-To: gdt@wolfe.bbn.com Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 18 Apr 2003 15:09:53 -0400 To: "Yaron Sheffer" From: Stephen Kent Subject: RE: [rohc] RE: (in)security of ESP with header compression Cc: "Lars-Erik Jonsson (EAB)" , "Derek Atkins" , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.19 (www . roaringpenguin . com / mimedefang) X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-22.7 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:48 PM +0200 4/18/03, Yaron Sheffer wrote: >Hi Steve, > >I see a trade-off here between tweaking ROHC to deal with reordering >channels (it may be easy or hard, I don't know) and tweaking the ESP >*implementation* to undo such reordering. I accept that the RFC doesn't >mandate or even suggest it, and from an architectural perspective it's not >clean. But it's a minor change to the implementation of sequence-number >handling in ESP, which can be spelled out specifically in a "Header >compression over ESP" draft. Otherwise you need to work very hard to >implement ROHC (or CRTP, or ECRTP) securely over ESP, going through >contortions like the proposed authentication-before-compression (sorry >David). Well, ESP has been around for a while; RFC 2406 was published in November of 1998. I don't think we can reasonably ask implementors to change their implementations to accommodate ROHC. Also, as you note, it is not architecturally attractive, since IP would not reorder the traffic and IPsec tries to minimize the differences between what the IP interface does and what IPsec does. We had to impose the notion of a receive window as a tradeoff in this regard, to make anti-replay feasible yet not too hard for an IPsec implementation. Also, as we go to higher speeds, asking an IPsec implementation to buffer inbound traffic places a significant burden on the implementation, since this would have to be done in hardware that is trying to operate at line rates. >Re: your comment in a previous mail, on negotiating ROHC in IKE. IKEv2 has a >IPCOMP_SUPPORTED notification, which can be extended (and renamed to >COMPRESSION_SUPPORTED?) by adding ROHC, ECRTP etc. This DOES NOT mean that >ROHC should be an IPComp profile, only that it's negotiated in an analogous >manner. IPComp makes different assumptions regarding traffic (packet >lengths) compared to ROHC, and therefore probably doesn't do the job here. >But this is for the ROHC people to judge. I understand. >I am being somewhat simplistic, you may need to negotiate some basic >compression parameters as well, just like the existing IPCOMP_{OUI, DEFLATE, >LZS} values of this field. > >Speaking about the IPSec architecture, it's a pity that compression >parameters remain an integral part of IKE v2, rather than add-ons. IKE is really a security association management protocol and if compression is part of the SA processing, then we have to negotiate its use and parameters when we establish an SA. Key management is the easy part :-). All the complexity is in the SA management part. Steve From owner-ipsec@lists.tislabs.com Fri Apr 18 14:59:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ILxSt2039270; Fri, 18 Apr 2003 14:59:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10430 Fri, 18 Apr 2003 17:28:54 -0400 (EDT) Delivered-To: gdt@ir.bbn.com Delivered-To: gdt@wolfe.bbn.com From: "Yaron Sheffer" To: "Stephen Kent" Cc: "Lars-Erik Jonsson (EAB)" , "Derek Atkins" , , Subject: RE: [rohc] RE: (in)security of ESP with header compression Date: Fri, 18 Apr 2003 21:48:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Scanned-By: MIMEDefang 2.19 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-16.9 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,MSGID_GOOD_EXCHANGE, ORIGINAL_MESSAGE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, I see a trade-off here between tweaking ROHC to deal with reordering channels (it may be easy or hard, I don't know) and tweaking the ESP *implementation* to undo such reordering. I accept that the RFC doesn't mandate or even suggest it, and from an architectural perspective it's not clean. But it's a minor change to the implementation of sequence-number handling in ESP, which can be spelled out specifically in a "Header compression over ESP" draft. Otherwise you need to work very hard to implement ROHC (or CRTP, or ECRTP) securely over ESP, going through contortions like the proposed authentication-before-compression (sorry David). Re: your comment in a previous mail, on negotiating ROHC in IKE. IKEv2 has a IPCOMP_SUPPORTED notification, which can be extended (and renamed to COMPRESSION_SUPPORTED?) by adding ROHC, ECRTP etc. This DOES NOT mean that ROHC should be an IPComp profile, only that it's negotiated in an analogous manner. IPComp makes different assumptions regarding traffic (packet lengths) compared to ROHC, and therefore probably doesn't do the job here. But this is for the ROHC people to judge. I am being somewhat simplistic, you may need to negotiate some basic compression parameters as well, just like the existing IPCOMP_{OUI, DEFLATE, LZS} values of this field. Speaking about the IPSec architecture, it's a pity that compression parameters remain an integral part of IKE v2, rather than add-ons. Best regards, Yaron -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, April 18, 2003 2:42 PM To: Yaron Sheffer Cc: Lars-Erik Jonsson (EAB); Derek Atkins; rohc@ietf.org; ipsec@lists.tislabs.com Subject: RE: [rohc] RE: (in)security of ESP with header compression At 12:59 AM +0200 4/18/03, Yaron Sheffer wrote: >ESP includes a 32-bit sequence number. It is mandatory for the sender to set >and increment it correctly, but optional for the receiver to verify it. It >is there to prevent malicious replay of messages. > >In the case of ROHC over ESP, if the receiver's policy is to delete packets >with an out-of-order ESP sequence number (possibly using a small reorder >buffer), then packets reaching the decompressor are always in order. The >channel is not reliable of course, since entire packets may be deleted. All >in all, this channel becomes analogous to your plain vanilla PPP. > >Applicability: in general, IP (and ESP) packets may be drastically >reordered, with packets coming in many seconds out of order. For Internet >telephony, those packets are useless and can be discarded on arrival. > >Under these assumptions, I don't believe any change to the operating >assumptions of ROHC, or a new ROHC profile, is needed. This is not "ROHC >over tunnels" but only "ROHC over ESP", but it's still an interesting case. > >Thanks, > Yaron I may not have understood your argument, but any solution we would adopt for IPsec use of ROHC must be general, i.e., it cannot depend on specific receiver constraints re anti-replay window parameters. Also, your message suggests a possible misunderstanding re IPsec and anti-replay: I know of no IPsec implementation that reorders packets upon arrival and doing so is certainly outside the scope of what the RFCs call for. Steve From owner-ipsec@lists.tislabs.com Fri Apr 18 15:00:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IM0Kt2039310; Fri, 18 Apr 2003 15:00:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10428 Fri, 18 Apr 2003 17:28:49 -0400 (EDT) Delivered-To: gdt@ir.bbn.com Delivered-To: gdt@wolfe.bbn.com Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Fri, 18 Apr 2003 16:16:23 -0400 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: IKE V2 Open Issues Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.19 (www . roaringpenguin . com / mimedefang) X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-10.9 required=5.0 tests=AWL,CALL_NOW version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted, I agree with Russ that it would be cleaner, and hopefully not too hard, to split off the algorithm specs for IKE to a separate document. We're doing this for AH and ESP, as per our latest drafts which, BTW, should be in WG last call now, right? Steve From owner-ipsec@lists.tislabs.com Fri Apr 18 18:49:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J1nlt2045312; Fri, 18 Apr 2003 18:49:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11269 Fri, 18 Apr 2003 21:18:44 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66C69@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Theodore Ts'o'" , Darren Dukes Cc: ipsec@lists.tislabs.com Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Date: Fri, 18 Apr 2003 18:16:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I vote for CP. And Darren and I can submit the draft we presented in SF to make life easy for everyone to implement w/ DHCP, RADIUS, LDAP, etc. > -----Original Message----- > From: Theodore Ts'o [mailto:tytso@mit.edu] > Sent: Friday, April 11, 2003 12:29 PM > To: Darren Dukes > Cc: ipsec@lists.tislabs.com > Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs > Configuration Payload > > > Darren, thanks for your good summary of the pros versus cons of DHCP > over IKE vs. Configuration Payload. Only one thing was missing: your > weighing on which proposal you think is superior. :-) > > To the rest of the list, the amount of comments on this item has been > extremely underwhelming. Barbara and I would like to call on > supporters of the two proposals to send their comments to the list > ASAP. We note that in San Francisco the wg had decided that in the > absence of strong support, the default would be to stay with the > existing text in the ikev2 document (Configuration Payload). > > - Ted > From owner-ipsec@lists.tislabs.com Fri Apr 18 18:57:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J1vjt2045394; Fri, 18 Apr 2003 18:57:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11293 Fri, 18 Apr 2003 21:30:47 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66C6B@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Charlie_Kaufman@notesdev.ibm.com'" , "Theodore Ts'o" Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Date: Fri, 18 Apr 2003 18:29:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Charlie_Kaufman@notesdev.ibm.com > [mailto:Charlie_Kaufman@notesdev.ibm.com] > Sent: Sunday, April 13, 2003 7:19 PM > To: Theodore Ts'o > Cc: ipsec@lists.tislabs.com; owner-ipsec@lists.tislabs.com > Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs > Configuration Payload > --SNIP-- > > Having read Tero's DHCP over IKE proposal, I continue to > believe that while > either DHCP or CP could be made to work that CP is the better > choice for > reasons of simplicity. (If I were king, I'd pick a protocol that was > simpler than either). for example? But then again, its too late for that ;-) > Tero's proposal describes how to deal with all these cases, but it's > awkward. agreed. Though CP isn't too much less awkward, we are all just more used to it since we all implemented it already (or dang close to it) for IKEv1 ModeCFG. > When the IKE responder is allocating addresses out of its own pool or > getting them using RADIUS, it appears to me that processing > would be more > complex translating them to DHCP than translating them to CP. also agreed. But that's because CP was sort of designed for more with RADIUS in mind than DHCP. Is that right, Darren? > My intuition > is that having the IKE responder lease addresses from its own > pool will be > the common case, since if the address is acquired from > elsewhere the IKE > responder will have to take some action to get traffic to the > allocated > address routed to it (most likely by responding to ARPs). Usually the whole pool and the routes to it are already entered in the internal network's routing infrastructure. This is not an issue in all the networks I've seen. Gregory. From owner-ipsec@lists.tislabs.com Fri Apr 18 19:00:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J20nt2045448; Fri, 18 Apr 2003 19:00:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11307 Fri, 18 Apr 2003 21:34:49 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66C6C@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'sommerfeld@east.sun.com'" , Michael Thomas Cc: Charlie_Kaufman@notesdev.ibm.com, "Theodore Ts'o" , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Date: Fri, 18 Apr 2003 18:33:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > Sent: Monday, April 14, 2003 1:03 PM > To: Michael Thomas > Cc: Charlie_Kaufman@notesdev.ibm.com; Theodore Ts'o; > ipsec@lists.tislabs.com; owner-ipsec@lists.tislabs.com > Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs > Configuration Payload > > > > > Well, there's that too, but I get the impression > > that config-over-IKE is pretty well ingrained so > > trying to excise that mindset at this point is > > pretty hopeless. Thus to my mind, lesser of evils > > is to beg, borrow and steal and punt as much work > > as possible to other wg's that actually care about > > this sort of thing... > > Indeed. My sense is that configuration is not an area of expertise > for the members of this WG, and incorporating DHCP as-is is a better > solution than trying to reinvent a wheel here. > > - Bill so the problem here is that we are assuming that the world uses only DHCP to configure, when, from all my customer contact, it seems to me that people use DHCP on local networks, but for remote access, especially the very large ones, they tend to use RADIUS for configuration and authentication. This is ESPECIALLY true of all my large enterprise customers. From owner-ipsec@lists.tislabs.com Fri Apr 18 19:07:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J27Yt2045578; Fri, 18 Apr 2003 19:07:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11322 Fri, 18 Apr 2003 21:39:50 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66C6A@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Scott G. Kelly'" , ipsec@lists.tislabs.com Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Date: Fri, 18 Apr 2003 18:22:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I see this as both a pro and con. PRO - it gets it done earlier, in terms of the exchange process, whereas the doc we wrote has the more extensive DHCP config occuring after CHILD-SA; only the basics are done in IKE. CON - it makes IKE heavier, more bytes (the more config options returned, the more bytes) and thus IKE will take longer time-wise to complete. Gregory. > -----Original Message----- > From: Scott G. Kelly [mailto:scott@airespace.com] > Sent: Monday, April 14, 2003 9:37 AM > To: ipsec@lists.tislabs.com > Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs > Configuration Payload > > > > I think Darren's summary is pretty accurate. It's kind of a toss up. > However, one difference that I note is that with the dhcp > approach, all > client config is (potentially) done prior to the instantiation of the > child sa. I'm not sure if this is a benefit or not, but it might be. > > Scott > From owner-ipsec@lists.tislabs.com Fri Apr 18 19:12:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J2C5t2045778; Fri, 18 Apr 2003 19:12:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11334 Fri, 18 Apr 2003 21:43:51 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66C6E@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'ddukes@cisco.com'" , Derek Atkins , Michael Richardson Cc: ipsec@lists.tislabs.com Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Date: Fri, 18 Apr 2003 18:42:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Darren Dukes [mailto:ddukes@cisco.com] > Sent: Tuesday, April 15, 2003 11:38 AM > To: Derek Atkins; Michael Richardson > Cc: ipsec@lists.tislabs.com > Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs > Configuration Payload > --SNIP-- > > > > On another note, can you even start the configuration process before > > EAP finishes? I'm not convinced you can run it > concurrently with EAP, > > which implies that the extra messages from EAP and then DHCP would > > have to be serialized, making the exchange even longer! I say this > > because I don't see how a server can respond with a DHCPOFFER until > > the client has authenticated (e.g. EAP finished). > > > > Am I missing something? > > Nope, you are correct. DHCP should be done after EAP, the > same as CP is > done after/with the last EAP message. I think > implementations could get > clever and block DHCPREQUESTs until after the client > authenticates, but it > seems simpler to require the client side to start the > DHCP-over-IKE exchange > after EAP completes and the client is authenticated. > In the case of a RADIUS back-end, the EAP is absolutely required, because it is the only way to get the credentials by which to lookup/validate the user, by which to know which configuration parameters to offer them. This is all detailed out in the draft darren and I wrote. (We never got to submitting it... sorry). It's at VPNC: From owner-ipsec@lists.tislabs.com Fri Apr 18 19:18:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J2I8t2047471; Fri, 18 Apr 2003 19:18:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11346 Fri, 18 Apr 2003 21:47:54 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66C6F@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Tero Kivinen'" , ipsec@lists.tislabs.com Cc: derek@ihtfp.com, Michael Richardson Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Date: Fri, 18 Apr 2003 18:46:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: Tuesday, April 15, 2003 2:30 PM --SNIP-- > Ps. I will be on the vacation for about two weeks starting tomorrow, > so I might not be able to reply to questions before that. He's not here to defend himself. CP wins!!!! Just Kidding ;-) From owner-ipsec@lists.tislabs.com Fri Apr 18 19:39:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J2dSt2047888; Fri, 18 Apr 2003 19:39:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11407 Fri, 18 Apr 2003 22:10:04 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66C6D@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'jknowles@SonicWALL.com'" , Charlie_Kaufman@notesdev.ibm.com, tytso@mit.edu Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Date: Fri, 18 Apr 2003 18:36:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: jknowles@SonicWALL.com [mailto:jknowles@SonicWALL.com] > Sent: Monday, April 14, 2003 3:00 PM > To: Charlie_Kaufman@notesdev.ibm.com; tytso@mit.edu > Cc: ipsec@lists.tislabs.com; owner-ipsec@lists.tislabs.com > Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs > Configuration Payload > --SNIP-- > Lately, I've been wondering if we can't just add an optional > DHCP CP payload type. Not sure if that would make everybody > happy or make everybody mad. > That is what Darren Dukes and I proposed in the doc we wrote and presented in SF. Send a DHCP server addr in CP along w/ IP and DNS/WINS (if needed) and do the rest of the DHCP extensions via INFORM in protected by CHILD-SA. From owner-ipsec@lists.tislabs.com Fri Apr 18 19:55:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J2tot2051150; Fri, 18 Apr 2003 19:55:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11504 Fri, 18 Apr 2003 22:25:20 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66C66@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Theodore Ts'o'" , Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: RE: Confirm decision on identity handling. Date: Fri, 18 Apr 2003 17:58:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am pretty darn close to agreeing with this text. I agree completely with the intent. I would just like to see it word-smithed to be a bit clearer, in order to attain "predictable interoperability," as Steve would say. Let's make it very explicit. My proposal below attempts to say: - the base interoperable way is DO NOT CHECK ID matches cert - implementations MUST be able to handle IDs that do not match cert contents - to allow for local security policy decisions, implementations MAY be configured to match. - Matching will only interoperate if both sides support the feature and have matching turned on. Proposed Text: The Identification Payload, denoted ID in this memo, allows peers to assert an identify to one another. The receiver will interpret the identity payload as a unique identity string for policy lookup in its SPD. Implementations MUST NOT mandate a check that the ID match anything in the certificate presented, and therefore MUST be able to accept the case where the identity presented does NOT match the certificate contents. To allow for more stringent local security policy, implementations MAY offer a configuration option to check that the idenity presented in the identity payload matches the equivalent identity type in the presented certificate. In such a case, interoperability will only be achieved by two consenting parties who both have such configuration options available on their respective gateways and who both enable the option. Gregory. > -----Original Message----- > From: Theodore Ts'o [mailto:tytso@mit.edu] > Sent: Friday, April 11, 2003 12:26 PM > To: Paul Hoffman / VPNC > Cc: ipsec@lists.tislabs.com > Subject: Re: Confirm decision on identity handling. > > > On Wed, Apr 09, 2003 at 05:53:10PM -0700, Paul Hoffman / VPNC wrote: > > > > We are better off with just the first sentence and a > revision of the > > one proposed here by Ted: > > > > The Identification Payload, denoted ID in this memo, > allows peers to > > assert an identify to one another. This identity may be > used for policy > > lookup, but does not necessarily have to match anything > in the CERT > > payload; both fields may be used by an implementation to perform > > access control decisions. > > Paul's proposed revision seems clearer and reflects the discussion in > San Francisco. Does anybody have any problems with this text, or > should we just go with it? > > - Ted > From owner-ipsec@lists.tislabs.com Fri Apr 18 20:30:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J3UEt2052021; Fri, 18 Apr 2003 20:30:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11679 Fri, 18 Apr 2003 22:58:50 -0400 (EDT) Message-Id: <200304190302.h3J32Rwm024184@thunk.east.sun.com> From: Bill Sommerfeld To: Gregory Lebovitz cc: "'jknowles@SonicWALL.com'" , Charlie_Kaufman@notesdev.ibm.com, tytso@mit.edu, ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload In-Reply-To: Your message of "Fri, 18 Apr 2003 18:36:12 PDT." <541402FFDC56DA499E7E13329ABFEA87E66C6D@SARATOGA.netscreen.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 18 Apr 2003 23:02:27 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Lately, I've been wondering if we can't just add an optional > > DHCP CP payload type. Not sure if that would make everybody > > happy or make everybody mad. > > > > That is what Darren Dukes and I proposed in the doc we wrote and presented > in SF. Send a DHCP server addr in CP along w/ IP and DNS/WINS (if needed) > and do the rest of the DHCP extensions via INFORM in protected by CHILD-SA. no, that's not the same thing. From owner-ipsec@lists.tislabs.com Sat Apr 19 19:08:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K28Kt2028175; Sat, 19 Apr 2003 19:08:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA14313 Sat, 19 Apr 2003 21:32:42 -0400 (EDT) \Received: from sentry.rv.nailabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id EAA08147 Fri, 18 Apr 2003 04:23:39 -0400 (EDT) Message-ID: From: "Lars-Erik Jonsson (EAB)" To: Mikael Degermark , Yaron Sheffer Cc: rohc@ietf.org, ipsec@lists.tislabs.com Subject: RE: [rohc] RE: (in)security of ESP with header compression Date: Fri, 18 Apr 2003 10:26:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, I just assumed that such a "tunnel sequence number" would be incrementally set. Otherwise it would not be useable for detecting out-of-order packets. /L-E > I believe that the compressor also needs to be involved, > as reordering can only be detected by the decompressor > if the compressor ensures that the sequence numbers it > sends out are ordered. > > Is there still an equivalent to the IPv4 protocol or IPv6 > Next Header field in the new ESP header? > > > > This is the approach we have previously discussed in ROHC > > (just informally), and most tunneling protocols seem to have > > a similar sequence number. The solution would then just be > > a modified decompressor, making use of the tunnel sequence > > number. > > > > But still, someone should look more carefully at this, and > > write something. From owner-ipsec@lists.tislabs.com Sat Apr 19 19:08:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K28Kt2028176; Sat, 19 Apr 2003 19:08:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA14302 Sat, 19 Apr 2003 21:31:44 -0400 (EDT) Message-ID: <00ac01c30581$a326b990$0801a8c0@gaston> From: "Mikael Degermark" To: "Lars-Erik Jonsson \(EAB\)" , "Yaron Sheffer" Cc: , References: Subject: Re: [rohc] RE: (in)security of ESP with header compression Date: Fri, 18 Apr 2003 01:08:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I believe that the compressor also needs to be involved, as reordering can only be detected by the decompressor if the compressor ensures that the sequence numbers it sends out are ordered. Is there still an equivalent to the IPv4 protocol or IPv6 Next Header field in the new ESP header? Micke ----- Original Message ----- From: "Lars-Erik Jonsson (EAB)" To: "Yaron Sheffer" Cc: ; Sent: Friday, April 18, 2003 12:34 AM Subject: RE: [rohc] RE: (in)security of ESP with header compression > Yaron, > > > ESP includes a 32-bit sequence number. It is mandatory for > > the sender to set and increment it correctly, but optional > > for the receiver to verify it. It is there to prevent > > malicious replay of messages. > > > > Under these assumptions, I don't believe any change to the > > operating assumptions of ROHC, or a new ROHC profile, is > > needed. This is not "ROHC over tunnels" but only "ROHC over > > ESP", but it's still an interesting case. > > This is the approach we have previously discussed in ROHC > (just informally), and most tunneling protocols seem to have > a similar sequence number. The solution would then just be > a modified decompressor, making use of the tunnel sequence > number. > > But still, someone should look more carefully at this, and > write something. > > Rgds, > /L-E > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > From owner-ipsec@lists.tislabs.com Sat Apr 19 19:08:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K28Kt2028177; Sat, 19 Apr 2003 19:08:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA14285 Sat, 19 Apr 2003 21:30:38 -0400 (EDT) Message-ID: From: "Lars-Erik Jonsson (EAB)" To: Yaron Sheffer Cc: rohc@ietf.org, ipsec@lists.tislabs.com Subject: RE: [rohc] RE: (in)security of ESP with header compression Date: Fri, 18 Apr 2003 09:34:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yaron, > ESP includes a 32-bit sequence number. It is mandatory for > the sender to set and increment it correctly, but optional > for the receiver to verify it. It is there to prevent > malicious replay of messages. > > Under these assumptions, I don't believe any change to the > operating assumptions of ROHC, or a new ROHC profile, is > needed. This is not "ROHC over tunnels" but only "ROHC over > ESP", but it's still an interesting case. This is the approach we have previously discussed in ROHC (just informally), and most tunneling protocols seem to have a similar sequence number. The solution would then just be a modified decompressor, making use of the tunnel sequence number. But still, someone should look more carefully at this, and write something. Rgds, /L-E From owner-ipsec@lists.tislabs.com Sat Apr 19 19:09:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K29Rt2028218; Sat, 19 Apr 2003 19:09:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA14278 Sat, 19 Apr 2003 21:26:37 -0400 (EDT) Message-ID: <3E9F86E9.8070103@roc.co.in> Date: Fri, 18 Apr 2003 10:32:33 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: DPD Notification messages in IKEv2 Content-Type: multipart/alternative; boundary="------------070509060603060205070009" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------070509060603060205070009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I did not see any notification messages related to DPD in IKEv2-06 specifications. Is there any plan to put these notifications in next version. Regards, Ravi -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------070509060603060205070009 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Hi,
I did not see any notification messages related to DPD in IKEv2-06 specifications.
Is there any plan to put these notifications in next version.
Regards,
Ravi

--
signature

The views presented in this mail are completely mine. The company is not responsible for whatsoever.
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page


--------------070509060603060205070009-- From owner-ipsec@lists.tislabs.com Sat Apr 19 19:09:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K29Tt2028228; Sat, 19 Apr 2003 19:09:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA14279 Sat, 19 Apr 2003 21:26:38 -0400 (EDT) Message-ID: <3E9F87B2.7070902@roc.co.in> Date: Fri, 18 Apr 2003 10:35:54 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Peer liveliness Content-Type: multipart/alternative; boundary="------------040705030305030501030908" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------040705030305030501030908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I was going through several drafts related to peer liveliness. But, some of practical problems faced in actual deployment may not be solved by these proposals. INITIAL_CONTACT Notification : It indicates that the Peer was dead and cameback. DPD: Checks the liveliness of the peer. I feel, we require interoperable solution to check liveliness of SA ie Dead Peer SA detection (DPSD). DPD specification can be enhanced to achieve this. Protocol-ID and SPI fields can be made mandatory. Protocol-ID can be ESP/AH/IKE. SPI : In case of IKE, it could be cookies and in case of ESP/AH, it is SPI (inbound SA's SPI on the peer). If peer is not dead, but SAs were deleted either due to temporary failure OR due to restarting of some processes in the system can be detected with this mechanism. Does this makes sense? If so, I can contribute text to this effect. Regards, Ravi -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------040705030305030501030908 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
 Hi,
  I was going through several drafts related to peer liveliness. But, some of practical
  problems faced in actual deployment may not be solved by these proposals.
  INITIAL_CONTACT Notification : It indicates that the Peer was dead and cameback.
  DPD:  Checks the liveliness of the peer.
  I feel, we require interoperable solution to check liveliness of SA ie Dead Peer SA detection
 (DPSD). 
  DPD specification can be enhanced to achieve this.
  Protocol-ID and SPI fields can be made mandatory.
  Protocol-ID can be ESP/AH/IKE.
  SPI : In case of IKE, it could be cookies and in case of ESP/AH, it is SPI (inbound SA's SPI
       on the peer).
  If peer is not dead, but SAs were deleted either due to temporary failure OR due to 
  restarting of some processes in the system can be detected with this mechanism.
  Does this makes sense? If so, I can contribute text to this effect.
Regards,
Ravi

--
signature

The views presented in this mail are completely mine. The company is not responsible for whatsoever.
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page


--------------040705030305030501030908-- From owner-ipsec@lists.tislabs.com Mon Apr 21 08:50:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LFoHt2051038; Mon, 21 Apr 2003 08:50:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18138 Mon, 21 Apr 2003 11:17:25 -0400 (EDT) Message-Id: <200304211521.h3LFLDwm010130@thunk.east.sun.com> From: Bill Sommerfeld To: Gregory Lebovitz cc: "'jknowles@SonicWALL.com'" , Charlie_Kaufman@notesdev.ibm.com, tytso@mit.edu, ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload In-Reply-To: Your message of "Mon, 21 Apr 2003 08:08:17 PDT." <541402FFDC56DA499E7E13329ABFEA87E66C74@SARATOGA.netscreen.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 21 Apr 2003 11:21:13 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > > Lately, I've been wondering if we can't just add an optional > > > > DHCP CP payload type. Not sure if that would make everybody > > > > happy or make everybody mad. > > > That is what Darren Dukes and I proposed in the doc we wrote and > > > presented in SF. Send a DHCP server addr in CP along w/ IP and > > > DNS/WINS (if needed) and do the rest of the DHCP extensions via > > > INFORM in protected by CHILD-SA. > > no, that's not the same thing. > care to clarify? A "dhcp cp payload type" would carry DHCP inside CP inside IKE, not send a referral to a DHCP server. - Bill From owner-ipsec@lists.tislabs.com Mon Apr 21 08:50:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LFoJt2051039; Mon, 21 Apr 2003 08:50:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18105 Mon, 21 Apr 2003 11:10:12 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66C74@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'sommerfeld@east.sun.com'" , Gregory Lebovitz Cc: "'jknowles@SonicWALL.com'" , Charlie_Kaufman@notesdev.ibm.com, tytso@mit.edu, ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Date: Mon, 21 Apr 2003 08:08:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > Lately, I've been wondering if we can't just add an optional > > > DHCP CP payload type. Not sure if that would make everybody > > > happy or make everybody mad. > > > > > > > That is what Darren Dukes and I proposed in the doc we > wrote and presented > > in SF. Send a DHCP server addr in CP along w/ IP and > DNS/WINS (if needed) > > and do the rest of the DHCP extensions via INFORM in > protected by CHILD-SA. > > no, that's not the same thing. > care to clarify? From owner-ipsec@lists.tislabs.com Mon Apr 21 11:22:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LIMWt2057506; Mon, 21 Apr 2003 11:22:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18691 Mon, 21 Apr 2003 13:50:12 -0400 (EDT) From: jknowles@SonicWALL.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Date: Mon, 21 Apr 2003 10:53:35 -0700 Message-ID: <385918F84B55DC4E9542E0A4812F413106E293@us0exb01.us.sonicwall.com> Thread-Topic: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload Thread-Index: AcMGFNZ9cu/u9DvoSYuju+mrjvivmgCGWZvQ To: , , Cc: , X-OriginalArrivalTime: 21 Apr 2003 17:53:35.0625 (UTC) FILETIME=[EE501790:01C3082E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA18688 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Gregory, Well, I probably wasn't clear, but I wasn't referring to sending the server addr. I'd like to see a CP payload type that encapsulates the DHCP. Tunnelling DHCP in CP in IKE. Getting kinda waist-deep here, but it gives me what I'd like, which is a way to get a DHCP packet generated by the OS over to the DHCP server. Just to clarify Ted's list, without this mechanism, I'd vote for DHCP-over-IKE, as CP alone does not provide what I want. Regards, Jim -----Original Message----- From: Gregory Lebovitz [mailto:Gregory@netscreen.com] Sent: Friday, April 18, 2003 6:36 PM To: Jim Knowles; Charlie_Kaufman@notesdev.ibm.com; tytso@mit.edu Cc: ipsec@lists.tislabs.com; owner-ipsec@lists.tislabs.com Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload > -----Original Message----- > From: jknowles@SonicWALL.com [mailto:jknowles@SonicWALL.com] > Sent: Monday, April 14, 2003 3:00 PM > To: Charlie_Kaufman@notesdev.ibm.com; tytso@mit.edu > Cc: ipsec@lists.tislabs.com; owner-ipsec@lists.tislabs.com > Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs > Configuration Payload > --SNIP-- > Lately, I've been wondering if we can't just add an optional > DHCP CP payload type. Not sure if that would make everybody > happy or make everybody mad. > That is what Darren Dukes and I proposed in the doc we wrote and presented in SF. Send a DHCP server addr in CP along w/ IP and DNS/WINS (if needed) and do the rest of the DHCP extensions via INFORM in protected by CHILD-SA. From owner-ipsec@lists.tislabs.com Mon Apr 21 13:05:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LK54t2059847; Mon, 21 Apr 2003 13:05:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19070 Mon, 21 Apr 2003 15:30:22 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66C82@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Andrew Krywaniuk'" , Gregory Lebovitz , ipsec@lists.tislabs.com Subject: RE: Confirm decision on identity handling. Date: Mon, 21 Apr 2003 12:29:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >To allow for more stringent local security policy, > implementations MAY > >offer > >a configuration option to check that the idenity presented > in the identity > >payload matches the equivalent identity type in the > presented certificate. > > I guess my main question would be, in what way does this > allow for a "more > stringent local security policy"? If alice and amy are both users with valid certs, amy cannot connect to bob using her own cert, but using alice's identity in the identity payload. I personally don't think it is a big deal, but Steve Kent has said he thinks it is, and I can see higher security organizations wanting it. From owner-ipsec@lists.tislabs.com Mon Apr 21 14:16:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LLGQt2061716; Mon, 21 Apr 2003 14:16:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19516 Mon, 21 Apr 2003 16:44:01 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: draft-ietf-ipsec-ikev2-07.txt To: IP Security List X-Mailer: Lotus Notes Build V601_12032002NP December 03, 2002 Message-ID: Date: Mon, 21 Apr 2003 16:41:27 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04072003NP|April 07, 2003) at 04/21/2003 04:48:39 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I just submitted draft-ietf-ipsec-ikev2-07.txt to the I-D editor, copying Paul Hoffman in hopes he will post it on his web site more quickly than the I-D editor can turn it around. I believe I reflected that changes called for in Ted's instructions. There are a couple of issues that I wasn't quite sure how to resolve, and didn't want to hold things up waiting: 1) NAT Traversal. While I had intended that this document obsolete the previous NAT Traversal RFCs and proposals, I can see from some comments from Tero that I didn't. He proposed some text that would have made a normative reference to an I-D, which seemed wrong. The current draft does not address having an endpoint finding itself behind a NAT adjusting the rate at which it sends keepalives to keep the address/port mapping active, nor does it address the mechanisms for coping with addresses and ports dynamically changing (which can happen with NATs and with IP Mobility). The current spec does not prohibit such mechanisms, but it doesn't specify them either. My inclination is to leave that for a subsequent effort, possibly to be folded into a future revision when it stabilizes. 2) I wasn't quite sure what to do with this one: 6. Remove language about required cryptographic algorithms. This question of which algorithms are mandatory to implement is to be deferred to another specification, which Jeff Schiller is authoring. Based on the discussion on the list, I got the impression that I was supposed to leave the tables of assigned codes for the algorithms, but remove specification of which are mandatory. But I thought I had done that in -06. I'm going to need more specific instructions on what to take out. Seeing the companion specification might help. There were lots of small wording changes proposed on the list (and evoking no comments) that I included, but some that I did not. I still intend to respond on the list with an explanation of why I didn't think the proposed change would work, but I haven't yet. There are undoubtedly other proposed changes that I either missed or didn't know how to handle. Please repost them, since at this late date I don't feel free to incorporate much more than spelling errors without consensus on the list. --Charlie From owner-ipsec@lists.tislabs.com Mon Apr 21 16:06:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LN6Ft2064379; Mon, 21 Apr 2003 16:06:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA19772 Mon, 21 Apr 2003 18:33:02 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 21 Apr 2003 14:49:44 -0700 To: Charlie_Kaufman@notesdev.ibm.com, IP Security List From: Paul Hoffman / VPNC Subject: Re: draft-ietf-ipsec-ikev2-07.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:41 PM -0400 4/21/03, Charlie_Kaufman@notesdev.ibm.com wrote: >I just submitted draft-ietf-ipsec-ikev2-07.txt to the I-D editor, copying >Paul Hoffman in hopes he will post it on his web site more quickly than the >I-D editor can turn it around. No problem. It is now available at . That link will be removed when the I-D editor posts the draft officially. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Apr 21 16:16:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LNGTt2064831; Mon, 21 Apr 2003 16:16:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA19815 Mon, 21 Apr 2003 18:51:31 -0400 (EDT) Reply-To: From: "Darren Dukes" To: "Ravi" , Subject: RE: Peer liveliness Date: Mon, 21 Apr 2003 14:27:46 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: <3E9F87B2.7070902@roc.co.in> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id SAA19812 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Ravi > Sent: Friday, April 18, 2003 1:06 AM > To: ipsec@lists.tislabs.com > Subject: Peer liveliness > > > Hi, > I was going through several drafts related to peer liveliness. > But, some of practical > problems faced in actual deployment may not be solved by these > proposals. > INITIAL_CONTACT Notification : It indicates that the Peer was > dead and cameback. > DPD: Checks the liveliness of the peer. > I feel, we require interoperable solution to check liveliness > of SA ie Dead Peer SA detection > (DPSD). I believe INVALID_SPI does what you are looking for. If I receive an INVALID_SPI notify via an IKE SA I know to delete the SA and traffic will bring up a new one. Darren > DPD specification can be enhanced to achieve this. > Protocol-ID and SPI fields can be made mandatory. > Protocol-ID can be ESP/AH/IKE. > SPI : In case of IKE, it could be cookies and in case of > ESP/AH, it is SPI (inbound SA's SPI > on the peer). > If peer is not dead, but SAs were deleted either due to > temporary failure OR due to > restarting of some processes in the system can be detected with > this mechanism. > Does this makes sense? If so, I can contribute text to this effect. > Regards, > Ravi > > > > -- > > > The views presented in this mail are completely mine. The company > is not responsible for whatsoever. > > > Ravi Kumar CH > Rendezvous On Chip (i) Pvt Ltd > Hyderabad, India > Ph: +91-40-2335 1214 / 1175 / 1184 > > ROC home page From owner-ipsec@lists.tislabs.com Mon Apr 21 19:34:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3M2Y9t2069449; Mon, 21 Apr 2003 19:34:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA20421 Mon, 21 Apr 2003 22:03:47 -0400 (EDT) X-Originating-IP: [64.114.95.129] X-Originating-Email: [askrywan@hotmail.com] From: "Andrew Krywaniuk" To: Gregory@netscreen.com, ipsec@lists.tislabs.com Subject: RE: Confirm decision on identity handling. Date: Mon, 21 Apr 2003 17:05:57 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Apr 2003 21:05:57.0278 (UTC) FILETIME=[CDAC93E0:01C30849] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > >To allow for more stringent local security policy, > > implementations MAY > > >offer > > >a configuration option to check that the idenity presented > > in the identity > > >payload matches the equivalent identity type in the > > presented certificate. > > > > I guess my main question would be, in what way does this > > allow for a "more > > stringent local security policy"? > >If alice and amy are both users with valid certs, amy cannot connect to bob >using her own cert, but using alice's identity in the identity payload. > >I personally don't think it is a big deal, but Steve Kent has said he >thinks >it is, and I can see higher security organizations wanting it. This is what I described a few days ago as the "gratuitous id check". However, I don't see how this is providing a more stringent security policy. If Amy is not allowed to talk to Bob, then the authentication should fail regardless of what she puts in her id payload, since the data in the certificate is authoritative. In its modern incarnation, the id payload is supposed to be a key for policy lookups. Once you finish the policy lookup, you should then be able to ignore the id and base all further decisions on the data in the certificate. Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From owner-ipsec@lists.tislabs.com Tue Apr 22 11:36:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MIaNt2038313; Tue, 22 Apr 2003 11:36:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21883 Tue, 22 Apr 2003 13:47:45 -0400 (EDT) Date: Tue, 22 Apr 2003 10:52:37 -0700 (PDT) From: Jan Vilhuber To: ipsec@lists.tislabs.com Subject: ESP and header compression drafts (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since there's been some discussion on this topic recently (sorry I didn't partake), I thought I'd point out two recent drafts I submitted. draft-vilhuber-hcoip-00.txt and draft-vilhuber-hcoesp-00.txt go together. draft-vilhuber-hcoesp-00.txt has a pretty detailed security analysis (or maybe I should call it a potential pitfalls analysis) in it. Comments and feedback is appreciated. jan ---------- Forwarded message ---------- Date: Fri, 31 Jan 2003 12:57:05 -0800 (PST) From: Jan Vilhuber To: ipsec@lists.tislabs.com Subject: [AVT] I-D ACTION:draft-vilhuber-hcoesp-00.txt (fwd) FYI. This is a use of draft-vilhuber-hcoip-00.txt (i.e. read that one first). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 "If Jack Valenti had been around at the time of Gutenberg he would have organized the monks to come and burn down the printing press." -- Harris Miller, president of the ITAA ---------- Forwarded message ---------- Date: Wed, 29 Jan 2003 06:54:08 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-vilhuber-hcoesp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP header compression in IPsec ESP Author(s) : J. Vilhuber Filename : draft-vilhuber-hcoesp-00.txt Pages : 8 Date : 2003-1-28 This draft outlines how to use IP Header compression over IP tunnels [HCOIP] inside IPsec ESP [ESP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vilhuber-hcoesp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-vilhuber-hcoesp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-vilhuber-hcoesp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ipsec@lists.tislabs.com Tue Apr 22 11:36:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MIaPt2038316; Tue, 22 Apr 2003 11:36:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21908 Tue, 22 Apr 2003 13:49:54 -0400 (EDT) Message-ID: <3EA5816E.FA07BD95@airespace.com> Date: Tue, 22 Apr 2003 10:52:46 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66C82@SARATOGA.netscreen.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2003 17:54:11.0560 (UTC) FILETIME=[2E251680:01C308F8] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just wanted to comment on this: I agree with Paul. Since we seem unable to produce a coherent specification with respect to PKI-related policies, when using certs the ID payload should not be present. If we cannot agree on this, then the next best position is that the ID payload must exactly match an identity contained in the cert. Anything else leads to utter confusion and confounds interoperability. I can't believe that after so many years, we are still paralyzed w.r.t. this topic. What a farce. For the last several weeks, I've been trying to get several ostensibly mature implementations to interoperate using certs, and I've not had much success. How sad. Scott From owner-ipsec@lists.tislabs.com Tue Apr 22 11:41:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MIfAt2038594; Tue, 22 Apr 2003 11:41:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21865 Tue, 22 Apr 2003 13:46:31 -0400 (EDT) Date: Tue, 22 Apr 2003 10:41:33 -0700 (PDT) From: Jan Vilhuber To: ipsec@lists.tislabs.com Subject: ESP and header compression drafts Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since there's been some discussion on this topic recently (sorry I didn't partake), I thought I'd point out a recent draft I submitted. draft-vilhuber-hcoip-00.txt and draft-vilhuber-hcoesp-00.txt go together. draft-vilhuber-hcoesp-00.txt has a pretty detailed security analysis (or maybe I should call it a potential pitfalls analysis) in it. Comments and feedback is appreciated. jan ---------- Forwarded message ---------- Date: Fri, 31 Jan 2003 12:57:05 -0800 (PST) From: Jan Vilhuber To: ipsec@lists.tislabs.com Subject: [AVT] I-D ACTION:draft-vilhuber-hcoesp-00.txt (fwd) FYI. This is a use of draft-vilhuber-hcoip-00.txt (i.e. read that one first). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 "If Jack Valenti had been around at the time of Gutenberg he would have organized the monks to come and burn down the printing press." -- Harris Miller, president of the ITAA ---------- Forwarded message ---------- Date: Wed, 29 Jan 2003 06:54:08 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-vilhuber-hcoesp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP header compression in IPsec ESP Author(s) : J. Vilhuber Filename : draft-vilhuber-hcoesp-00.txt Pages : 8 Date : 2003-1-28 This draft outlines how to use IP Header compression over IP tunnels [HCOIP] inside IPsec ESP [ESP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vilhuber-hcoesp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-vilhuber-hcoesp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-vilhuber-hcoesp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] --NextPart-- From owner-ipsec@lists.tislabs.com Tue Apr 22 17:05:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N05Nt2051011; Tue, 22 Apr 2003 17:05:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA23111 Tue, 22 Apr 2003 19:21:42 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 22 Apr 2003 16:26:26 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Wes Hardaker cc: IPsec WG , "Wijnen, Bert (Bert)" Subject: IANA administrative issues with draft-ietf-ipsec-doi-tc-mib-07.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 18 Apr 2003, C. M. Heard wrote: > On Thu, 17 Apr 2003, Wes Hardaker wrote: > > On Thu, 17 Apr 2003, C. M. Heard wrote: > > C> The extra burden on IANA is a very real concern, and when I > > C> started the review of this MIB module most of the comments > > C> I wrote were related to changes that I thought would be > > C> necessary in order to make that tractable. > > > > If that is the reason you want to oppose the use of enums, then > > it is a more understandable argument from my eyes at least. > > Unfortunately, there is still functionality lost if this is the > > case. Does it mean we should never create enums in MIBs when it > > is supposed to match another standards document? We should > > always use references and no real values (in enums, description > > clauses or comments) in that case? > > > > I would argue that the administrative burden isn't as big a > > problem either. > > You might not think so when you've seen the details that apply > to this case. Unfortunately, [ ... ] I will have to defer the > details of that discussion [ ... ] until next week. Here is the promised discussion. iana@iana.org have been bcc:'d and are invited to weigh in with their opinions. The reason why I forsee a significant adminstrative burden if the MIB module in is turned over to the IANA for maintenance is that the number assignments captured by the enumerated INTEGER TCs in that module overlap those recorded in two existing IANA registries, namely the IANA Internet Security Association and Key Management Protocol (ISAKMP) Identifiers registry (http://www.iana.org/assignments/isakmp-registry) and the IANA Internet Key Exchange (IKE) Attributes registry (http://www.iana.org/assignments/ipsec-registry). The implication is that the IANA would have to maintain the assignments in two places, or else would have to reorganize those registries so that the proposed MIB module was the registry of record for the parameters it covers. The draft proposes the latter course of action, but it should be noted that the existing registries would not be eliminated, because the proposed MIB module does not cover all of the parameters and attributes recorded in the registries. It might be useful to make a side-by-side comparison of which parameters and attributes are covered both in the MIB module and the existing IANA registries, which ones appear in a registry file (or one of the IPsec RFCs) but not in the MIB module, and which ones appear in the MIB module but not in the registry files. The parameters and attributes from the IANA Internet Security Association and Key Management Protocol (ISAKMP) Identifiers registry (http://www.iana.org/assignments/isakmp-registry) that are captured by some textual convention in the draft are as follows: Parameter/Attribute Name Textual Convention IPSEC Situation Definition IpsecDoiSituation IPSEC Security Protocol Identifiers IpsecDoiSecProtocolId IPSEC ISAKMP Transform Identifiers IpsecDoiTransformIdent IPSEC AH Transform Identifiers IpsecDoiAhTransform IPSEC ESP Transform Identifiers IpsecDoiEspTransform IPSEC IPCOMP Transform Identifiers IpsecDoiIpcompTransform IPSEC Security Association Attributes Encapsulation Mode IpsecDoiEncapsulationMode Authentication Algorithm IpsecDoiAuthAlgorithm IPSEC Identification Type IpsecDoiIdentType IPSEC Notify Message Types IkeNotifyMessageType Notes: (a) In the case of IkeNotifyMessageType, only those enumerated values within the DOI-specific ranges 8192-16383 and 24576-32767 are recorded in the registry. The IkeNotifyMessageType TC also includes the DOI-independent values that are defined in RFC 2408 Section 3.14.1 (and captured by the IsakmpNotifyMessageType TC). Since the DOI-specific enumerations associated with the IkeNotifyMessageType TC are defined in RFC 2407 rather than RFC 2409, it seems that it is mis-named and should probably have been called IpsecDoiNotifyMessageType. (b) The registry specifies that values in the range 8192-16383 are error codes allocated for "private use within a DOI". This agrees with RFC 2407 but apparently disagrees with RFC 2408, which states that values in this range are for private use (but also states that values in the private use range are expected to be DOI-specific values). The registry (and RFC 2407) also specify that status codes in the range 32001-32767 are reserved for private use among consenting systems; however, while RFC 2408 does allocates status codes in the range 24576-32767 for DOI-specific use, it also allocates status codes in the range 32768-40959 for private use. This confusion needs to be fixed. The parameters and attributes from the IANA Internet Security Association and Key Management Protocol (ISAKMP) Identifiers registry (http://www.iana.org/assignments/isakmp-registry) that are NOT captured by any textual convention in the draft are as follows: IPSEC Security Association Attribute Class SA Life Type SA Life Duration Group Description Key Length Key Rounds Compression Dictionary Size Compression Private Algorithm ECN Tunnel IPSEC Labeled Domain Identifier Notes: (a) SA Life Duration, Compression Dictionary Size, and Compression Private Algorithm are such that management of values by the IANA is not required; however, Compression Dictionary Size and Compression Private Algorithm are mentioned in the registry, and TCs to represent them might be useful (although they might best be located in a MIB module that is not maintained by the IANA). (b) There is a section in the IANA ISAKMP registry for Group Description attribute values but that attribute is not mentioned here since its values are identical with those for the IKE Group Description attribute, which are listed in the IANA IKE Attributes registry discussed below. The attributes from the IANA Internet Key Exchange (IKE) Attributes registry (http://www.iana.org/assignments/ipsec-registry) that are captured by some textual convention in the draft are as follows: Attribute Name Textual Convention Encryption Algorithm IkeEncryptionAlgorithm Hash Algorithm IkeHashAlgorithm IPSEC Authentication Methods IkeAuthMethod Group Description IkeGroupDescription Group Type IkeGroupType PRF IkePrf Additional Exchanges (XCHG values) IkeExchangeType Notes: (a) In the case of IkeExchangeType, only those enumerated values within the DOI-specific range 32-239 are recorded in the registry. The IkeExchangeType TC also includes the DOI-independent values that are defined in RFC 2408 Section 3.1 (and captured by the IsakmpExchangeType TC). (b) No PRF values are currently registered, and IkePrf is a subranged Unsigned32 type, not an enumerated INTEGER type. Since Unsigned32 and INTEGER have different over-the-wire representations and Unsigned32 does not admit enumerations, the base type would need to be changed to INTEGER in order for future registered values to be represented as enumerations. The attributes from the IANA Internet Key Exchange (IKE) Attributes registry (http://www.iana.org/assignments/ipsec-registry) and/or RFC 2409 that are NOT captured by any textual convention in the draft are as follows: Attribute Class Group Prime/Irreducible Polynomial Group Generator One Group Generator Two Group Curve A Group Curve B Life Type Life Duration Key Length Field Size Group Order Note: Group Prime/Irreducible Polynomial, Group Generator One, Group Generator Two, Group Curve A, Group Curve B, and Life Duration are such that management of values by the IANA is not required, and their values are not listed in the IKE Attributes registry; however, they are defined in RFC 2409 and TCs to represent them might be useful (although they might best be located in a MIB module that is not maintained by the IANA). Certain of the textual conventions in the proposed MIB module capture parameters and attributes which are not recorded in either of the above-mentioned IANA registries, but which are mentioned in the IPsec RFCs and in a a registry update proposal (accessible on-line at http://www.vpnc.org/iana-ipsec/current-propsal.txt) that was recently discussed on the ipsec@lists.tislabs.com mailing list. Here is the list of the "missing in action" TCs and where the corresponding parameter or attribute is mentioned: Textual Convention Where param or attrib is mentioned IsakmpDOI RFC 2407 Section 4.1, RFC 2408 Appendix A (see proposal item #16) IsakmpCertificateEncoding RFC 2408 Section 3.9 (see proposal item #13) IsakmpExchangeType RFC 2408 Section 3.1 (see proposal item #12, but note that it includes both the DOI-independent stuff in RFC 2408 Section 3.1 and the the stuff discussed in RFC 2409 appendix A that is specific to IKE, and so corresponds more precisely to the IkeExchangeType TC) IsakmpNotifyMessageType RFC 2408 Section 3.14.1 (see proposal item #10, but note that it includes both the DOI-independent stuff in RFC 2408 Section 3.14.1 and the the stuff discussed in RFC 2407 Section 4.6.3 that is specific to the IPsec DOI, and so corresponds more precisely to the IkeNotifyMessageType TC) I hope that this comparison serves to shed some light on the amount of work that would be necessary if the MIB module in is turned over to the IANA for maintenance. If the IPsec-related registry files remain structured as they are presently, there will be a need to update at least one TC (and in some cases two TCs) when a new value is registered for most IPsec parameters. If the TCs in the MIB module become authoritative and duplication is eliminated, then there will be a lot of restructuring work needed. In either case the administrative burden is non-trivial, and I think that is a reason for concern. None of this would be necessary if the base types of the TCs were changed to subranged Unsigned32 (like IkePrf) with a pointer where appropriate to the existing IANA registry. So the question (leaving aside for the moment the questions of legality under SMI rules) is whether the benefits of having the enumeration labels are worth the administrative burden. Remember the burden will be borne not only by the IANA but also by document authors who have to generate the instructions to add new things to the registries. Mike Heard From owner-ipsec@lists.tislabs.com Wed Apr 23 00:47:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N7lGt2092254; Wed, 23 Apr 2003 00:47:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA24559 Wed, 23 Apr 2003 03:06:26 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 23 Apr 2003 00:11:11 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Wes Hardaker cc: IPsec WG , "Wijnen, Bert (Bert)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 18 Apr 2003, Wes Hardaker wrote: > On Fri, 18 Apr 2003, C. M. Heard wrote: > > Wes> In fact, the agent that receives a value outside the legal range > Wes> of values will already have to return the exact same error to > Wes> the management app that sent an illegal value in the first > Wes> place. > > C> Depending on what you mean by "the legal range of values" this can > C> be a problem. If you mean "the values in the enum list that are > C> know to the agent" (which is the behaviour mandated by RFC 2578 > C> Section 7.1.1) then this IS a problem because for the DOI TCs the > C> agent should ACCEPT any value that is within the range defined for > C> the underlying protocol data item if (a) it does not require special > C> knowledge on the part of the agent to process it or (b) it is in the > C> "private use" range and the agent knows what to do with it. Note > C> that in the latter case in particular, the value is _valid_ even > C> though it does not appear in the enum list. Now, one could code > C> around this problem, but that won't be conformant to RFC 2578 > C> Section 7.1.1, which says that "only those named-numbers so > C> enumerated may be present as a value." > > Ok, then how about changing my suggestion to: > > As described in RFC 2407 section 4.4.1, the range of values that > will be assigned by IANA for use in this TEXTUAL-CONVENTION and the > IPsec DOI will fall between 0 and 248, while legal values on the > wire may fall between 0 and 255. Values in the range 249-255 will > not be utilized within IETF standardization documents as they have > been reserved by the IPsec DOI for private use by cooperating > devices. All use of deviations from the standardized list of > enumerations, including those that fall in the 249-255 range, must > be documented within the appropriate AGENT-CAPABILITIES statements. > > This documents that values from 249-255 won't be standardized, are > intended for use by private organizations, and finally reminds the > agent implementers that these other accepted/used values must be > documented in the standard way in which all agents are supposed to > document their deviation from a standardized SMIv2 document. There are a couple of problem with this proposal that I'd like to point out. For concreteness, note that the specific TC to which this suggestion pertains is IpsecDoiSecProtocolId, whose definition is as follows: IpsecDoiSecProtocolId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "These are the IPsec DOI values for the Protocol-Id field in an ISAKMP Proposal Payload, and in all Notification Payloads. They are also used as the Protocol-ID In the Notification Payload and the Delete Payload. The values 249-255 are reserved for private use amongst cooperating systems." REFERENCE "RFC 2407 section 4.4.1" SYNTAX INTEGER { reserved(0), -- reserved in DOI protoIsakmp(1), -- message protection -- required during Phase I -- of the IKE protocol protoIpsecAh(2), -- IP packet authentication -- via Authentication Header protoIpsecEsp(3), -- IP packet confidentiality -- via Encapsulating -- Security Payload protoIpcomp(4) -- IP payload compression } Presumably, the proposed text is intended to replace the third paragraph of the DESCRIPTION clause of this TC. (As an aside, note that the proposed text should point to RFC 2407 section 6.3 rather than 4.4.1 and that the REFERENCE clause should mention section 6.3 as well as 4.4.1). Observe that it is not permissible to specify something like this SYNTAX IpsecDoiSecProtocolId { protoIsakmp(1), protoIpsecAh(2), protoIpsecEsp(3), protoIpcomp(4), protoIpsecCompanyProprietary(249) } in a VARIATION clause of an AGENT-CAPABILITIES statement. That is an illegal refinement, and at least some MIB compilers (SMICng is one) will reject it. The same is true, of course, of WRITE-SYNTAX. So the only way to document deviations from the standardized list of enumerations within an AGENT-CAPABILITIES statement is to do it in a DESCRIPTION clause. That can be done in a VARIATION description for objects that have a MAX-ACCESS value greater than not-accessible, but must be done in the AGENT-CAPABILITIES description for index objects that have a MAX-ACCESS value of not-accessible because VARIATION clauses are not allowed for such objects. As it turns out, all but one of the uses of this TC in the three MIB modules that use it (and both of the uses in the IPSEC-POLICY-MIB) are in the definitions of inaccessible index objects, so the state of affairs is not a very satisfactory one. Very similar limitations apply to MODULE-COMPLIANCE statements. My conclusion is still that use of enumerated INTEGER in a manner that is inconsistent with the semantics defined in the SMIv2 RFCs is something to be avoided. Yes, it can probably be made to work over the wire, but it messes up the meaning not only of object definitions, but also of compliance statements and capabilities statements. It is hard to predict how it will interact with tools such as automated code generators for method routines or indexing routines that expect standards-compliant behaviour. In my opinion, such practices have no place in standards-track MIB modules; implementors have a right to expect standards-compliant behaviour. Regards, //cmh From owner-ipsec@lists.tislabs.com Wed Apr 23 00:52:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N7qAt2092603; Wed, 23 Apr 2003 00:52:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA24664 Wed, 23 Apr 2003 03:21:13 -0400 (EDT) Message-Id: <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 23 Apr 2003 13:03:16 +0530 To: ipsec@lists.tislabs.com From: Jyothi Subject: Question on inbound IPSEC policy check In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E5583FB40@TMM_EDGMSMSG01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I have a question regarding the inbound SPD policy checking. Please consider the following scenario: Office1Network-----SG1---------Internet------------SG2-------Office2Network. Office1Network has HTTP as well as other services hosted. Office1 administartor wants to make sure that all HTTP traffic has to go with 3DES and SHA1 And all other traffic can go with AH MD5 and no encyrption is required for performance reasons. In this case, if office2Network SG is mis-configured or they did not even configure HTTP policy. Then SG1 accepts the HTTP traffic and process it. After IPSEC processing, SHOULD WE ACCEPT THOSE PACKETS OR DROP THOSE PACKETS, because higher priority SPD policy is created for the HTTP traffic. Any advice on this would be greatly appreciated Thanks in advance, Jyothi From owner-ipsec@lists.tislabs.com Wed Apr 23 03:30:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NAUgt2006423; Wed, 23 Apr 2003 03:30:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA25138 Wed, 23 Apr 2003 05:55:18 -0400 (EDT) Message-Id: <200304230959.h3N9xZof001659@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com Subject: Re: peer address protection In-reply-to: Your message of Wed, 16 Apr 2003 07:05:06 +0800. <16028.36898.778373.788474@tero.kivinen.iki.fi> Date: Wed, 23 Apr 2003 11:59:35 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Francis.Dupont@enst-bretagne.fr (Francis Dupont) writes: > The peer addresses are not protected in IKEv2 and are not clearly > protected in IKEv1 I do not think there is any need to protect them in IKEv2. => please reread draft-dupont-transient-pseudonat-01.txt... This is not a dramatic need (i.e., we have not to fix IKEv1 too) because the issue is DOS attacks using IKE, but we should take the opportunity to cleanup this in IKEv2. > - Fourth/last case: no NAT is detected: IKE and IPsec SAs SHOULD be > run over UDP port 500 and peer addresses MUST be protected using > PEER_ADDRESS_SOURCE and PEER_ADDRESS_DESTINATION notifications > included in the encrypted payload of all messages. If we do not have NAT between (meaning that NAT-T is disabled), then this also means that the host changing ip address will know when it does so (it is mobile node, which gets new ip address or it is multihoming device which decides to use another interface for the traffic). => yes, in this case the peer has the control on its address(es). This means that to update any of the IPsec or IKE SA peer addresses, it MUST send the SOURCE-ADDRESS-CHANGED notification telling that this => with a SHOULD (MUST is only needed in some cases, not all cases) and a peer address update payload or any equivalent I agree. will be its new source IP address/port. It SHOULD do this immediately when it can receive from the new address/port, and I think it MAY send => I believe the complexity of updating to another address than the one used for the transport of the update is higher than possible benefits. Note we have the same issue for CREATE_CHILD_SA exchange: uses the peer addresses from the IP headers or send the "outer" addresses in a payload or a notification. The second is strictly more powerful but far more complex too. BTW if I've understood all the details of your proposal in fact the SOURCE-ADDRESS-CHANGED notification MAY be sent from any address/port, i.e., not only from the old or new address/port. it from the old address/port. This notification will tell the new source IP address and port. If some attacker will modify some IP header source address or port of the IKE packet that does not affect anything else, than that the responce is sent back to this modified address. It does not affect to the future packets sent in the IKE SA nor does it change the tunnel endpoint addresses used for the IPSec SAs. The future IKE packets still use the same official IKE SA IP address, which was used in the beginning, or which was changed using SOURCE-ADDRESS-CHANGED notification. => this is an effect of the decoupling of peer addresses and "outer" addresses... BTW I don't understand what you'd like to prove. For the tunnel endpoints the IKE will also use the same official IKE SA IP address, thus even if the packet seemed to come from different address the tunnel endpoint address is taken from the IP address associated with the IKE SA. Only way to change this IP address associated with the IKE SA is to use SOURCE-ADDRESS-CHANGED (this whole discussion is discussing case where we do NOT have NAT, i.e when the NAT-T is not enabled). => there is no such address lock in the current draft. If we introduce one, we have to be accurate in the exchange which locks the addresses (for instance the IKE_SA_INIT one) and at a side effect it makes the support of an peer address update payload/notification mandatory because a rekeying won't be enough to change "outer" addresses. I.e, this is a real change and I am afraid we have not enough time to decide about it. I.e only thing attacker can gain by modifying the source address is to get one reply packet to be sent to wrong address. This not really a attack, as he could have sent the packet directly there (i.e it is one extra packet to wrong address per one modified packet). I do not thing we need PEER_ADDRESS_SOURCE, PEER_ADDRESS_DESTINATION or PEER_ADDRESS_ALERT notifications. The SOURCE-ADDRESS-CHANGED is the only thing we need. => in fact it seems you propose to replace my explicit protection of the peer addresses with a peer address update payload by a different scheme which should roughly give the same things. In your proposal: - the peer addresses are "locked" in the IKE_SA_INIT exchange (this exchange because this is the only exchange where the peer addresses are indirectly protected by the NAT detection notifications and the AUTH payload of the IKE_AUTH exchange). - the "locked" pair of peer addresses is used for tunnel endpoint addresses (what I called the "outer" addresses), - as they are "locked", there is no need to protect them further but only a pair of peer addresses are managed by a IKE SA. - the only way to change this pair of peer addresses is the SOURCE-ADDRESS-CHANGED which has a global effect (global in place of per IKE SA/IPsec SA pair). I have three main concerns: - only one peer address is managed per peer when in some cases (mainly in multi-homing) it is better to manage an address set. This shan't be a real problem without the second point. - your SOURCE-ADDRESS-CHANGED notification has a global effect, i.e., it is not possible to update only an IPsec SA pair and to keep the "old" address for the IKE SA and other IPsec SA pairs. In a PS I give a scenario where this is a real problem. - rekeying doesn't change the locked pair of peer addresses so the support of your SOURCE-ADDRESS-CHANGED notification should be mandatory in mobility and multi-homing environments (i.e., the update mechanism is no more an optimization). I cannot see any pseudo NAT attack that will work with this protocol. If you can see something, can you explain it to me (with exact packet examples, please). => I agree that when the peer addresses are "locked" in the IKE_SA_INIT exchange a pseudo NAT attack cannot setup a SA with NAT traversal inactive (addresses are protected by the NAT detection notifications which are themselves protected as the content of IKE_SA_INIT messages by the AUTH payloads in the IKE_AUTH exchange). The only possibility for a pseudo NAT attack is to force a NAT detection but the implicit update mechanism (which SHOULD be supported for this reason) removes the "transient" property, i.e., this becomes a common NAT attack and IKE no more needs a specific defense against it. Ps. I will be on the vacation for about two weeks starting tomorrow, so I might not be able to read replies before that. => I'm back from vacation and in the announce of the draft 07 there is something for us: "My inclination is to leave that for a subsequent effort, possibly to be folded into a future revision when it stabilizes". I'm afraid that the NAT traversal support is postponed too which was never in my intention... Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Apr 23 03:39:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NAdat2007223; Wed, 23 Apr 2003 03:39:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA25205 Wed, 23 Apr 2003 06:09:55 -0400 (EDT) Message-Id: <200304231014.h3NAEDof001699@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com Subject: Re: peer address update payload In-reply-to: Your message of Wed, 16 Apr 2003 07:10:01 +0800. <16028.37193.164975.747768@tero.kivinen.iki.fi> Date: Wed, 23 Apr 2003 12:14:13 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Francis.Dupont@enst-bretagne.fr (Francis Dupont) writes: > Here is a proposal for the peer address update payload if > we decide to include it in the next IKEv2 draft. The modifs > are: I am still not sure we need to have the ability to have different IP address per each CHILD SA of the IKE SA. => between multi-homed SGs this is very useful, both for resilience to failures and for load sharing. In the mobile node to mobile node case, one should like to setup an ESP tunnel using the care-of addresses in the outer header but with an IKE SA running over the stable home addresses: this is the easiest way to handle simultaneous handoffs. I think we should simply say that if you want to modify the IP addresses of the CHILD SAs independently then create them using separate IKE SAs. => this can be very expensive. I believe this trade-off was intensely discussed when we decide to keep a two phase protocol, i.e., the choice is to run *one* IKE SA between two peers. If you happen to have all of the CHILD SAs created by one IKE SA and you want to split them to two different classes, create another IKE SA and recreate those CHILD SAs you want to move inside this new IKE SA and delete them from the old IKE SA. Or you can create each CHILD SA with separate IKE SA. => I agree this gives the same level of flexibility. I think it is simplier, and offeres same features than peer address update payload. => I don't believe we agree about what is simplier. My opinion is to use one IKE SA per IPsec SA group is against the rationale for a two phase protocol... Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Apr 23 06:34:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NDYOt2016364; Wed, 23 Apr 2003 06:34:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25668 Wed, 23 Apr 2003 08:59:20 -0400 (EDT) Message-Id: <200304231054.GAA10959@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-07.txt Date: Wed, 23 Apr 2003 06:54:12 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-07.txt Pages : 95 Date : 2003-4-22 This document describes version 2 of the IKE (Internet Key Exchange) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations. This version of IKE simplifies the design by removing options that were rarely used and simplifying the encoding. This version of the IKE specification combines the contents of what were previously separate documents, including ISAKMP (RFC 2408), IKE (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy authentication, and remote address acquisition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-22151800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-22151800.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Apr 23 10:27:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NHRSt2032753; Wed, 23 Apr 2003 10:27:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26447 Wed, 23 Apr 2003 12:40:37 -0400 (EDT) Message-Id: <200304222017.h3MKHBPU002312@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-reply-to: Your message of "Tue, 22 Apr 2003 10:52:46 PDT." <3EA5816E.FA07BD95@airespace.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 22 Apr 2003 16:17:11 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: Scott> Just wanted to comment on this: I agree with Paul. Since we seem Scott> unable to produce a coherent specification with respect to Scott> PKI-related Scott> policies, when using certs the ID payload should not be Scott> present. If we I would agree, that if you said: When using a PKIX-style certificate which is provided in a CERT payload that the ID payload should not be set to anything other than ID_DER_ASN1_DN or ID_DES_ASN1_GN. The provided GN or DN MUST be identical to that in the certificate. (It is redundant, I agree) The appropriate policy can clearly be looked up by GN/DN. So, I just don't get it. It seems to me that if you are using a pre-exchanged certificate, or other out-of-band certificate retrival system, that all ID payload types are useful. Scott> this topic. What a farce. For the last several weeks, I've been Scott> trying Scott> to get several ostensibly mature implementations to interoperate Scott> using Scott> certs, and I've not had much success. How sad. The last time I tried this, it all failed because implementations could not produce PKCS10 certificate requests, nor could they load self-signed certificates. So there was no way to get public keys to the other side. How have things "improved"? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPqWjRYqHRg3pndX9AQEKBAP+IvtYigYs6g3IH+ZW/BfGqjSqPqhM1DTq lXQwqJcY1QXVCBaDdLZz0n2VxnAHerJM9SHwfzrRfEuhoml1vAKkQfw2qgw+xs74 o7tiAY+UtgntZAuKfX+kBeOBrKsM6AkoAyy/Ay5IR4m7j2AaJw6ml6pb9sjxDIo7 swn9K7+kIxU= =biU5 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Apr 23 13:31:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NKVCt2038169; Wed, 23 Apr 2003 13:31:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26892 Wed, 23 Apr 2003 14:37:46 -0400 (EDT) Message-Id: <5.0.2.1.0.20030423113413.0313fea8@10.1.5.10> X-Sender: suren@10.1.5.10 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 23 Apr 2003 11:38:27 -0700 To: Ravi , ipsec@lists.tislabs.com From: suren Subject: Re: Peer liveliness In-Reply-To: <3E9F87B2.7070902@roc.co.in> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Ravi, It is good idea to find out whether the peer SA is dead or not. I support this and would like to see some draft in this regard. Suren At 10:35 AM 4/18/2003 +0530, Ravi wrote: > Hi, > I was going through several drafts related to peer liveliness. But, > some of practical > problems faced in actual deployment may not be solved by these proposals. > INITIAL_CONTACT Notification : It indicates that the Peer was dead and > cameback. > DPD: Checks the liveliness of the peer. > I feel, we require interoperable solution to check liveliness of SA ie > Dead Peer SA detection > (DPSD). > DPD specification can be enhanced to achieve this. > Protocol-ID and SPI fields can be made mandatory. > Protocol-ID can be ESP/AH/IKE. > SPI : In case of IKE, it could be cookies and in case of ESP/AH, it is > SPI (inbound SA's SPI > on the peer). > If peer is not dead, but SAs were deleted either due to temporary > failure OR due to > restarting of some processes in the system can be detected with this > mechanism. > Does this makes sense? If so, I can contribute text to this effect. >Regards, >Ravi > >-- > > >The views presented in this mail are completely mine. The company is not >responsible for whatsoever. > >---------- >Ravi Kumar CH >Rendezvous On Chip (i) Pvt Ltd >Hyderabad, India >Ph: +91-40-2335 1214 / 1175 / 1184 > >ROC home page > From owner-ipsec@lists.tislabs.com Wed Apr 23 13:33:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NKXSt2038217; Wed, 23 Apr 2003 13:33:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26904 Wed, 23 Apr 2003 14:42:27 -0400 (EDT) From: jknowles@SonicWALL.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Confirm decision on identity handling. Date: Wed, 23 Apr 2003 11:47:08 -0700 Message-ID: <385918F84B55DC4E9542E0A4812F4131074AE7@us0exb01.us.sonicwall.com> Thread-Topic: Confirm decision on identity handling. Thread-Index: AcMJCES8PBwuFEWzQPuY29Xb9hHxygAMCj1Q To: , X-OriginalArrivalTime: 23 Apr 2003 18:47:08.0621 (UTC) FILETIME=[BE3BDFD0:01C309C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA26901 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, I don't like banning ID payloads when using certs. The ID check against policy is cheap compared to cert sig processing so I'd like to have the option of checking for policy match prior to cert processing. I'm also not sure how I look up the policy without an ID payload. I think the purpose of the ID payload when using certs is (was) to specify which of several possible IDs contained in the cert should be used for policy lookup. Unfortunately, the mapping was never clearly defined. De-coupling the ID from the cert allows the lookup as well and avoids the ID-to-cert mapping mess. I guess all that we lose is the direct authentication of the ID (if in the cert) by the issuing authority. Since the ID is ultimately signed anyway, we don't lose too much. It's true that someone holding the private key could send a rogue identity that is not directly confirmed by the CA/RA. Depending on your views of PKI, that could be good or bad :-). As local policy, we can mandate the ID-to-cert mapping as we wish. We just need to provide the knobs and levers to specify interoperable mappings. Regards, Jim > -----Original Message----- > From: Scott G. Kelly [mailto:scott@airespace.com] > Sent: Tuesday, April 22, 2003 10:53 AM > To: ipsec@lists.tislabs.com > Subject: Re: Confirm decision on identity handling. > > > > Just wanted to comment on this: I agree with Paul. Since we seem > unable to produce a coherent specification with respect to PKI-related > policies, when using certs the ID payload should not be present. If we > cannot agree on this, then the next best position is that the > ID payload > must exactly match an identity contained in the cert. Anything else > leads to utter confusion and confounds interoperability. > > I can't believe that after so many years, we are still > paralyzed w.r.t. > this topic. What a farce. For the last several weeks, I've been trying > to get several ostensibly mature implementations to interoperate using > certs, and I've not had much success. How sad. > > Scott > From owner-ipsec@lists.tislabs.com Wed Apr 23 13:34:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NKYAt2038234; Wed, 23 Apr 2003 13:34:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26872 Wed, 23 Apr 2003 14:29:06 -0400 (EDT) Message-Id: <5.0.2.1.0.20030423112726.023a84e0@10.1.5.10> X-Sender: suren@10.1.5.10 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 23 Apr 2003 11:32:03 -0700 To: Jyothi , ipsec@lists.tislabs.com From: suren Subject: Re: Question on inbound IPSEC policy check In-Reply-To: <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> References: <421CB3B9B2D2F645B548D213C0A90E5583FB40@TMM_EDGMSMSG01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Jyothi, The HTTP packets, that are coming via AH-MD5 tunnel should be dropped by SG1. You might have been confused by text in RFC2401 section 5.2.1 Bullet 3, which reads like this. "Find an incoming policy in the SPD that matches the packet. This could be done, for example, by use of backpointers from the SAs to the SPD or by matching the packet's selectors (Inner Header if tunneled) against those of the policy entries in the SPD " In my view, text indicating "backpointers from SA" is confusing. Dropping HTTP traffic in following example by SG1 is good and I would like to hear from other IPSEC vendors as it impacts inter-operability. I feel the text for bullet 3, should be read like this: "Find an incoming policy in the SPD that matches the packet selectors. This could be done by matching packet selectors against those of the policy entries in the SPD in their order of priority." Suren Intoto Inc 3160, De La Cruz Blvd #100 Santa Clara, CA www.intotoinc.com At 01:03 PM 4/23/2003 +0530, Jyothi wrote: >Hi all, > >I have a question regarding the inbound SPD policy checking. > >Please consider the following scenario: > >Office1Network-----SG1---------Internet------------SG2-------Office2Network. > >Office1Network has HTTP as well as other services hosted. >Office1 administartor wants to make sure that all HTTP traffic has to go with >3DES and SHA1 > >And all other traffic can go with AH MD5 and no encyrption is required for >performance reasons. > >In this case, if office2Network SG is mis-configured or they did not even >configure HTTP policy. > >Then SG1 accepts the HTTP traffic and process it. >After IPSEC processing, SHOULD WE ACCEPT THOSE PACKETS OR DROP THOSE >PACKETS, because higher priority SPD policy is created for the HTTP traffic. > >Any advice on this would be greatly appreciated > > >Thanks in advance, >Jyothi From owner-ipsec@lists.tislabs.com Wed Apr 23 13:39:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NKdKt2038338; Wed, 23 Apr 2003 13:39:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26977 Wed, 23 Apr 2003 15:05:17 -0400 (EDT) Message-ID: <3EA6E496.8F65904B@airespace.com> Date: Wed, 23 Apr 2003 12:08:06 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: jknowles@SonicWALL.com CC: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <385918F84B55DC4E9542E0A4812F4131074AE7@us0exb01.us.sonicwall.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2003 19:09:35.0512 (UTC) FILETIME=[E10B2180:01C309CB] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Jim, I think the problem arises precisely when we try to interoperate. If one vendor owns both sides of the connection, then one might assume that the initiator knows what to send in the ID payload, but this is not necessarily the case when interoperating. Since the choice of which ID value to use as a policy selector is a matter for the recipient to decide (it is, after all, the recipient's policy which must be satisfied), the sender may or may not choose the proper value to insert in the ID payload, even though the cert is acceptable to the recipient. However, the recipient (hopefully) knows what to look at in the cert, and it can extract this without verifying the cert and still gain the same level of assurance as it would if it grabbed it from an ID payload, did the policy lookup, and then verified that the ID payload matched the cert field and then verified the cert itself. I think the right answer is a well-defined profile which makes all of this explicit. However, this working group seems to anxious to simply produce a document and disband without addressing this or other interop issues. It is not clear to me that anyone has much incentive to implement ike2 if it doesn't address the fundamental shortcomings of ike1, though, and the lack of clear guidelines for pki-based policy is (in my view) one of the significant shortcomings of ike1. I guess if the ID payload is important to you, then (somone's) suggested language which makes it optional to process it might be more to your liking. I'm not sure that I feel strongly that we shouldn't just go that way, except that this sort of slop in the spec is what causes interop problems. Scott jknowles@SonicWALL.com wrote: > > Hi Scott, > > I don't like banning ID payloads when using certs. > The ID check against policy is cheap compared to > cert sig processing so I'd like to have the option > of checking for policy match prior to cert processing. > I'm also not sure how I look up the policy without > an ID payload. > > I think the purpose of the ID payload when using > certs is (was) to specify which of several possible IDs > contained in the cert should be used for policy > lookup. Unfortunately, the mapping was never > clearly defined. De-coupling the ID from the cert > allows the lookup as well and avoids the ID-to-cert > mapping mess. I guess all that we lose is the direct > authentication of the ID (if in the cert) by the > issuing authority. Since the ID is ultimately signed > anyway, we don't lose too much. It's true that > someone holding the private key could send a rogue > identity that is not directly confirmed by the CA/RA. > Depending on your views of PKI, that could be good > or bad :-). As local policy, we can mandate the > ID-to-cert mapping as we wish. We just need to > provide the knobs and levers to specify interoperable > mappings. > > Regards, > > Jim > > > -----Original Message----- > > From: Scott G. Kelly [mailto:scott@airespace.com] > > Sent: Tuesday, April 22, 2003 10:53 AM > > To: ipsec@lists.tislabs.com > > Subject: Re: Confirm decision on identity handling. > > > > > > > > Just wanted to comment on this: I agree with Paul. Since we seem > > unable to produce a coherent specification with respect to PKI-related > > policies, when using certs the ID payload should not be present. If we > > cannot agree on this, then the next best position is that the > > ID payload > > must exactly match an identity contained in the cert. Anything else > > leads to utter confusion and confounds interoperability. > > > > I can't believe that after so many years, we are still > > paralyzed w.r.t. > > this topic. What a farce. For the last several weeks, I've been trying > > to get several ostensibly mature implementations to interoperate using > > certs, and I've not had much success. How sad. > > > > Scott > > From owner-ipsec@lists.tislabs.com Wed Apr 23 14:05:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NL5Kt2039312; Wed, 23 Apr 2003 14:05:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27146 Wed, 23 Apr 2003 16:16:09 -0400 (EDT) From: jknowles@SonicWALL.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Confirm decision on identity handling. Date: Wed, 23 Apr 2003 13:20:56 -0700 Message-ID: <385918F84B55DC4E9542E0A4812F413106E295@us0exb01.us.sonicwall.com> Thread-Topic: Confirm decision on identity handling. Thread-Index: AcMJy+IFt4N4qTB6TJyfjDzP1722UgAAukJA To: Cc: X-OriginalArrivalTime: 23 Apr 2003 20:20:56.0911 (UTC) FILETIME=[D8F4C5F0:01C309D5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA27143 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, OK, I see your point. However, the recipient policy can still say "ignore ID payloads, get me an email addr from the cert subjectAltName" and get the same behaviour you'd like. Choosing between two (or more) recipient policies that expect different cert ID fields will be interesting when a cert matches more than one. An ID payload could differentiate in this case and avoids the cert parsing when ID's don't match, but you're right that the initiator needs to know which ID to send. I'd like to have that option in cases where the ID payload type can be selected by the sender. Regards, Jim > -----Original Message----- > From: Scott G. Kelly [mailto:scott@airespace.com] > Sent: Wednesday, April 23, 2003 12:08 PM > To: Jim Knowles > Cc: ipsec@lists.tislabs.com > Subject: Re: Confirm decision on identity handling. > > > Hi Jim, > > I think the problem arises precisely when we try to > interoperate. If one > vendor owns both sides of the connection, then one might > assume that the > initiator knows what to send in the ID payload, but this is not > necessarily the case when interoperating. Since the choice of which ID > value to use as a policy selector is a matter for the recipient to > decide (it is, after all, the recipient's policy which must be > satisfied), the sender may or may not choose the proper value > to insert > in the ID payload, even though the cert is acceptable to the > recipient. > > However, the recipient (hopefully) knows what to look at in the cert, > and it can extract this without verifying the cert and still gain the > same level of assurance as it would if it grabbed it from an > ID payload, > did the policy lookup, and then verified that the ID payload > matched the > cert field and then verified the cert itself. > > I think the right answer is a well-defined profile which makes all of > this explicit. However, this working group seems to anxious to simply > produce a document and disband without addressing this or > other interop > issues. It is not clear to me that anyone has much incentive to > implement ike2 if it doesn't address the fundamental shortcomings of > ike1, though, and the lack of clear guidelines for pki-based policy is > (in my view) one of the significant shortcomings of ike1. > > I guess if the ID payload is important to you, then > (somone's) suggested > language which makes it optional to process it might be more to your > liking. I'm not sure that I feel strongly that we shouldn't > just go that > way, except that this sort of slop in the spec is what causes interop > problems. > > Scott > > jknowles@SonicWALL.com wrote: > > > > Hi Scott, > > > > I don't like banning ID payloads when using certs. > > The ID check against policy is cheap compared to > > cert sig processing so I'd like to have the option > > of checking for policy match prior to cert processing. > > I'm also not sure how I look up the policy without > > an ID payload. > > > > I think the purpose of the ID payload when using > > certs is (was) to specify which of several possible IDs > > contained in the cert should be used for policy > > lookup. Unfortunately, the mapping was never > > clearly defined. De-coupling the ID from the cert > > allows the lookup as well and avoids the ID-to-cert > > mapping mess. I guess all that we lose is the direct > > authentication of the ID (if in the cert) by the > > issuing authority. Since the ID is ultimately signed > > anyway, we don't lose too much. It's true that > > someone holding the private key could send a rogue > > identity that is not directly confirmed by the CA/RA. > > Depending on your views of PKI, that could be good > > or bad :-). As local policy, we can mandate the > > ID-to-cert mapping as we wish. We just need to > > provide the knobs and levers to specify interoperable > > mappings. > > > > Regards, > > > > Jim > > > > > -----Original Message----- > > > From: Scott G. Kelly [mailto:scott@airespace.com] > > > Sent: Tuesday, April 22, 2003 10:53 AM > > > To: ipsec@lists.tislabs.com > > > Subject: Re: Confirm decision on identity handling. > > > > > > > > > > > > Just wanted to comment on this: I agree with Paul. Since we seem > > > unable to produce a coherent specification with respect > to PKI-related > > > policies, when using certs the ID payload should not be > present. If we > > > cannot agree on this, then the next best position is that the > > > ID payload > > > must exactly match an identity contained in the cert. > Anything else > > > leads to utter confusion and confounds interoperability. > > > > > > I can't believe that after so many years, we are still > > > paralyzed w.r.t. > > > this topic. What a farce. For the last several weeks, > I've been trying > > > to get several ostensibly mature implementations to > interoperate using > > > certs, and I've not had much success. How sad. > > > > > > Scott > > > > From owner-ipsec@lists.tislabs.com Wed Apr 23 15:15:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NMFJt2042661; Wed, 23 Apr 2003 15:15:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27455 Wed, 23 Apr 2003 17:36:18 -0400 (EDT) Message-ID: <3EA707FC.498FFE54@airespace.com> Date: Wed, 23 Apr 2003 14:39:08 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: jknowles@SonicWALL.com CC: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <385918F84B55DC4E9542E0A4812F413106E295@us0exb01.us.sonicwall.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2003 21:40:37.0958 (UTC) FILETIME=[FAAEA660:01C309E0] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Jim, I'm partially addressing your comments, and partially addressing Michael Richardson's comments, which I see on the vpnc archive, but have yet to receive here. I think Michael makes a good point: if the cert is not included in the packet, then the ID payload is useful. It allows a way to indicate which cert is intended absent the cert itself. But note the subtle difference here: we are not trying to use the id payload as a policy selector so much as we are using it as a credential identifer in this case. In general, I think we're mixing the notion of a credential (or credential identifier) with a policy selector. When the cert is passed in the packet, the cert is the credential, but it is also used as a policy selector. I may use one or more fields in the cert as a policy selector, but you have no way of knowing a priori (unless we agree ahead of time) which ones that will include. Since the criteria by which I evaluate your certificate is wholly left to me (it is not explicitly specified), then any additional information you pass me is liable to be superfluous, unless we are running the same implementation at both ends, and/or you *know* exactly what I expect. Think about it: since you can send me either the DN or the GN (or who knows what else?), I need to know what to do if what you send doesn't match my expectations (policy). For example, suppose you send the DN. If my policy is to accept certs from issuer x, then your ID payload is meaningless. Or, if my policy is to require your GN to contain jknowles@foo.com, again your ID payload is meaningless. And if my policy is to accept certs from issuer x containing {xyz} in the DN, even if this is in the ID payload you pass, I still must verify that it matches the cert, and validate the cert. Back to the case where you send me the wrong ID payload, it has been suggested that I can just ignore what you send, meaning I will parse the cert anyway, but what if I don't? Instead I can fail the negotiation, in which case a customer will likely call and say "what does ID-MISMATCH mean?". The bottom line is that, in order to guarantee interoperability, as a responder I will need to have the ability to ignore the ID payload and parse the cert instead - but it's not clear *when* I should ignore it. Should I ignore it always, or just when it fails to match my policy? It doesn't seem worthwhile to introduce this ambiguity for the very small amount of convenience it might provide in a single vendor implementation. Why not simply treat the cert as the ID in this case, and not add superfluous ID payloads which someone may or may not ignore? Nailing down little twists like this go a long way toward fostering interoperability... Scott jknowles@SonicWALL.com wrote: > > Hi Scott, > > OK, I see your point. However, the recipient policy > can still say "ignore ID payloads, get me an email addr > from the cert subjectAltName" and get the same > behaviour you'd like. Choosing between two (or more) > recipient policies that expect different cert ID fields > will be interesting when a cert matches more than one. > An ID payload could differentiate in this case and > avoids the cert parsing when ID's don't match, but > you're right that the initiator needs to know which > ID to send. I'd like to have that option in cases > where the ID payload type can be selected by the > sender. > > Regards, > > Jim > > > -----Original Message----- > > From: Scott G. Kelly [mailto:scott@airespace.com] > > Sent: Wednesday, April 23, 2003 12:08 PM > > To: Jim Knowles > > Cc: ipsec@lists.tislabs.com > > Subject: Re: Confirm decision on identity handling. > > > > > > Hi Jim, > > > > I think the problem arises precisely when we try to > > interoperate. If one > > vendor owns both sides of the connection, then one might > > assume that the > > initiator knows what to send in the ID payload, but this is not > > necessarily the case when interoperating. Since the choice of which ID > > value to use as a policy selector is a matter for the recipient to > > decide (it is, after all, the recipient's policy which must be > > satisfied), the sender may or may not choose the proper value > > to insert > > in the ID payload, even though the cert is acceptable to the > > recipient. > > > > However, the recipient (hopefully) knows what to look at in the cert, > > and it can extract this without verifying the cert and still gain the > > same level of assurance as it would if it grabbed it from an > > ID payload, > > did the policy lookup, and then verified that the ID payload > > matched the > > cert field and then verified the cert itself. > > > > I think the right answer is a well-defined profile which makes all of > > this explicit. However, this working group seems to anxious to simply > > produce a document and disband without addressing this or > > other interop > > issues. It is not clear to me that anyone has much incentive to > > implement ike2 if it doesn't address the fundamental shortcomings of > > ike1, though, and the lack of clear guidelines for pki-based policy is > > (in my view) one of the significant shortcomings of ike1. > > > > I guess if the ID payload is important to you, then > > (somone's) suggested > > language which makes it optional to process it might be more to your > > liking. I'm not sure that I feel strongly that we shouldn't > > just go that > > way, except that this sort of slop in the spec is what causes interop > > problems. > > > > Scott > > > > jknowles@SonicWALL.com wrote: > > > > > > Hi Scott, > > > > > > I don't like banning ID payloads when using certs. > > > The ID check against policy is cheap compared to > > > cert sig processing so I'd like to have the option > > > of checking for policy match prior to cert processing. > > > I'm also not sure how I look up the policy without > > > an ID payload. > > > > > > I think the purpose of the ID payload when using > > > certs is (was) to specify which of several possible IDs > > > contained in the cert should be used for policy > > > lookup. Unfortunately, the mapping was never > > > clearly defined. De-coupling the ID from the cert > > > allows the lookup as well and avoids the ID-to-cert > > > mapping mess. I guess all that we lose is the direct > > > authentication of the ID (if in the cert) by the > > > issuing authority. Since the ID is ultimately signed > > > anyway, we don't lose too much. It's true that > > > someone holding the private key could send a rogue > > > identity that is not directly confirmed by the CA/RA. > > > Depending on your views of PKI, that could be good > > > or bad :-). As local policy, we can mandate the > > > ID-to-cert mapping as we wish. We just need to > > > provide the knobs and levers to specify interoperable > > > mappings. > > > > > > Regards, > > > > > > Jim > > > > > > > -----Original Message----- > > > > From: Scott G. Kelly [mailto:scott@airespace.com] > > > > Sent: Tuesday, April 22, 2003 10:53 AM > > > > To: ipsec@lists.tislabs.com > > > > Subject: Re: Confirm decision on identity handling. > > > > > > > > > > > > > > > > Just wanted to comment on this: I agree with Paul. Since we seem > > > > unable to produce a coherent specification with respect > > to PKI-related > > > > policies, when using certs the ID payload should not be > > present. If we > > > > cannot agree on this, then the next best position is that the > > > > ID payload > > > > must exactly match an identity contained in the cert. > > Anything else > > > > leads to utter confusion and confounds interoperability. > > > > > > > > I can't believe that after so many years, we are still > > > > paralyzed w.r.t. > > > > this topic. What a farce. For the last several weeks, > > I've been trying > > > > to get several ostensibly mature implementations to > > interoperate using > > > > certs, and I've not had much success. How sad. > > > > > > > > Scott > > > > > > From owner-ipsec@lists.tislabs.com Wed Apr 23 16:02:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NN2dt2044476; Wed, 23 Apr 2003 16:02:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27661 Wed, 23 Apr 2003 18:25:22 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <385918F84B55DC4E9542E0A4812F4131074AE7@us0exb01.us.sonicwall.com> References: <385918F84B55DC4E9542E0A4812F4131074AE7@us0exb01.us.sonicwall.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 23 Apr 2003 15:30:07 -0700 To: jknowles@SonicWALL.com, , From: Paul Hoffman / VPNC Subject: RE: Confirm decision on identity handling. Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:47 AM -0700 4/23/03, jknowles@SonicWALL.com wrote: >I think the purpose of the ID payload when using >certs is (was) to specify which of several possible IDs >contained in the cert should be used for policy >lookup. There is nothing in the IKEv2 spec that says this, and there is nothing in RFC 2409 that says this. Hence, the desire for more specificity in IKEv2. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Apr 23 16:05:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NN5bt2044550; Wed, 23 Apr 2003 16:05:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27698 Wed, 23 Apr 2003 18:31:42 -0400 (EDT) Message-ID: <3EA714F9.8DE4B6A1@airespace.com> Date: Wed, 23 Apr 2003 15:34:33 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman / VPNC CC: jknowles@SonicWALL.com, ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <385918F84B55DC4E9542E0A4812F4131074AE7@us0exb01.us.sonicwall.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2003 22:36:03.0049 (UTC) FILETIME=[B8974590:01C309E8] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC wrote: > > At 11:47 AM -0700 4/23/03, jknowles@SonicWALL.com wrote: > >I think the purpose of the ID payload when using > >certs is (was) to specify which of several possible IDs > >contained in the cert should be used for policy > >lookup. > > There is nothing in the IKEv2 spec that says this, and there is > nothing in RFC 2409 that says this. Hence, the desire for more > specificity in IKEv2. > And since the decision as to which ID will be used for this purpose is left to the receiver, it is not clear that the ID payload could ever be reliably used this way... Scott From owner-ipsec@lists.tislabs.com Wed Apr 23 16:26:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NNQDt2045497; Wed, 23 Apr 2003 16:26:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27787 Wed, 23 Apr 2003 18:50:32 -0400 (EDT) From: jknowles@SonicWALL.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Confirm decision on identity handling. Date: Wed, 23 Apr 2003 15:55:21 -0700 Message-ID: <385918F84B55DC4E9542E0A4812F413106E297@us0exb01.us.sonicwall.com> Thread-Topic: Confirm decision on identity handling. Thread-Index: AcMJ5+qF3vSJcyMjTMeEQ3jLxaazBQAApgZg To: , , X-OriginalArrivalTime: 23 Apr 2003 22:55:21.0686 (UTC) FILETIME=[6B313F60:01C309EB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA27784 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Paul, Right, but 2407 says: "When an IKE exchange is authenticated using certificates (of any format), any ID's used for input to local policy decisions SHOULD be contained in the certifcate used in the authentication of the exchange." So, we've got a relationship betweed ID payload, cert, and policy. Maybe I've overextended that relationship. Regards, Jim > -----Original Message----- > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > Sent: Wednesday, April 23, 2003 3:30 PM > To: Jim Knowles; scott@airespace.com; ipsec@lists.tislabs.com > Subject: RE: Confirm decision on identity handling. > > > At 11:47 AM -0700 4/23/03, jknowles@SonicWALL.com wrote: > >I think the purpose of the ID payload when using > >certs is (was) to specify which of several possible IDs > >contained in the cert should be used for policy > >lookup. > > There is nothing in the IKEv2 spec that says this, and there is > nothing in RFC 2409 that says this. Hence, the desire for more > specificity in IKEv2. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Wed Apr 23 17:11:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3O0B7t2047079; Wed, 23 Apr 2003 17:11:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27963 Wed, 23 Apr 2003 19:31:01 -0400 (EDT) From: jknowles@SonicWALL.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Confirm decision on identity handling. Date: Wed, 23 Apr 2003 16:35:50 -0700 Message-ID: <385918F84B55DC4E9542E0A4812F413106E298@us0exb01.us.sonicwall.com> Thread-Topic: Confirm decision on identity handling. Thread-Index: AcMJ6LozlZtBWlRVQ3G5SwGjUMffxAAAtM6w To: , Cc: X-OriginalArrivalTime: 23 Apr 2003 23:35:51.0280 (UTC) FILETIME=[1357DF00:01C309F1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA27959 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, Sure it could, with prior agreement of the ID to send. This sort of prior agreement does happen, at least sometimes, and may then be useful. Regards, Jim > -----Original Message----- > From: Scott G. Kelly [mailto:scott@airespace.com] > Sent: Wednesday, April 23, 2003 3:35 PM > To: Paul Hoffman / VPNC > Cc: Jim Knowles; ipsec@lists.tislabs.com > Subject: Re: Confirm decision on identity handling. > > > Paul Hoffman / VPNC wrote: > > > > At 11:47 AM -0700 4/23/03, jknowles@SonicWALL.com wrote: > > >I think the purpose of the ID payload when using > > >certs is (was) to specify which of several possible IDs > > >contained in the cert should be used for policy > > >lookup. > > > > There is nothing in the IKEv2 spec that says this, and there is > > nothing in RFC 2409 that says this. Hence, the desire for more > > specificity in IKEv2. > > > > And since the decision as to which ID will be used for this purpose is > left to the receiver, it is not clear that the ID payload > could ever be > reliably used this way... > > Scott > From mHhirhdZikh@www.fr.bw.schule.de Wed Apr 23 23:48:34 2003 Received: from 62.56.189.205 ([61.159.191.4]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3O6mRt2066238 for ; Wed, 23 Apr 2003 23:48:30 -0700 (PDT) (envelope-from mHhirhdZikh@www.fr.bw.schule.de) Date: Wed, 23 Apr 2003 23:48:27 -0700 (PDT) X-SpamLevel: Mqdijqzj5Aj448EPDAmugyW--1089824127 Received: from 98.29.26.152 (HELO aamcinfo.aamc.org) (98.29.26.152) by mail.newmedia-net.de with ESMTP id for ; Wed, 5 Mar 2003 02:03:11 -0600 X-Mailer: IFM Report system Message-Id: <5.1.3.159751153.ROwSP9TJ@lists.esu16.org> To: "ietf-ipsec@vpnc.org" From: "Lucia Strouse" Subject: ADV: Proven effective, male sexual enhancement. Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="==PzkmfHDlsEOG" 1YT1bWzIdUBXQw08TsNkazHJx5llDtUKo6pbfgFpquOVD problem and its fix. --==PzkmfHDlsEOG Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 Cgo8aHRtbD4KPGhlYWQ+PC9oZWFkPgo8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIj4KPGNlbnRl cj4KPGJyPgo8IS0tMTYwMzEwMjYxOS0tPjxhIGhyZWY9Imh0dHA6Ly8xOTMuMjMxLjI0OC43 Mi92My9pbmRleC5waHA/ZWcyMDAyIj48aW1nIGJvcmRlcj0wIHNyYz0iaHR0cDovLzE5My4y MzEuMjQ4Ljc5L2dwMS5naWYiID48L2E+Cjxicj48YnI+Cjxmb250IHNpemU9Ii0yIj4KVGhp cyBvZmZlciBpcyBicm91Z2h0IHRvIHlvdSBieSBIZWFsdGggYW5kIEZpdCAzMDAwLCBJbmMu IElmIHlvdSB3aXNoIHRvIGJlIHJlbW92ZWQgYW5kIG5vdCByZWNlaXZlIG1haWwgZnJvbSB1 cywgcGxlYXNlIDxhIGhyZWY9Imh0dHA6Ly8xOTMuMjMxLjI0OC43Mi9yZW1vdmUucGhwP2Vn MjAwMiI+Z28gaGVyZS48L2E+Cjxicj4KPC9mb250Pgo8L2NlbnRlcj4KPCEtLTE5OTcwMDMx NDctLT4KPCEtLQpyZXN0cmljdGlvbnMgLSBhbHNvIHNlcnZpbmcgYXMgYSBtZWNoYW5pc20g b2YgcHJvdmlkaW5nIHBlZXIgcmV2aWV3IG9mCiJXaGF0IE5ldyBaZWFsYW5kIG5hdGl2ZSB3 YXMgdGhlIGZpcnN0IG1hbiB0byBjbGltYiBNdC4gRXZlcmVzdD8iICJTaXIgRWRtdW5kIEhp bGxhcnkiCi0tPgo8L2JvZHk+PC9odG1sPgoK --==PzkmfHDlsEOG-- From owner-ipsec@lists.tislabs.com Thu Apr 24 07:06:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OE6ct2005877; Thu, 24 Apr 2003 07:06:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00461 Thu, 24 Apr 2003 09:18:30 -0400 (EDT) Message-ID: <3EA76924.5050308@roc.co.in> Date: Thu, 24 Apr 2003 10:03:40 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jyothi CC: ipsec@lists.tislabs.com Subject: Re: Question on inbound IPSEC policy check References: <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> Content-Type: multipart/alternative; boundary="------------070502010400060109020900" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------070502010400060109020900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jyothi, Since, the SPD policies are ordered list and priority of the SPD policies should be followed to check the validity of the decrypted packets w.r.t security policy. SG1 will drop the unencrypted packets coming from SG2 Regards, Ravi Jyothi wrote: > Hi all, > > I have a question regarding the inbound SPD policy checking. > > Please consider the following scenario: > > Office1Network-----SG1---------Internet------------SG2-------Office2Network. > > > Office1Network has HTTP as well as other services hosted. > Office1 administartor wants to make sure that all HTTP traffic has to > go with > 3DES and SHA1 > > And all other traffic can go with AH MD5 and no encyrption is required > for > performance reasons. > > In this case, if office2Network SG is mis-configured or they did not even > configure HTTP policy. > > Then SG1 accepts the HTTP traffic and process it. > After IPSEC processing, SHOULD WE ACCEPT THOSE PACKETS OR DROP THOSE > PACKETS, because higher priority SPD policy is created for the HTTP > traffic. > > Any advice on this would be greatly appreciated > > > Thanks in advance, > Jyothi -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------070502010400060109020900 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jyothi, Since, the SPD policies are ordered list and priority of the SPD policies should be followed to check the validity of the decrypted packets w.r.t security policy. SG1 will drop the unencrypted packets coming from SG2 Regards, Ravi Jyothi wrote: >Hi all, > >I have a question regarding the inbound SPD policy checking. > >Please consider the following scenario: > >Office1Network-----SG1---------Internet------------SG2-------Office2Network. > >Office1Network has HTTP as well as other services hosted. >Office1 administartor wants to make sure that all HTTP traffic has to go with >3DES and SHA1 > >And all other traffic can go with AH MD5 and no encyrption is required for >performance reasons. > >In this case, if office2Network SG is mis-configured or they did not even >configure HTTP policy. > >Then SG1 accepts the HTTP traffic and process it. >After IPSEC processing, SHOULD WE ACCEPT THOSE PACKETS OR DROP THOSE PACKETS, because higher priority SPD policy is created for the HTTP traffic. > >Any advice on this would be greatly appreciated > > >Thanks in advance, >Jyothi -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------070502010400060109020900-- --=====================_2014867==_.ALT Content-Type: text/html; charset="us-ascii" Approved: Dob.ipsec >From majordomo-owner Thu Apr 24 00:23:35 2003 Received: from brahma.roc.com ([202.125.87.14]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id AAA28999 Thu, 24 Apr 2003 00:23:30 -0400 (EDT) Received: (from root@localhost) by brahma.roc.com (8.9.3/8.8.7) id KAA18883; Thu, 24 Apr 2003 10:16:25 +0530 Received: from roc.co.in ([202.125.87.14]) by brahma.roc.com (8.9.3/8.8.7) with ESMTP id KAA18874; Thu, 24 Apr 2003 10:16:17 +0530 Message-ID: <3EA76924.5050308@roc.co.in> Date: Thu, 24 Apr 2003 10:03:40 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jyothi CC: ipsec@lists.tislabs.com Subject: Re: Question on inbound IPSEC policy check References: <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> Content-Type: multipart/alternative; boundary="------------070502010400060109020900" X-Virus-Scanned: by AMaViS perl-11 --------------070502010400060109020900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jyothi, Since, the SPD policies are ordered list and priority of the SPD policies should be followed to check the validity of the decrypted packets w.r.t security policy. SG1 will drop the unencrypted packets coming from SG2 Regards, Ravi Jyothi wrote: > Hi all, > > I have a question regarding the inbound SPD policy checking. > > Please consider the following scenario: > > Office1Network-----SG1---------Internet------------SG2-------Office2Network. > > > Office1Network has HTTP as well as other services hosted. > Office1 administartor wants to make sure that all HTTP traffic has to > go with > 3DES and SHA1 > > And all other traffic can go with AH MD5 and no encyrption is required > for > performance reasons. > > In this case, if office2Network SG is mis-configured or they did not even > configure HTTP policy. > > Then SG1 accepts the HTTP traffic and process it. > After IPSEC processing, SHOULD WE ACCEPT THOSE PACKETS OR DROP THOSE > PACKETS, because higher priority SPD policy is created for the HTTP > traffic. > > Any advice on this would be greatly appreciated > > > Thanks in advance, > Jyothi -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------070502010400060109020900 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jyothi, Since, the SPD policies are ordered list and priority of the SPD policies should be followed to check the validity of the decrypted packets w.r.t security policy. SG1 will drop the unencrypted packets coming from SG2 Regards, Ravi Jyothi wrote: >Hi all, > >I have a question regarding the inbound SPD policy checking. > >Please consider the following scenario: > >Office1Network-----SG1---------Internet------------SG2-------Office2Network. > >Office1Network has HTTP as well as other services hosted. >Office1 administartor wants to make sure that all HTTP traffic has to go with >3DES and SHA1 > >And all other traffic can go with AH MD5 and no encyrption is required for >performance reasons. > >In this case, if office2Network SG is mis-configured or they did not even >configure HTTP policy. > >Then SG1 accepts the HTTP traffic and process it. >After IPSEC processing, SHOULD WE ACCEPT THOSE PACKETS OR DROP THOSE PACKETS, because higher priority SPD policy is created for the HTTP traffic. > >Any advice on this would be greatly appreciated > > >Thanks in advance, >Jyothi -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------070502010400060109020900-- --=====================_2014867==_.ALT-- From owner-ipsec@lists.tislabs.com Thu Apr 24 08:03:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OF3Pt2010207; Thu, 24 Apr 2003 08:03:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00701 Thu, 24 Apr 2003 10:27:37 -0400 (EDT) To: "C. M. Heard" Cc: IPsec WG , "Wijnen, Bert (Bert)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories References: Date: Thu, 24 Apr 2003 07:32:18 -0700 In-Reply-To: ("C. M. Heard"'s message of "Wed, 23 Apr 2003 00:11:11 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> On Wed, 23 Apr 2003 00:11:11 -0700 (PDT), "C. M. Heard" said: C> Presumably, the proposed text is intended to replace the third C> paragraph of the DESCRIPTION clause of this TC. (yes, although it was an "example". I was hoping it would be used as a template for the rest of the TCs being discussed too). C> Observe that it is not permissible to specify something like this C> SYNTAX IpsecDoiSecProtocolId { C> protoIsakmp(1), C> protoIpsecAh(2), C> protoIpsecEsp(3), C> protoIpcomp(4), C> protoIpsecCompanyProprietary(249) C> } C> in a VARIATION clause of an AGENT-CAPABILITIES statement. That is C> an illegal refinement, and at least some MIB compilers (SMICng is C> one) will reject it. Sad, unfortunately. Ok, if that is illegal than it'll have to be described in a DESCRIPTION clause, as you mentioned. (there are many types of agent exceptions/changes that can only be documented in the description clause). It's likely the need to document these exceptions will be rare, fortunately. C> My conclusion is still that use of enumerated INTEGER in a manner C> that is inconsistent with the semantics defined in the SMIv2 RFCs C> is something to be avoided. We'll likely just have to disagree when this discussion is over, I'm sure. I do understand your point of view, of course and I think you understand mine so we're probably out of things to say :-/ -- Wes Hardaker Network Associates Laboratories From owner-ipsec@lists.tislabs.com Thu Apr 24 08:38:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OFcrt2014338; Thu, 24 Apr 2003 08:38:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00786 Thu, 24 Apr 2003 11:07:21 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 24 Apr 2003 08:12:12 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: IPsec WG cc: Wes Hardaker , "Wijnen, Bert (Bert)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 24 Apr 2003, Wes Hardaker wrote: > We'll likely just have to disagree when this discussion is over, I'm > sure. I do understand your point of view, of course and I think you > understand mine so we're probably out of things to say :-/ I think that is a fair assessment, and it is time to move on. I shall attempt to get the MIB review comments written up not later than next Monday, 28 April 2003. //cmh From owner-ipsec@lists.tislabs.com Thu Apr 24 11:42:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OIg4t2022152; Thu, 24 Apr 2003 11:42:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01293 Thu, 24 Apr 2003 13:52:17 -0400 (EDT) Message-ID: <3EA8207A.7030002@sockeye.com> Date: Thu, 24 Apr 2003 13:35:54 -0400 From: John Shriver Organization: Sockeye Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "C. M. Heard" CC: Wes Hardaker , IPsec WG , "Wijnen, Bert (Bert)" Subject: Re: IANA administrative issues with draft-ietf-ipsec-doi-tc-mib-07.txt References: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk C. M. Heard wrote: > Notes: > (a) In the case of IkeNotifyMessageType, only those > enumerated values within the DOI-specific ranges 8192-16383 and > 24576-32767 are recorded in the registry. The IkeNotifyMessageType > TC also includes the DOI-independent values that are defined in RFC > 2408 Section 3.14.1 (and captured by the IsakmpNotifyMessageType > TC). Since the DOI-specific enumerations associated with the > IkeNotifyMessageType TC are defined in RFC 2407 rather than RFC > 2409, it seems that it is mis-named and should probably have been > called IpsecDoiNotifyMessageType. While these numbers may be defined in RFC 2407, they are not generic ISAKMP numbers, they are specific to the use of IKE over ISAKMP. The TC-MIB was sectioned in what was believed to be a rational way, based on the real layering of the protocols. (The same applied to the MIBs that were developed along with it, one was pure IPsec, the next was ISAKMP, the next was IKE.) The partitioning was not artifically "adjusted" to match odd partitioning of the protocols between the RFCs, and instead reflects the real layering. Ironically, IKEv2 removes some of this layering. As for the duplication of values between IsakmpNotifyMessageType and IkeNotifyMessageType, that is necessary because the SMI doesn't allow a syntax for an object that is the "union" of several enumerations or TC's. > (b) The registry specifies that values in the range > 8192-16383 are error codes allocated for "private use within a > DOI". This agrees with RFC 2407 but apparently disagrees with RFC > 2408, which states that values in this range are for private use > (but also states that values in the private use range are expected > to be DOI-specific values). The registry (and RFC 2407) also > specify that status codes in the range 32001-32767 are reserved > for private use among consenting systems; however, while RFC 2408 > does allocates status codes in the range 24576-32767 for > DOI-specific use, it also allocates status codes in the range > 32768-40959 for private use. This confusion needs to be fixed. Are you complaining about RFC 2407 and RFC 2408 being inconsistent and disagreeing? This part of why IKEv2 is being documented in one document, to simplify ensuring internal consistency. An ISAKMP DOI is apparently rather free to redefine what ISAKMP itself doesn't define. I don't think that this issue is worth much concern, because ISAKMP will be irrelevant when IKEv2 is baked. Interestingly, IKEv2 deprecates a group of these values, and defines a good dozen new ones. (If someone wants to argue that the TC-MIB should be "collapsed" a bit in anticipation of IKEv2, that's not that bad an idea, although it would break other MIBs that depend on it.) (IKEv2 was one of the reasons that I figured this MIB project was lingering, IKEv1 isn't going to reach Full Standard.) > > The parameters and attributes from the IANA Internet Security > Association and Key Management Protocol (ISAKMP) Identifiers > registry (http://www.iana.org/assignments/isakmp-registry) that are > NOT captured by any textual convention in the draft are as follows: > > IPSEC Security Association Attribute Class > SA Life Type > SA Life Duration > Group Description > Key Length > Key Rounds > Compression Dictionary Size > Compression Private Algorithm > ECN Tunnel > IPSEC Labeled Domain Identifier > This is a possible argument for not making the TC-MIB the definitive reference on the IANA assignments. Another approach would be to refactor the assignments, those that are in the TC-MIB move there, and the rest stay in the plain text files. > > The attributes from the IANA Internet Key Exchange (IKE) Attributes > registry (http://www.iana.org/assignments/ipsec-registry) that are > captured by some textual convention in the draft are as follows: > > Attribute Name Textual Convention > > Encryption Algorithm IkeEncryptionAlgorithm > Hash Algorithm IkeHashAlgorithm > IPSEC Authentication Methods IkeAuthMethod > Group Description IkeGroupDescription > Group Type IkeGroupType > PRF IkePrf > Additional Exchanges (XCHG values) IkeExchangeType > > Notes: > (a) In the case of IkeExchangeType, only those enumerated > values within the DOI-specific range 32-239 are recorded in the > registry. The IkeExchangeType TC also includes the DOI-independent > values that are defined in RFC 2408 Section 3.1 (and captured by > the IsakmpExchangeType TC). Yes, I see that the supersetting/nesting of the TC's makes it awkward to use this TC-MIB as the definitive IANA reference for these values. > (b) No PRF values are currently registered, and IkePrf is > a subranged Unsigned32 type, not an enumerated INTEGER type. > Since Unsigned32 and INTEGER have different over-the-wire > representations and Unsigned32 does not admit enumerations, the > base type would need to be changed to INTEGER in order for future > registered values to be represented as enumerations. No problem changing this to INTEGER, since it's got enough precision to handle 0-65535. On the other hand, if we're not doing enumerations (except in DESCRIPTION), it's moot, and the real protocol number is an "Unsigned16", which is more like Unsigned32 than it is like INTEGER. > > The attributes from the IANA Internet Key Exchange (IKE) Attributes > registry (http://www.iana.org/assignments/ipsec-registry) and/or > RFC 2409 that are NOT captured by any textual convention in the > draft are as follows: > > Attribute Class > Group Prime/Irreducible Polynomial > Group Generator One > Group Generator Two > Group Curve A > Group Curve B > Life Type > Life Duration > Key Length > Field Size > Group Order > > Note: Group Prime/Irreducible Polynomial, Group Generator One, > Group Generator Two, Group Curve A, Group Curve B, and Life > Duration are such that management of values by the IANA is not > required, and their values are not listed in the IKE Attributes > registry; however, they are defined in RFC 2409 and TCs to > represent them might be useful (although they might best be > located in a MIB module that is not maintained by the IANA). Since there were no magic values, these group numbers were not TC'd. The IKE Monitoring MIB did have tables with them in them (OCTET STRING (SIZE (0..511)), however I think that some of the latest groups probably have generators larger than 511 bytes (or the next generation will). > > Certain of the textual conventions in the proposed MIB module > capture parameters and attributes which are not recorded in either > of the above-mentioned IANA registries, but which are mentioned in > the IPsec RFCs and in a a registry update proposal (accessible > on-line at http://www.vpnc.org/iana-ipsec/current-propsal.txt) > that was recently discussed on the ipsec@lists.tislabs.com mailing > list. Here is the list of the "missing in action" TCs and where > the corresponding parameter or attribute is mentioned: > > Textual Convention Where param or attrib is mentioned > > IsakmpDOI RFC 2407 Section 4.1, > RFC 2408 Appendix A > (see proposal item #16) > > IsakmpCertificateEncoding RFC 2408 Section 3.9 > (see proposal item #13) > > IsakmpExchangeType RFC 2408 Section 3.1 > (see proposal item #12, but > note that it includes both > the DOI-independent stuff in > RFC 2408 Section 3.1 and > the the stuff discussed in > RFC 2409 appendix A that > is specific to IKE, and so > corresponds more precisely > to the IkeExchangeType TC) > > IsakmpNotifyMessageType RFC 2408 Section 3.14.1 > (see proposal item #10, but > note that it includes both > the DOI-independent stuff in > RFC 2408 Section 3.14.1 and > the the stuff discussed in > RFC 2407 Section 4.6.3 that > is specific to the IPsec > DOI, and so corresponds > more precisely to the > IkeNotifyMessageType TC) > > I hope that this comparison serves to shed some light on the > amount of work that would be necessary if the MIB module in > is turned over to the IANA for > maintenance. If the IPsec-related registry files remain structured > as they are presently, there will be a need to update at least one > TC (and in some cases two TCs) when a new value is registered for > most IPsec parameters. If the TCs in the MIB module become > authoritative and duplication is eliminated, then there will be a > lot of restructuring work needed. In either case the administrative > burden is non-trivial, and I think that is a reason for concern. > None of this would be necessary if the base types of the TCs were > changed to subranged Unsigned32 (like IkePrf) with a pointer where > appropriate to the existing IANA registry. Changing from enumerations to Unsigned32 does not solve the maintenance problem. We still want to keep the descriptions up to date. If we don't keep the descriptions up to date, we might as well not have a TC-MIB. Cut & paste will do in that case... > > So the question (leaving aside for the moment the questions of > legality under SMI rules) is whether the benefits of having the > enumeration labels are worth the administrative burden. Remember > the burden will be borne not only by the IANA but also by document > authors who have to generate the instructions to add new things to > the registries. On the other hand, the number of assignments has been small. Most have been efforts to work around the limitations of ISAKMP/IKEv1. With IKEv2 being far more feature-rich (requirements based), I suspect that there will be even less change. I can fully see either of two alternatives: 1. IANA refactors the IPsec registries to eliminate overlap with the TC-MIB, and the TC-MIB is authoritative on what it covers. 2. IANA maintains the TC-MIB separately, keeping it in sync with the registries. I do not see the alternative of maintaining the TC-MIB under the RFC process as useful, since that will prevent anything using it as a normative reference from ever reaching Full Standard. > > Mike Heard John Shriver From owner-ipsec@lists.tislabs.com Thu Apr 24 11:57:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OIv5t2022493; Thu, 24 Apr 2003 11:57:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01356 Thu, 24 Apr 2003 14:12:10 -0400 (EDT) Message-Id: <5.2.0.9.0.20030424110716.02afbcc0@mail.attbi.com> X-Sender: alten@mail.attbi.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 24 Apr 2003 11:12:59 -0700 To: ipsec@lists.tislabs.com From: Alex Alten Subject: Fwd: exporting IPsec? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've gotten a number of private replies. I wanted to thank those people for responding. My main interest is to see if the key management of IPsec has caused any problems with getting an export license. Does the end-to-end nature of it make a license more restrictive? Say in comparison to SSL? (Actually I'd expect SSL to be more restrictive since it internally generates the session keys.) - Alex >Date: Sat, 12 Apr 2003 12:35:25 -0700 >To: ipsec@lists.tislabs.com >From: Alex Alten >Subject: exporting IPsec? > > >Has anyone on this list encountered any issues with >exporting IPsec from USA/Canada to other countries? >In particular I'd curious to know what types of restrictions; >key length, countries approved (or not), escrow requirements, >product type restrictions (network hardware, software), etc. > >Did you have to maintain two types of product one for North >America and the other for overseas? > >I'm not looking for names in particular, just whether or not >the BXA would approve (or not) types of IPsec products >to areas of the planet (Europe, Asia, etc.), and what types of >restrictions were placed on successful export licenses. > >Also, out of curiosity, has Sept. 11th caused any tightening >of the export requirements? Are you finding it harder to get >BXA license approval? > >- Alex > >-- > >Alex Alten >Alten@ATTBI.com > -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Thu Apr 24 15:54:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OMsQt2032152; Thu, 24 Apr 2003 15:54:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02339 Thu, 24 Apr 2003 18:06:41 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 24 Apr 2003 15:11:30 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: IPsec WG cc: Wes Hardaker , "Wijnen, Bert (Bert)" Subject: Re: IANA administrative issues with draft-ietf-ipsec-doi-tc-mib-07.txt In-Reply-To: <3EA8207A.7030002@sockeye.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 24 Apr 2003, John Shriver wrote: > C. M. Heard wrote: > > > Notes: > > (a) In the case of IkeNotifyMessageType, only those > > enumerated values within the DOI-specific ranges 8192-16383 and > > 24576-32767 are recorded in the registry. The IkeNotifyMessageType > > TC also includes the DOI-independent values that are defined in RFC > > 2408 Section 3.14.1 (and captured by the IsakmpNotifyMessageType > > TC). Since the DOI-specific enumerations associated with the > > IkeNotifyMessageType TC are defined in RFC 2407 rather than RFC > > 2409, it seems that it is mis-named and should probably have been > > called IpsecDoiNotifyMessageType. > > While these numbers may be defined in RFC 2407, they are not generic > ISAKMP numbers, they are specific to the use of IKE over ISAKMP. > > The TC-MIB was sectioned in what was believed to be a rational > way, based on the real layering of the protocols. (The same > applied to the MIBs that were developed along with it, one was > pure IPsec, the next was ISAKMP, the next was IKE.) The > partitioning was not artifically "adjusted" to match odd > partitioning of the protocols between the RFCs, and instead > reflects the real layering. OK, thanks for educating me on this point. I assumed that the DOI-specific message types pertained to the IPsec DOI of ISAKMP (rather than IKE) partly because of the following words in the DESCRIPTION clause of the IkeNotifyMessageType TC: This textual convention is a merge of values defined by ISAKMP with the additional values defined in the IPsec DOI. On this point I'll most certainly defer to those who actually know what goes on in these protocols. > Ironically, IKEv2 removes some of this layering. > > As for the duplication of values between IsakmpNotifyMessageType > and IkeNotifyMessageType, that is necessary because the SMI > doesn't allow a syntax for an object that is the "union" of > several enumerations or TC's. That was understood. > > (b) The registry specifies that values in the range > > 8192-16383 are error codes allocated for "private use within a > > DOI". This agrees with RFC 2407 but apparently disagrees with RFC > > 2408, which states that values in this range are for private use > > (but also states that values in the private use range are expected > > to be DOI-specific values). The registry (and RFC 2407) also > > specify that status codes in the range 32001-32767 are reserved > > for private use among consenting systems; however, while RFC 2408 > > does allocates status codes in the range 24576-32767 for > > DOI-specific use, it also allocates status codes in the range > > 32768-40959 for private use. This confusion needs to be fixed. > > Are you complaining about RFC 2407 and RFC 2408 being > inconsistent and disagreeing? Yes :) > This part of why IKEv2 is being documented in one > document, to simplify ensuring internal consistency. OK. Thanks for the education. > An ISAKMP DOI is apparently rather free to redefine what ISAKMP > itself doesn't define. > > I don't think that this issue is worth much concern, because > ISAKMP will be irrelevant when IKEv2 is baked. What _is_ relevant is what to put in the TC DESCRIPTION clause with respect to the use to which various ranges in the number space are put. I guess that at this point the "de-facto" standard is the usage in RFC 2407, since the registry agrees with it. > Interestingly, IKEv2 deprecates a group of these values, and > defines a good dozen new ones. (If someone wants to argue that > the TC-MIB should be "collapsed" a bit in anticipation of IKEv2, > that's not that bad an idea, although it would break other MIBs > that depend on it.) If the IPsec assigned number registries remain intact, it is possible to write the MIB module in a way that is immune from such changes. Details appear below. > > The parameters and attributes from the IANA Internet Security > > Association and Key Management Protocol (ISAKMP) Identifiers > > registry (http://www.iana.org/assignments/isakmp-registry) that are > > NOT captured by any textual convention in the draft are as follows: > > > > IPSEC Security Association Attribute Class > > SA Life Type > > SA Life Duration > > Group Description > > Key Length > > Key Rounds > > Compression Dictionary Size > > Compression Private Algorithm > > ECN Tunnel > > IPSEC Labeled Domain Identifier > > > > This is a possible argument for not making the TC-MIB the > definitive reference on the IANA assignments. > > Another approach would be to refactor the assignments, those > that are in the TC-MIB move there, and the rest stay in the > plain text files. I agree that those two approaches could be made to work. > > The attributes from the IANA Internet Key Exchange (IKE) Attributes > > registry (http://www.iana.org/assignments/ipsec-registry) that are > > captured by some textual convention in the draft are as follows: > > > > Attribute Name Textual Convention > > > > Encryption Algorithm IkeEncryptionAlgorithm > > Hash Algorithm IkeHashAlgorithm > > IPSEC Authentication Methods IkeAuthMethod > > Group Description IkeGroupDescription > > Group Type IkeGroupType > > PRF IkePrf > > Additional Exchanges (XCHG values) IkeExchangeType > > > > Notes: > > (a) In the case of IkeExchangeType, only those enumerated > > values within the DOI-specific range 32-239 are recorded in the > > registry. The IkeExchangeType TC also includes the DOI-independent > > values that are defined in RFC 2408 Section 3.1 (and captured by > > the IsakmpExchangeType TC). > > Yes, I see that the supersetting/nesting of the TC's makes it awkward to > use this TC-MIB as the definitive IANA reference for these values. Right, because of the update-in-two-places problem. [ ... remainder snipped ... ] > > I hope that this comparison serves to shed some light on the > > amount of work that would be necessary if the MIB module in > > is turned over to the IANA for > > maintenance. If the IPsec-related registry files remain structured > > as they are presently, there will be a need to update at least one > > TC (and in some cases two TCs) when a new value is registered for > > most IPsec parameters. If the TCs in the MIB module become > > authoritative and duplication is eliminated, then there will be a > > lot of restructuring work needed. In either case the administrative > > burden is non-trivial, and I think that is a reason for concern. > > None of this would be necessary if the base types of the TCs were > > changed to subranged Unsigned32 (like IkePrf) with a pointer where > > appropriate to the existing IANA registry. > > Changing from enumerations to Unsigned32 does not solve the > maintenance problem. We still want to keep the descriptions up > to date. If we don't keep the descriptions up to date, we might > as well not have a TC-MIB. Cut & paste will do in that case... I don't agree with that. The SnmpSecurityModel TC in RFC 3411 (which is an Internet Standard) provides an alternate model that avoids the maintenance problems. An example modelled after it is provided below. > > So the question (leaving aside for the moment the questions of > > legality under SMI rules) is whether the benefits of having the > > enumeration labels are worth the administrative burden. Remember > > the burden will be borne not only by the IANA but also by document > > authors who have to generate the instructions to add new things to > > the registries. > > On the other hand, the number of assignments has been small. Most > have been efforts to work around the limitations of ISAKMP/IKEv1. > With IKEv2 being far more feature-rich (requirements based), I > suspect that there will be even less change. > > I can fully see either of two alternatives: > > 1. IANA refactors the IPsec registries to eliminate overlap with the > TC-MIB, and the TC-MIB is authoritative on what it covers. > > 2. IANA maintains the TC-MIB separately, keeping it in sync with the > registries. Those alternatives can indeed be made to work. Both impose some extra administrative burden on the IANA. #1 does so once up front, #2 does so on an ongoing basis. > I do not see the alternative of maintaining the TC-MIB under the > RFC process as useful, since that will prevent anything using it > as a normative reference from ever reaching Full Standard. Again, I don't agree with that. Using IpsecDoiSecProtocolId as an example, here is how one could re-write the TCs in the IPSEC-ISAKMP-IKE-DOI-TC module so as to avoid the need to track updates to the registry. This is modelled after the SnmpSecurityModel TC in RFC 3411, but incorporates the suggestion from Dave Perkins to include a pointer to the registry where assignments can be found. It also incorporates the suggestion from Wes Hardaker to recommend that "private use" values be documented in an AGENT-CAPABILITIES statement if they are used. IpsecDoiSecProtocolId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Objects of this type represent IPsec DOI values for the IP Security Protocol Identifier (Protocol ID) field in an ISAKMP Proposal Payload, and in all Notification Payloads. They may also represent values of the Protocol ID field in the Notification Payload and the Delete Payload. The value zero does not identify any particular security protocol. It MAY be used in MIB objects to indicate that the security protocol is unknown or that none applies. Any such use MUST be documented in the MIB object's DESCRIPTION clause. Values between 1 and 248, inclusive, are managed by the Internet Assigned Numbers Authority (IANA). Assigned values are recorded in the IPSEC Security Protocol Identifiers section of the IANA Internet Security Association and Key Management Protocol (ISAKMP) Identifiers registry (a URL for which is http://www.iana.org/assignments/isakmp-registry). The values 249-255 are reserved for private use amongst cooperating systems. It is RECOMMENDED that implementations document the usage of such values in an AGENT-CAPABILITIES statement." REFERENCE "RFC 2407 sections 4.4.1 and 6.2" SYNTAX Unsigned32 (0..255) Some wordsmithing may of course be necessary or desirable. Changes (if any) as the MIB module advances on the standards track could include updates to the STATUS clause (a TC might be deprecated if it became obsolete, or if it was not used in defining objects contained in two implementations), to the DESCRIPTION clause (e.g., if the URL of the registry changes -- one hopes not, those things need to be stable), or the REFERENCE clause (if new documents are issued). But new number assignments would not have any effect, and so would not hinder advancement on the standards track. The disadvantage of this approach (as we all know by now) is the loss of some machine readable information. The advantages are that it does not conflict with the formal requirements of the SMI and that it does not impose any administrative burden on the IANA. Does anyone else (other than John Shriver, Wes Hardaker, or myself) care to express an opinion on these matters? //cmh From owner-ipsec@lists.tislabs.com Fri Apr 25 11:55:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PIttt2022625; Fri, 25 Apr 2003 11:55:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05616 Fri, 25 Apr 2003 14:11:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> References: <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> Date: Fri, 25 Apr 2003 14:13:59 -0400 To: Jyothi From: Stephen Kent Subject: Re: Question on inbound IPSEC policy check Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:03 PM +0530 4/23/03, Jyothi wrote: >Hi all, > >I have a question regarding the inbound SPD policy checking. > >Please consider the following scenario: > >Office1Network-----SG1---------Internet------------SG2-------Office2Network. > >Office1Network has HTTP as well as other services hosted. >Office1 administartor wants to make sure that all HTTP traffic has to go with >3DES and SHA1 > >And all other traffic can go with AH MD5 and no encyrption is required for >performance reasons. > >In this case, if office2Network SG is mis-configured or they did not even >configure HTTP policy. > >Then SG1 accepts the HTTP traffic and process it. >After IPSEC processing, SHOULD WE ACCEPT THOSE PACKETS OR DROP THOSE >PACKETS, because higher priority SPD policy is created for the HTTP >traffic. > >Any advice on this would be greatly appreciated > > >Thanks in advance, >Jyothi Yes, the exit check at SG1 should reject traffic that has either source or dest port = 80, consistent with the policy you articulated above. From owner-ipsec@lists.tislabs.com Fri Apr 25 13:08:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PK8ht2024936; Fri, 25 Apr 2003 13:08:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06159 Fri, 25 Apr 2003 15:37:02 -0400 (EDT) Message-Id: <200304251940.h3PJes820577@yogi> X-Mailer: exmh version 2.6.2 03/21/2003 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: IKEV2 - INVALID_KE_PAYLOAD not defined Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Apr 2003 14:40:54 -0500 From: "Stephen C. Koehler" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I noticed that draft 7 refers to INVALID_KE_PAYLOAD (e.g., in section 2.6), but this notify message is not defined in the section on the notify payload. Procedural question: is it better to post minor issues, like this, to the list, or should these go directly to the editor? -- Steve Koehler koehler@securecomputing.com From owner-ipsec@lists.tislabs.com Fri Apr 25 15:03:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PM3qt2028830; Fri, 25 Apr 2003 15:03:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06532 Fri, 25 Apr 2003 17:33:38 -0400 (EDT) Message-ID: <82CC1E573B94A648B87027C9419E2C055A6FF3@losgatos> From: Michael Choung Shieh To: "'ddukes@cisco.com'" , Ravi , ipsec@lists.tislabs.com Subject: RE: Peer liveliness Date: Fri, 25 Apr 2003 14:30:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk you won't achieve interoperability unless it's mandated that everyone must reply INVALID_SPI (in clear or initiate IKE back to the sender) whenever it receives bad spi packets. Current IKEv2 draft doesn't address this issue (only states you MAY reply a clear notify message). IKEv1 vendors has implemented many ways to solve it which leave poor interoperability. We should just pick a method and clarify it in IKEv2. =============== Michael Shieh -----Original Message----- From: Darren Dukes [mailto:ddukes@cisco.com] Sent: Monday, April 21, 2003 11:28 AM To: Ravi; ipsec@lists.tislabs.com Subject: RE: Peer liveliness > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Ravi > Sent: Friday, April 18, 2003 1:06 AM > To: ipsec@lists.tislabs.com > Subject: Peer liveliness > > > Hi, > I was going through several drafts related to peer liveliness. > But, some of practical > problems faced in actual deployment may not be solved by these > proposals. > INITIAL_CONTACT Notification : It indicates that the Peer was > dead and cameback. > DPD: Checks the liveliness of the peer. > I feel, we require interoperable solution to check liveliness > of SA ie Dead Peer SA detection > (DPSD). I believe INVALID_SPI does what you are looking for. If I receive an INVALID_SPI notify via an IKE SA I know to delete the SA and traffic will bring up a new one. Darren > DPD specification can be enhanced to achieve this. > Protocol-ID and SPI fields can be made mandatory. > Protocol-ID can be ESP/AH/IKE. > SPI : In case of IKE, it could be cookies and in case of > ESP/AH, it is SPI (inbound SA's SPI > on the peer). > If peer is not dead, but SAs were deleted either due to > temporary failure OR due to > restarting of some processes in the system can be detected with > this mechanism. > Does this makes sense? If so, I can contribute text to this effect. > Regards, > Ravi > > > > -- > > > The views presented in this mail are completely mine. The company > is not responsible for whatsoever. > > > Ravi Kumar CH > Rendezvous On Chip (i) Pvt Ltd > Hyderabad, India > Ph: +91-40-2335 1214 / 1175 / 1184 > > ROC home page From owner-ipsec@lists.tislabs.com Fri Apr 25 17:22:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3Q0Mpt2033972; Fri, 25 Apr 2003 17:22:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06931 Fri, 25 Apr 2003 19:47:35 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <3E9F86E9.8070103@roc.co.in> Subject: Re: DPD Notification messages in IKEv2 To: Ravi Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Thu, 24 Apr 2003 21:27:40 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04072003NP|April 07, 2003) at 04/25/2003 07:52:12 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Hi, > I did not see any notification messages related to DPD in IKEv2-06 > specifications. > Is there any plan to put these notifications in next version. > Regards, > Ravi The IKEv2 spec has said for some time that an empty exchange (a message with no payloads) can be used for dead peer detection since every message must be acknowledged including an empty one. Is some other form of notification message needed? --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Sat Apr 26 05:21:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3QCLwt2097390; Sat, 26 Apr 2003 05:21:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA09725 Sat, 26 Apr 2003 07:45:20 -0400 (EDT) From: Bill Manning Message-Id: <200304261149.h3QBnb602499@boreas.isi.edu> Subject: Re: Peer liveliness In-Reply-To: <82CC1E573B94A648B87027C9419E2C055A6FF3@losgatos> from Michael Choung Shieh at "Apr 25, 3 02:30:30 pm" To: mshieh@netscreen.com (Michael Choung Shieh) Date: Sat, 26 Apr 2003 04:49:37 -0700 (PDT) Cc: ddukes@cisco.com, ravivsn@roc.co.in, ipsec@lists.tislabs.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [Charset WINDOWS-1252 unsupported, skipping...] Empirical example listed above... :) Why would anyone expect that everyone has Microsoft character set support? Michael states: "you won't achieve interoperability unless it's mandated that everyone must..." which is patently false. Interoperability is achieved when the various parties agree to communicate with a well defined, well known suite of interfaces. Mandating does not carry the weight of implementation. And private/propriatary extentions hinder/cripple adoption of otherwise good ideas. I guess this off-topic rant really focuses on two words in Michaels posting: "You" should be "We" and "everyone" should be "implementations" -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Sat Apr 26 16:56:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3QNuJt2029522; Sat, 26 Apr 2003 16:56:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11656 Sat, 26 Apr 2003 19:15:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Sat, 26 Apr 2003 16:20:38 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Requirements for IKEv2 implementations Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. The -05 draft of IKEv2 introduced the following requirements: For an implementation to be called conforming to this specification, it MUST be possible to configure it to accept the following: PKIX Certificates containing and signed by RSA keys of size 1024 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or ID_DER_ASN1_DN. Shared key authentication where the ID passes is any of ID_KEY_ID, ID_FQDN, or ID_RFC822_ADDR. Authentication where the responder authenticates using PKIX Certificates and the initiator authenticates using shared key authentication. I don't remember seeing this discussed in the WG before now. There are many reasons why an implementation might not want to support PKIX certificates, including the fact that many vendors find that PKIX is too complicated to support securely. In some security environments, other forms of public key infrastructures are more appropriate for some security uses. And, of course, for systems that have the ability to create and distribute good shared secrets, PKIX support is just dangerous bloat. The minimum that is needed for interoperability is shared secrets. The document already has requirements for handling large shared secrets, so we don't need to worry about limitations that reduce to passwords. Requiring both shared secrets *and* PKIX-specific public key support does not help interoperability, and because of the nature of PKIX, hurts it significantly. We only need to mandate one or the other, and given the ugly reality of PKIX, it should only be sufficiently long shared secrets. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sat Apr 26 18:39:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3R1dMt2033257; Sat, 26 Apr 2003 18:39:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA12128 Sat, 26 Apr 2003 21:11:13 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155016A3D30@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "C. M. Heard" , IPsec WG Cc: Wes Hardaker , "Wijnen, Bert (Bert)" Subject: RE: IANA administrative issues with draft-ietf-ipsec-doi-tc-mib-0 7.txt Date: Sat, 26 Apr 2003 18:24:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Let me express that I think that the proposed solution by Mike seems to make a lot of sense to me. That is the answer from Mike to John, as in the folloing extract from a recent email posting: > is Mike > > is John > > I can fully see either of two alternatives: > > > > 1. IANA refactors the IPsec registries to eliminate overlap with the > > TC-MIB, and the TC-MIB is authoritative on what it covers. > > > > 2. IANA maintains the TC-MIB separately, keeping it in sync with the > > registries. > > Those alternatives can indeed be made to work. Both impose some > extra administrative burden on the IANA. #1 does so once up front, > #2 does so on an ongoing basis. > > > I do not see the alternative of maintaining the TC-MIB under the > > RFC process as useful, since that will prevent anything using it > > as a normative reference from ever reaching Full Standard. > > Again, I don't agree with that. Using IpsecDoiSecProtocolId > as an example, here is how one could re-write the TCs in the > IPSEC-ISAKMP-IKE-DOI-TC module so as to avoid the need to > track updates to the registry. This is modelled after the > SnmpSecurityModel TC in RFC 3411, but incorporates the > suggestion from Dave Perkins to include a pointer to the > registry where assignments can be found. It also incorporates > the suggestion from Wes Hardaker to recommend that "private > use" values be documented in an AGENT-CAPABILITIES statement > if they are used. > > IpsecDoiSecProtocolId ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION "Objects of this type represent IPsec DOI values > for the IP Security Protocol Identifier (Protocol > ID) field in an ISAKMP Proposal Payload, and in > all Notification Payloads. They may also represent > values of the Protocol ID field in the Notification > Payload and the Delete Payload. > > The value zero does not identify any particular > security protocol. It MAY be used in MIB objects > to indicate that the security protocol is unknown > or that none applies. Any such use MUST be > documented in the MIB object's DESCRIPTION clause. > > Values between 1 and 248, inclusive, are managed by > the Internet Assigned Numbers Authority (IANA). > Assigned values are recorded in the IPSEC Security > Protocol Identifiers section of the IANA Internet > Security Association and Key Management Protocol > (ISAKMP) Identifiers registry (a URL for which is > http://www.iana.org/assignments/isakmp-registry). > > The values 249-255 are reserved for private use > amongst cooperating systems. It is RECOMMENDED > that implementations document the usage of such > values in an AGENT-CAPABILITIES statement." > REFERENCE "RFC 2407 sections 4.4.1 and 6.2" > SYNTAX Unsigned32 (0..255) > > Some wordsmithing may of course be necessary or desirable. > > Changes (if any) as the MIB module advances on the standards track > could include updates to the STATUS clause (a TC might be deprecated > if it became obsolete, or if it was not used in defining objects > contained in two implementations), to the DESCRIPTION clause (e.g., > if the URL of the registry changes -- one hopes not, those things > need to be stable), or the REFERENCE clause (if new documents are > issued). But new number assignments would not have any effect, and > so would not hinder advancement on the standards track. > > The disadvantage of this approach (as we all know by now) is the > loss of some machine readable information. The advantages are that > it does not conflict with the formal requirements of the SMI and > that it does not impose any administrative burden on the IANA. > > Does anyone else (other than John Shriver, Wes Hardaker, or > myself) care to express an opinion on these matters? > > //cmh > From owner-ipsec@lists.tislabs.com Sun Apr 27 23:20:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3S6Kmt2037578; Sun, 27 Apr 2003 23:20:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA15764 Mon, 28 Apr 2003 01:40:10 -0400 (EDT) Message-Id: <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Apr 2003 11:22:16 +0530 To: Stephen Kent From: Jyothi Subject: Re: Question on inbound IPSEC policy check Cc: ipsec@lists.tislabs.com In-Reply-To: References: <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, If we reject the traffic, how do we inform the peer??? I think there might be some inter-operability issues. Thanks Jyothi At 02:13 PM 4/25/03 -0400, Stephen Kent wrote: >At 1:03 PM +0530 4/23/03, Jyothi wrote: >>Hi all, >> >>I have a question regarding the inbound SPD policy checking. >> >>Please consider the following scenario: >> >>Office1Network-----SG1---------Internet------------SG2-------Office2Network. >> >>Office1Network has HTTP as well as other services hosted. >>Office1 administartor wants to make sure that all HTTP traffic has to go with >>3DES and SHA1 >> >>And all other traffic can go with AH MD5 and no encyrption is required for >>performance reasons. >> >>In this case, if office2Network SG is mis-configured or they did not even >>configure HTTP policy. >> office2Network administrator is configured only one policy for all >> traffic with AH MD5 >>Then SG1 accepts the HTTP traffic and process it. >>After IPSEC processing, SHOULD WE ACCEPT THOSE PACKETS OR DROP THOSE >>PACKETS, because higher priority SPD policy is created for the HTTP traffic. >> >>Any advice on this would be greatly appreciated >> >> >>Thanks in advance, >>Jyothi > >Yes, the exit check at SG1 should reject traffic that has either source >or dest port = 80, consistent with the policy you articulated above. From owner-ipsec@lists.tislabs.com Mon Apr 28 07:22:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3SEMgt2004495; Mon, 28 Apr 2003 07:22:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00335 Mon, 28 Apr 2003 09:36:17 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> References: <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> Date: Mon, 28 Apr 2003 09:36:11 -0400 To: Jyothi From: Stephen Kent Subject: Re: Question on inbound IPSEC policy check Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:22 AM +0530 4/28/03, Jyothi wrote: >Hi, > >If we reject the traffic, how do we inform the peer??? >I think there might be some inter-operability issues. > >Thanks >Jyothi > If the SAs are established using IKE, then the payloads passed during the IKE negotiations will inform the peer of the range of allowable traffic, so it will not be a surprise. Steve From owner-ipsec@lists.tislabs.com Mon Apr 28 13:47:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3SKlwi2026126; Mon, 28 Apr 2003 13:47:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01606 Mon, 28 Apr 2003 16:08:08 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 28 Apr 2003 13:13:00 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: IPsec WG cc: John Shriver , Barbara Fraser , "Theodore Ts'o" , Steven Bellovin , Russ Housley , Bert Wijnen Subject: MIB doctor review of draft-ietf-ipsec-doi-tc-mib-07.txt In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550137C1F4@nl0006exch001u.nl.lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IPsec folks, This e-mail message contains the results of the MIB doctor review for that Bert Wijnen asked me to do. The review comments take into account the discussions that have taken place on this list over the past three weeks. The authors of are urged to pay attention to these review comments, as many of them apply to that draft too. The main recommendations that I wish to make are (1) that the enumerated INTEGER TCs in this draft have their SYNTAX values changed to be a subrange of Unsigned32, and (2) that a pointer to the IANA registry where the assigned values can be found be added to the DESCRIPTION clause of applicable TCs, in lieu of having the IANA maintain the content of the TCs themselves. The reasons for these recommendations (as discussed at length on the IPsec mailing list over the last three weeks) are: (1) the semantics of enumerated INTEGER, as specified in RFC 2578 Section 7.1.1, do not allow for objects of such a type to assume values other than those explicitly enumerated, but objects defined using the TCs in this draft are supposed to be able to assume private use values that don't appear in the enumeration list; and (2) the TCs in this draft cover parameters that reside in existing registries, so if maintenance of the MIB module in the draft is turned over to the IANA then it will be necessary either to perform updates in multiple places or else to restructure the IPsec registries. Detailed recommendations follow below. Note that if these recommendations (or equivalent changes) are implemented, then the MIB module in this draft will be insulated from having to track changes in the IPsec registries, and the document can be progressed along the standards track like any other WG document. The comments below follow the MIB review checklist from Appendix A of . 1.) I-D Boilerplate -- OK 2.) Title, Abstract, and Discussion sections -- several changes are suggested for these parts of the document. Title: RFC Editor policy (see Section 2.6 of ) states that acronyms in a title should generally be expanded except when they are so well-known that every member of the IETF should be expected to recognize them immediately. While IPsec probably qualifies, I don't think that's true of DOI (at least, that one was not obvious to me). So I suggest a revision along the following lines: IPsec Domain of Interpretation (DOI) Textual Conventions MIB Abstract: if the MIB module is restructured per the recommendations then the abstract needs to be rewritten. Something along the following lines is suggested: This document defines textual conventions that represent parameters that appear in IPsec protocol messages. In particular, it defines textual conventions for parameters that have value assignments in "magic number" spaces. Discussion (Section 3): in the fourth and following paragraphs s/MIB/MIB module/, s/seperate/separate/, s/numberous/numerous/, and wordsmith to reflect the changes recommended at the outset of the review comments. Here is the suggested text: This MIB module defines textual conventions for certain parameters in ISAKMP, the IPsec DOI, and IKE. These are defined in a separate MIB module for two reasons. o There will be variables with a syntax corresponding to these textual conventions in numerous MIB modules that will be defined for the IPsec architecture. o All of the parameters modelled by these textual conventions have value assignments in "magic number" spaces, and it is useful to have a single pointer to the registry entries or documents where the value assignments are recorded instead of having that information repeated in each object definition. One of the objectives for these textual conventions is to have the data representation for MIB objects defined with them be as close as possible to the on-the-wire representation of the ISAKMP/IKE protocol parameters that they represent. Hence the SYNTAX value is a subrange of Unsigned32, rather than enumerated INTEGER or BITS. Note: here and elsewhere where words like "along the lines of" or "along the following lines" appear it is intended that the document editor shall wordsmith the suggested text as he or she sees fit. 3.) MIB Boilerplate -- the title of Section 2 needs to be changed to "The Internet-Standard Management Framework" (as documented in http://www.ops.ietf.org/mib-boilerplate.html) and the second paragraph (i.e., the sentence at the end of page 2) needs to be removed (it is a duplicate of the first sentence on page 3). 4.) IPR Notices -- OK, subject to one condition. Section 5 contains the required verbatim copies of the IPR notices specified in bullets (A) and (B) of Section 10.4 of RFC 2026; however, the WG must affirm that bullet (D) is not needed because there are no IPR claims known to the WG that are relevant to this document. 5.) References -- if the DESCRIPTION clause change recommendations suggested in (11) below are accepted as is, then a normative reference to RFC 2119 will need to be added. Content is otherwise OK, but the style differs from that used in recent RFCs. Although the RFC Editor can fix this, it might save some time if the document author would do so instead. 6.) Security Considerations Section -- s/MIB/MIB module/, otherwise it is OK. 7.) IANA Considerations Section -- should not be required if the recommended changes are implemented, since the WG (and not the IANA) will be maintaining the MIB module. 8.) Copyright notices -- OK 9.) MIB compilation -- OK. No diagnostics were reported by the smilint e-mail robot with default switches other than the expected warnings for unreferenced TCs. With the additional switch "-i type-unref" to suppress these warnings no diagnostics were reported at all: This is an automatically generated mail message in response to a mail message you (or someone else who used your address) sent to . If you want to learn more about this mail service, send a mail message with the "Subject: help" to . This command (smilint 0.4.2-pre1, as of Sat Mar 08 10:42:09 2003) has been processed to get the following results: smilint -m -s -l 6 -i namelength-32 -i type-unref IPSEC-ISAKMP-IKE-DOI-TC no errors found. NOTE: this will have to be re-checked after the recommended changes to the SYNTAX clauses and DESCRIPTION clauses are incorporated. 10.) Other issues -- if the DESCRIPTION clause change recommendations suggested in (11) below are accepted as is, then a section defining the use of the MUST, MAY, etc. keywords will need to be added (this is in addition to adding a normative reference to RFC 2119, per (5) above). See section 2 of http://www.ietf.org/ID-nits.html 11.) Technical content -- here are the comments on the MIB module itself. (a) I suggest changing the following IMPORTS -- delete next line before release experimental, MODULE-IDENTITY, Unsigned32 FROM SNMPv2-SMI -- uncomment next line before release -- mib-2 FROM RFC1213-MIB TEXTUAL-CONVENTION FROM SNMPv2-TC; to IMPORTS -- RFC Ed.: delete next line & remove this note before publication experimental, -- RFC Ed.: uncomment next line & remove this note before publication -- mib-2, MODULE-IDENTITY, Unsigned32 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; The purpose of this change is to import mib-2 from SNMPv2-SMI rather than the by now out-of-date RFC1213-MIB and to make it clear to the RFC editor which comment line are editor's instructions that need to be removed when carried out. Making similar changes to all other ASN.1 comments that are editor's instructions is likewise recommended. (b) Please change the MODULE-IDENTITY descriptor from ianaIPsecIsakmpIkeDoiTcMib to iPsecIsakmpIkeDoiTcMib (or perhaps even better, to iPsecIsakmpIkeDoiTc -- that would be in line with the naming conventions recommendeded by Appendix E of ). (c) Please change the ORGANIZATION clause of the MODULE-IDENTITY invocation to contain the official IPsec working group name and please add the working group web page and mailing list info to the CONTACT-INFO clause. See section 4.5 of for details. (d) Please delete the second paragraph of the DESCRIPTION clause of the MODULE-IDENTITY invocation, since it will no longer apply. (e) The DESCRIPTION clause for IpsecDoiSituation should state that the object is a 32-bit (not a four (4) octet) bit mask, since the data type is Unsigned32 and not OCTET STRING (SIZE(4)), and it should point to the appropriate IANA registry entry for the assigned values instead of listing them. Also, the REFERENCE clause should point to RFC 2407 Section 6.1 (not 6.2). Finally, the ASN.1 comment at the end explaining why the data type is Unsigned32 rather than BITS is no longer needed if the change to the last paragraph of Section 3 recommended in (2) above is accepted. A revised definition along the following lines is suggested: IpsecDoiSituation ::= TEXTUAL-CONVENTION DISPLAY-HINT "x" STATUS current DESCRIPTION "The IPsec DOI Situation is a 32-bit bitmask that provides information which can be used by a responder to make a policy determination about how to process an incoming Security Association request. Situation assignments for the low-order 30 bits are managed by the Internet Assigned Numbers Authority (IANA). Assigned values are recorded in the IPSEC Situation Definition section of the IANA Internet Security Association and Key Management Protocol (ISAKMP) Identifiers registry (a URL for which is http://www.iana.org/assignments/isakmp-registry). The upper two bits (0x80000000 and 0x40000000) are reserved for private use amongst cooperating systems. It is RECOMMENDED that implementations document the usage of such values in an AGENT-CAPABILITIES statement." REFERENCE "RFC 2407 sections 4.2 and 6.1" SYNTAX Unsigned32 (0..4294967295) NOTE: the IpsecDoiSituation TC is not used in any of the four MIB modules (IPSEC-SA-MON-MIB, ISAKMP-DOI-IND-MON-MIB, IKE-MON-MIB, and IPSEC-POLICY-MIB) that currently import TCs from IPSEC-ISAKMP-IKE-DOI-TC. Be aware that TCs which are not used to define MIB objects that are included in two independent implementations must be deprecated or obsoleted before the spec containing them can advance beyond Proposed Standard. (f) Per the general recommendations above, the SYNTAX value for IpsecDoiSecProtocolId should be changed to Unsigned32 (0..255), and the DESCRIPTION clause should point to the appropriate IANA registry entry for the assigned values and should recommend that an agent-caps statement document use of "private use" values. Also, the REFERENCE clause should point to RFC 2407 section 6.2 (in addition to section 4.4.1). A revised definition along the following lines is suggested: IpsecDoiSecProtocolId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Managed objects of this type represent IPsec DOI values for the IP Security Protocol Identifier (Protocol ID) field in an ISAKMP Proposal Payload. They may also represent values of the Protocol ID field in the Notification Payload and the Delete Payload. The value zero does not identify any particular security protocol. It MAY be used in MIB objects to indicate that the security protocol is unknown or that none applies. Any such usage MUST be documented in the MIB object's DESCRIPTION clause. Values between 1 and 248, inclusive, are managed by the Internet Assigned Numbers Authority (IANA). Assignments are recorded in the IPSEC Security Protocol Identifiers section of the IANA Internet Security Association and Key Management Protocol (ISAKMP) Identifiers registry (a URL for which is http://www.iana.org/assignments/isakmp-registry). The values 249-255 are reserved for private use amongst cooperating systems. It is RECOMMENDED that implementations document the usage of such values in an AGENT-CAPABILITIES statement." REFERENCE "RFC 2407 sections 4.4.1 and 6.2" SYNTAX Unsigned32 (0..255) (g) The SYNTAX value for IpsecDoiTransformIdent should be changed to Unsigned32 (0..255), and its DESCRIPTION clause should point to the appropriate IANA registry entry for the assigned values and should recommend that an agent-caps statement document use of the "private use" values. A revised definition along the lines of the one shown in 11(f) is suggested. (h) The SYNTAX value for IpsecDoiAhTransform should be changed to Unsigned32 (0..255), and its DESCRIPTION clause should point to the appropriate IANA registry entry for the assigned values and should recommend that an agent-caps statement document use of the "private use" values. Also, the REFERENCE clause should point only to RFC 2407 sections 4.4.3 and 6.4, which define the parameter and its value assignment rules. A revised definition along the lines of the one shown in 11(f) is suggested. (i) The SYNTAX value for IpsecDoiEspTransform should be changed to Unsigned32 (0..255), and its DESCRIPTION clause should point to the appropriate IANA registry entry for the assigned values and should recommend that an agent-caps statement document use of the "private use" values. Also, the REFERENCE clause should point only to RFC 2407 sections 4.4.4 and 6.5, which define the parameter and its value assignment rules. A revised definition along the lines of the one shown in 11(f) is suggested. (j) It is suggested that the order of appearance of the definitions of IpsecDoiAuthAlgorithm, IpsecDoiIpcompTransform, and IpsecDoiEncapsulationMode be changed to IpsecDoiIpcompTransform, IpsecDoiEncapsulationMode, and IpsecDoiAuthAlgorithm so that all of the IpsecDoi-related stuff appears in the same order as its counterparts in http://www.iana.org/assignments/isakmp-registry and RFC 2407 (this will make it easier to audit the registries and the specifications for mutual consistency). (k) The SYNTAX value for IpsecDoiAuthAlgorithm should be changed to Unsigned32 (0..65535), and its DESCRIPTION clause should point to the appropriate IANA registry entry for the assigned values and should recommend that an agent-caps statement document use of the "private use" values. Also, the introductory text in the DESCRIPTION clause should probably say just "Authentication Algorithm" and not "ESP Authentication Algorithm", and the REFERENCE clause should point only to RFC 2407 section 4.5 (which defines the parameter). A revised definition along the lines of the one shown in 11(f) is suggested. (l) The SYNTAX value for IpsecDoiIpcompTransform should be changed to Unsigned32 (0..255), and its DESCRIPTION clause should point to the appropriate IANA registry entry for the assigned values and should recommend that an agent-caps statement document use of the "private use" values. Also, the REFERENCE clause should point only to RFC 2407 sections 4.4.5 and 6.6, which define the parameter and its value assignment rules. A revised definition along the lines of the one shown in 11(f) is suggested (see also 11(z) below). (m) The SYNTAX value for IpsecDoiEncapsulationMode should be changed to Unsigned32 (0..65535), and its DESCRIPTION clause should point to the appropriate IANA registry entry for the assigned values and should recommend that an agent-caps statement document use of the "private use" values. Also, a REFERENCE clause which points to RFC 2407 section 4.5 should be added. A revised definition along the lines of the one shown in 11(f) is suggested. (n) The SYNTAX value for IpsecDoiIdentType should be changed to Unsigned32 (0..255), and its DESCRIPTION clause should point to the appropriate IANA registry entry for the assigned values and should recommend that an agent-caps statement document use of the "private use" values. Also, the REFERENCE clause should point only to RFC 2407 sections 4.6.2.1 and 6.9, which define the parameter and its value assignment rules. A revised definition along the lines of the one shown in 11(f) is suggested. (o) Although there are no private used values for IsakmpDOI, it is still inappropriate to use an enumerated INTEGER type if values in the range 2147483648..4294967295 need to be represented, as stated in the DESCRIPTION clause and by RFC 2408 section 3.4. One must instead use a SYNTAX value of Unsigned32 (0..4294967295) and either point to a registry entry where assigned values can be found or list them in the DESCRIPTION clause. Since this assigned values for this parameter are not listed in any IANA registry the second option is suggested. Also, the REFERENCE clause should to RFC 2408 (not RFC 2048) and should probably mention sections 3.14 and 3.15 (in addition to section 3.4) since the payloads documented in those sections also contain a DOI value. A revised definition along the following lines is suggested: IsakmpDOI ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Managed objects of this type represent Domain of Interpretation (DOI) values for the ISAKMP Protocol. They are 32-bit unsigned values used in the Domain of Interpretation field of the Security Association Payload, the Notification Payload, and the Delete Payload. Currently assigned values are: isakmp(0) generic ISAKMP SA in used for any protocol in Phase 2 ipsecDOI(1) the IPsec DOI as specified in RFC 2407 At the present time there is no assigned number registry for ISAKMP DOI values. A registry may be established and additional values may be assigned by the IANA at some future date." REFERENCE "RFC 2408 sections 3.4, 3.14, and 3.15" SYNTAX Unsigned32 (0..4294967295) (p) Unlike all the other enumerated INTEGER TCs in this MIB module, there are no private use values for IsakmpCertificateEncoding and its value range is easily accomodated by the INTEGER data type, so the only technical objection to the existing definition is that it does not have an enumeration of corresponding to the value NONE = 0 that is listed in Section 3.9 of RFC 2408. While this could be easily remedied by adding none(0) to the enumeration list, there would still remain the issue of how to keep the enumeration list properly maintained. It turns out, however, that this TC is not used in any of the four MIB modules IPSEC-SA-MON-MIB, ISAKMP-DOI-IND-MON-MIB, IKE-MON-MIB, and IPSEC-POLICY-MIB that import TCs from IPSEC-ISAKMP-IKE-DOI-TC. So the recommended course of action is to remove it from this MIB module and worry about the issue when there is an actual need to do so. An alternative course of action would be to change the SYNTAX value to Unsigned32 (0..255) and re-write the DESCRIPTION clause along the lines of 11(o) above. (q) The SYNTAX value for IsakmpExchangeType should be changed to Unsigned32 (0..31 | 240..255), and its DESCRIPTION clause should be revised to specify that it represents only the values in the DOI-independent or private-use ranges defined in RFC 2408 and to recommend documenting use of the latter in an agent-caps statement. A revised definition along the following lines is suggested: IsakmpExchangeType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Managed objects of this type represent DOI-independent values of the Exchange Type field in the ISAKMP header. The value zero signifies an exchange type of NONE. It MAY be used in MIB objects to indicate that the exchange type is unknown or that none applies. Any such usage MUST be documented in the MIB object's DESCRIPTION clause. Values between 1 and 31, inclusive, represent DOI-independent exchange types specified in RFC 2408 Section 3.1. At the present time there is no assigned number registry for DOI-independent ISAKMP exchange type values. A registry may be established and additional DOI-independent values may be assigned by the IANA at some future date. The values 240-255 are reserved for private use amongst cooperating systems. It is RECOMMENDED that implementations document the usage of such values in an AGENT-CAPABILITIES statement." REFERENCE "RFC 2408 section 3.1" SYNTAX Unsigned32 (0..31 | 240..255) NOTE: the IsakmpExchangeType TC is not used in any of the four MIB modules (IPSEC-SA-MON-MIB, ISAKMP-DOI-IND-MON-MIB, IKE-MON-MIB, and IPSEC-POLICY-MIB) that currently import TCs from IPSEC-ISAKMP-IKE-DOI-TC. Be aware that TCs which are not used to define MIB objects that are included in two independent implementations must be deprecated or obsoleted before the spec containing them can advance beyond Proposed Standard. (r) The SYNTAX value for IsakmpNotifyMessageType should be changed to Unsigned32 (0..8191 | 16384..24575 | 32768..65535), and its DESCRIPTION clause should be revised to specify that it represents only the values in the DOI-independent or private-use ranges defined in RFC 2408 and to recommend documenting use of the latter in an agent-caps statement. A revised definition along the following lines is suggested: IsakmpNotifyMessageType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Managed objects of this type represent DOI-independent values of the Notify Message Type field in the ISAKMP Notification Payload. This textual convention merges the types for error types (in the range 1-16383) and for status types (in the range 16384-65535). The value zero does not not identify any particular notify message type. It MAY be used in MIB objects to indicate that the notify message type is unknown or that none applies. Any such usage MUST be documented in the MIB object's DESCRIPTION clause. Values between 1 and 8191, inclusive, represent DOI-independent error message types specified in RFC 2408 Section 3.14.1. At the present time there is no assigned number registry for DOI-independent ISAKMP error message type values. A registry may be established and additional DOI-independent values may be assigned by the IANA at some future date. Values between 16384 and 24575, inclusive, represent DOI-independent status message types specified in RFC 2408 Section 3.14.1. At the present time there is no assigned number registry for DOI-independent ISAKMP status message type values. A registry may be established and additional DOI-independent values may be assigned by the IANA at some future date. Values in the range 32768-40959 are reserved for private use as status message types amongst cooperating systems. It is RECOMMENDED that implementations document the usage of such values in an AGENT-CAPABILITIES statement. Values in the range 40960-65535 are reserved for future use." REFERENCE "RFC 2408 section 3.14.1" SYNTAX Unsigned32 (0..8191 | 16384..24575 | 32768..65535) NOTE: RFC 2408 Section 3.14.1 states that values in the range 8192..16383 are for private use, but also states that codes in this range are expected to be DOI-specific. Since RFC 2407 allocated DOI-specific error message codes from this range, the DESCRIPTION clause above assumes that the range 8192..16383 is DOI-specific and excludes that range from the allowed values. (s) The SYNTAX value for IkeExchangeType should be changed to Unsigned32 (0..255), and its DESCRIPTION clause should point to the appropriate IANA registry entries for the assigned values and should recommend that an agent-caps statement document use of the "private use" values. Also, the REFERENCE clause should point to RFC 2408 sections 3.1 as well as RFC 2409 Appendix A. A revised definition along the following lines is suggested: IkeExchangeType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Managed objects of this type represent values of the Exchange Type field in the ISAKMP header that pertain to IKE. The value zero signifies an exchange type of NONE. It MAY be used in MIB objects to indicate that the exchange type is unknown or that none applies. Any such usage MUST be documented in the MIB object's DESCRIPTION clause. Values between 1 and 31, inclusive, represent DOI-independent exchange types specified in RFC 2408 Section 3.1. At the present time there is no assigned number registry for DOI-independent ISAKMP exchange type values. A registry may be established and additional DOI-independent values may be assigned by the IANA at some future date. Values between 32 and 239, inclusive, represent exchange types that pertain specifically to IKE. Assignments are recorded in the Additional Exchanges section of the IANA Internet Key Exchange (IKE) Attributes registry (a URL for which is http://www.iana.org/assignments/ipsec-registry). The values 240-255 are reserved for private use amongst cooperating systems. It is RECOMMENDED that implementations document the usage of such values in an AGENT-CAPABILITIES statement." REFERENCE "RFC 2408 section 3.1 and RFC 2409 Appendix A" SYNTAX Unsigned32 (0..255) NOTE: since the additional XCHG values for IKE are listed last both in RFC 2409 Appendix A and in the IKE Attributes registry http://www.iana.org/assignments/ipsec-registry, it might be a good idea to relocate this TC just after IkePrf (this will make it easier to audit the registries and the MIB module for mutual consistency). (t) The SYNTAX value for IkeEncryptionAlgorithm should be changed to Unsigned32 (0..65535), and its DESCRIPTION clause should point to the appropriate IANA registry entry for the assigned values and should recommend that an agent-caps statement document use of the "private use" values. Also, the REFERENCE clause should point to RFC 2409 Appendix A only, as this is the reference that defines the parameter. A revised definition along the following lines is suggested: IkeEncryptionAlgorithm ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Managed objects of this type represent values for encryption algorithms negotiated for the ISAKMP SA by IKE in Phase I. These are values for SA Attribute type Encryption Algorithm (1). The value zero does not not identify any particular encryption algorithm. It MAY be used in MIB objects to indicate that the exchange type is unknown or that none applies. Any such usage MUST be documented in the MIB object's DESCRIPTION clause. Values between 1 and 65000, inclusive, are managed by the Internet Assigned Numbers Authority (IANA). Assignments are recorded in the Encryption Algorithm section of the IANA Internet Key Exchange (IKE) Attributes registry (a URL for which is http://www.iana.org/assignments/ipsec-registry). Values 65001-65535 are for private use among mutually consenting parties. It is RECOMMENDED that implementations document the usage of such values in an AGENT-CAPABILITIES statement." REFERENCE "RFC 2409 appendix A" SYNTAX Unsigned32 (0..65535) (u) The SYNTAX value for IkeHashAlgorithm should be changed to Unsigned32 (0..65535), and its DESCRIPTION clause should point to the appropriate IANA registry entry for the assigned values and should recommend that an agent-caps statement document use of the "private use" values. Also, the REFERENCE clause should point to RFC 2409 Appendix A only, as this is the reference that defines the parameter. A revised definition along the lines of the one shown in 11(t) is suggested. (v) The SYNTAX value for IkeAuthMethod should be changed to Unsigned32 (0..65535), and its DESCRIPTION clause should point to the appropriate IANA registry entry for the assigned values and should recommend that an agent-caps statement document use of the "private use" values. Also, the REFERENCE clause should point to RFC 2409 Appendix A only, as this is the reference that defines the parameter. A revised definition along the lines of the one shown in 11(t) is suggested. (w) The SYNTAX value for IkeGroupDescription should be changed to Unsigned32 (0..65535), and its DESCRIPTION clause should point to the appropriate IANA registry entry for the assigned values and should recommend that an agent-caps statement document use of the "private use" values. Also, the REFERENCE clause should point to RFC 2409 Appendix A only, as this is the reference that defines the parameter. A revised definition along the lines of the one shown in 11(t) is suggested. (x) The SYNTAX value for IkeGroupType should be changed to Unsigned32 (0..65535), and its DESCRIPTION clause should point to the appropriate IANA registry entry for the assigned values and should recommend that an agent-caps statement document use of the "private use" values. A revised definition along the lines of the one shown in 11(t) is suggested. NOTE: the IkeGroupType TC is not used in any of the four MIB modules (IPSEC-SA-MON-MIB, ISAKMP-DOI-IND-MON-MIB, IKE-MON-MIB, and IPSEC-POLICY-MIB) that currently import TCs from IPSEC-ISAKMP-IKE-DOI-TC. Be aware that TCs which are not used to define MIB objects that are included in two independent implementations must be deprecated or obsoleted before the spec containing them can advance beyond Proposed Standard. (y) The DESCRIPTION clause for IkePrf should point to the appropriate IANA registry entry for the assigned values and should recommend that an agent-caps statement document use of the "private use" values. A revised definition along the lines of the one shown in 11(t) is suggested. (z) The SYNTAX value for IkeNotifyMessageType should be changed to Unsigned32 (0..65535), and its DESCRIPTION clause should point to the appropriate IANA registry entries for the assigned values and should recommend that an agent-caps statement document use of the "private use" values. A revised definition along the following lines is suggested: IsakmpNotifyMessageType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Managed objects of this type represent values of the Notify Message Type field in the ISAKMP Notification Payload. This textual convention merges the types for error types (in the range 1-16383) and for status types (in the range 16384-65535). The value zero does not not identify any particular notify message type. It MAY be used in MIB objects to indicate that the notify message type is unknown or that none applies. Any such usage MUST be documented in the MIB object's DESCRIPTION clause. Values between 1 and 8191, inclusive, represent DOI-independent error message types specified in RFC 2408 Section 3.14.1. At the present time there is no assigned number registry for DOI-independent ISAKMP error message type values. A registry may be established and additional DOI-independent values may be assigned by the IANA at some future date. Values between 8192 and 16383, inclusive, represent DOI-specific error message types. Assignments are recorded in the Notify Messages - Error Types subsection of the IPSEC Notify Message Types section of the IANA Internet Security Association and Key Management Protocol (ISAKMP) Identifiers registry (http://www.iana.org/assignments/isakmp-registry). Values between 16384 and 24575, inclusive, represent DOI-independent status message types specified in RFC 2408 Section 3.14.1. At the present time there is no assigned number registry for DOI-independent ISAKMP status message type values. A registry may be established and additional DOI-independent values may be assigned by the IANA at some future date. Values between 24576 and 32767, inclusive, represent DOI-specific status message types. Assignments are recorded in the Notify Messages - Status Types subsection of the IPSEC Notify Message Types section of the IANA Internet Security Association and Key Management Protocol (ISAKMP) Identifiers registry (http://www.iana.org/assignments/isakmp-registry). Values in the range 32768-40959 are reserved for private use as status message types amongst cooperating systems. It is RECOMMENDED that implementations document the usage of such values in an AGENT-CAPABILITIES statement. Values in the range 40960-65535 are reserved for future use." REFERENCE "RFC 2408 section 3.14.1 and RFC 2407 sections 4.6.3 and 6.10" SYNTAX Unsigned32 (0..65535) 12.) The following minor editorial changes are requested: (a) s/Attrbute/Attribute/ in all the IkeXyz TC DESCRIPTION clauses where it appears. (b) Please change phrases such as "when used in a MIB" to "when used in a MIB module" throughout the document. Note that if the change recommendations above are accepted, then some minor changes will also have to be made to some of the modules that import TCs from IPSEC-ISAKMP-IKE-DOI-TC. Here are the modules that are known to import from IPSEC-ISAKMP-IKE-DOI-TC: Client Module Internet Draft IPSEC-SA-MON-MIB ISAKMP-DOI-IND-MON-MIB IKE-MON-MIB IPSEC-POLICY-MIB The (minimum) required changes would be as follows: IPSEC-SA-MON-MIB none known ISAKMP-DOI-IND-MON-MIB none known IKE-MON-MIB The DESCRIPTION clauses of ikeSaTable and ikeSaEntry refer to 'ipsecDOI(1)'. The DESCRIPTION clause of ipsecSaInSuiteSpi refers to 'protoIpcomp(4)'. These clauses should be edited to reflect the fact that these enums will no longer exist. IPSEC-POLICY-MIB The DEFVAL clause of ipspSaPreActActionType will need to be changed from '{ tunnel }' to '{ 1 } -- tunnel', or else the object needs to get a stand-alone definition independent of a TC, as was done for ipspIpsecActMode. Also, the DESCRIPTION clauses for ipspIpsecPropProtocolId and ipspIpsecTranType refer to protoIsakmp(1). These clauses should be edited to reflect the fact that this enum will not exist. Other changes might also be required (e.g., to comply with the proposed requirement to document how the special value 0 is used). The authors/editors of these MIB modules have been bcc:'d. One last point: it is acknowledged that the main recommendations in this review are controversial. Understand that all recommendations are presented as advice to the OPS AD responsible for Network Management (see http://www.ops.ietf.org/mib-doctors.html), and any recommendation with which folks do not agree may be challenged. Regards, Mike Heard From owner-ipsec@lists.tislabs.com Mon Apr 28 14:31:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3SLV7i2027992; Mon, 28 Apr 2003 14:31:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01735 Mon, 28 Apr 2003 16:55:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 28 Apr 2003 11:11:58 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Crypto algorithms for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. At the WG meeting in San Francisco over a month ago, the WG agreed that the IKEv2 document should split out the cryptographic algorithms into a RFC that can be updated separately from the main IKEv2 protocol RFC with which we are almost finished. I have turned in an Internet Draft on this topic that matches what I believe matches the general feeling from the WG based on earlier discussion on this mailing list and the lively face-to-face discussions in San Francisco. A temporary version of the draft is at ; as usual, that link will disappear when the draft is officially in the Internet Drafts directory. This document is meant to be a companion to the *next* draft of IKEv2. In that draft, Charlie can cleanly excise from his section 3.3.2 the cryptographic tables labeled "For Transform Type 1", "For Transform Type 2", "For Transform Type 3", and "For Transform Type 4", leaving Transform Type 5, which is not cryptographic. He can also remove the MUST, SHOULD, and MAY statements in Appendix B. The result will be a free-standing document that the IETF can update when we want to change the cryptographic requirements for IKEv2. For example, there was general agreement in San Francisco that we will probably be requiring AES and longer Diffie-Hellman primes in the not-distant future, and that fact is reflected in the Internet Draft. Given that we are trying to finish up IKEv2 in the near future and not reopening agreed-to issues, I'm definitely interested to hear if anyone thinks that the document has things that the WG didn't agree to. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Apr 28 17:37:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T0b2i2035365; Mon, 28 Apr 2003 17:37:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02349 Mon, 28 Apr 2003 20:05:07 -0400 (EDT) Reply-To: From: "Jimmy Zhang" To: "'Paul Hoffman / VPNC'" , Subject: RE: Crypto algorithms for IKEv2 Date: Mon, 28 Apr 2003 17:09:03 -0700 Message-ID: <000001c30de3$902b4d00$0300a8c0@riverside> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How about TWOFISH ? Thanks, Jimmy > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Paul > Hoffman / VPNC > Sent: Monday, April 28, 2003 11:12 AM > To: ipsec@lists.tislabs.com > Subject: Crypto algorithms for IKEv2 > > > Greetings again. At the WG meeting in San Francisco over a month ago, > the WG agreed that the IKEv2 document should split out the > cryptographic algorithms into a RFC that can be updated separately > from the main IKEv2 protocol RFC with which we are almost finished. > > I have turned in an Internet Draft on this topic that matches what I > believe matches the general feeling from the WG based on earlier > discussion on this mailing list and the lively face-to-face > discussions in San Francisco. A temporary version of the draft is at > ; as usual, that link will disappear when the draft is officially in the Internet Drafts directory. This document is meant to be a companion to the *next* draft of IKEv2. In that draft, Charlie can cleanly excise from his section 3.3.2 the cryptographic tables labeled "For Transform Type 1", "For Transform Type 2", "For Transform Type 3", and "For Transform Type 4", leaving Transform Type 5, which is not cryptographic. He can also remove the MUST, SHOULD, and MAY statements in Appendix B. The result will be a free-standing document that the IETF can update when we want to change the cryptographic requirements for IKEv2. For example, there was general agreement in San Francisco that we will probably be requiring AES and longer Diffie-Hellman primes in the not-distant future, and that fact is reflected in the Internet Draft. Given that we are trying to finish up IKEv2 in the near future and not reopening agreed-to issues, I'm definitely interested to hear if anyone thinks that the document has things that the WG didn't agree to. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Apr 28 18:03:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T13ci2035893; Mon, 28 Apr 2003 18:03:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02567 Mon, 28 Apr 2003 20:33:45 -0400 (EDT) Message-ID: From: "Hallam-Baker, Phillip" To: "'jzhang@elmic.com'" , "'Paul Hoffman / VPNC'" , ipsec@lists.tislabs.com Subject: RE: Crypto algorithms for IKEv2 Date: Mon, 28 Apr 2003 17:38:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At the RSA crypto panel Bruce told folk to use AES. better we all use the same thing. At this point I would rather we start deprecating algorithms rather than add more. I would especially like to get rid of RC4, including a stream cipher in a list of block ciphers is real bad news, especially when the traditional default has been a block cipher. There are lots of unexpected problems that occur with stream ciphers which is why lots of folk avoid them in designs. Phill From owner-ipsec@lists.tislabs.com Mon Apr 28 21:14:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T4EMi2040055; Mon, 28 Apr 2003 21:14:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA03084 Mon, 28 Apr 2003 23:43:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 28 Apr 2003 20:48:04 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Crypto algorithms for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Offl-list, two people pointed out a serious typo. The document says: > For IKEv2, ENCR_3DES (3) MUST be implemented and ENCR_AES_128_CBC (12) > SHOULD be implemented. It is expected that in the not-distant future, > ENCR_AES_128_CBC (12) will become a MUST-level requirement and that > ENCR_AES_128_CBC (12) will become a SHOULD-level requirement. The paragraph should read: For IKEv2, ENCR_3DES (3) MUST be implemented and ENCR_AES_128_CBC (12) SHOULD be implemented. It is expected that in the not-distant future, ENCR_AES_128_CBC (12) will become a MUST-level requirement and that ENCR_3DES (3) will become a SHOULD-level requirement. That is, when we make AES a MUST, we will most likely demote TripleDES to a SHOULD. This is what we discussed on the mailing list and in San Francisco. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Apr 28 21:42:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T4fxi2040641; Mon, 28 Apr 2003 21:41:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA03183 Tue, 29 Apr 2003 00:16:17 -0400 (EDT) Message-Id: <5.1.0.14.0.20030429090406.00a2fec0@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Apr 2003 09:58:24 +0530 To: Stephen Kent , Jyothi From: Jyothi Subject: Re: Question on inbound IPSEC policy check Cc: ipsec@lists.tislabs.com In-Reply-To: References: <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Office1Network-----SG1---------Internet------------SG2-------Office2Network. SG1 contains the 2 IPSEC policies: 1. protocol TCP and port 80 2. protocol ANY SG2 contains the one IPSEC policy of protocol ANY. Office2Network starts the IKE negotiation for protocol ANY, after the negotiation SG2 will send the HTTP traffic with SAs created. In IKE negotiation, we are informing the allowable traffic as protocol ANY. In this case, HTTP is part of protocol ANY. So, if SG1 rejects inbound traffic coming from SG2, then how SG2 knows?? Thanks Jyothi At 09:36 AM 4/28/03 -0400, Stephen Kent wrote: >At 11:22 AM +0530 4/28/03, Jyothi wrote: >>Hi, >> >>If we reject the traffic, how do we inform the peer??? >>I think there might be some inter-operability issues. >> >>Thanks >>Jyothi > >If the SAs are established using IKE, then the payloads passed during the >IKE negotiations will inform the peer of the range of allowable traffic, >so it will not be a surprise. > >Steve From owner-ipsec@lists.tislabs.com Tue Apr 29 06:02:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TD2ci2089810; Tue, 29 Apr 2003 06:02:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04371 Tue, 29 Apr 2003 08:21:20 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155017C0D20@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "C. M. Heard" , IPsec WG Cc: John Shriver , Barbara Fraser , "Theodore Ts'o" , Steven Bellovin , Russ Housley , Bert Wijnen Subject: RE: MIB doctor review of draft-ietf-ipsec-doi-tc-mib-07.txt Date: Tue, 29 Apr 2003 05:54:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks Mike for your review. People who answer and want me to see the response, pls copy me personally, cause I am not on your IPsec mailing list. Thanks, Bert > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: maandag 28 april 2003 22:13 > To: IPsec WG > Cc: John Shriver; Barbara Fraser; Theodore Ts'o; Steven Bellovin; Russ > Housley; Bert Wijnen > Subject: MIB doctor review of draft-ietf-ipsec-doi-tc-mib-07.txt > > > IPsec folks, > > This e-mail message contains the results of the MIB doctor review > for that Bert Wijnen asked me > to do. The review comments take into account the discussions that > have taken place on this list over the past three weeks. The > authors of are urged to > pay attention to these review comments, as many of them apply to > that draft too. > > The main recommendations that I wish to make are (1) that the > enumerated INTEGER TCs in this draft have their SYNTAX values > changed to be a subrange of Unsigned32, and (2) that a pointer to > the IANA registry where the assigned values can be found be added > to the DESCRIPTION clause of applicable TCs, in lieu of having the > IANA maintain the content of the TCs themselves. The reasons for > these recommendations (as discussed at length on the IPsec mailing > list over the last three weeks) are: (1) the semantics of > enumerated INTEGER, as specified in RFC 2578 Section 7.1.1, do not > allow for objects of such a type to assume values other than those > explicitly enumerated, but objects defined using the TCs in this > draft are supposed to be able to assume private use values that > don't appear in the enumeration list; and (2) the TCs in this draft > cover parameters that reside in existing registries, so if > maintenance of the MIB module in the draft is turned over to the > IANA then it will be necessary either to perform updates in multiple > places or else to restructure the IPsec registries. Detailed > recommendations follow below. Note that if these recommendations > (or equivalent changes) are implemented, then the MIB module in this > draft will be insulated from having to track changes in the IPsec > registries, and the document can be progressed along the standards > track like any other WG document. > > The comments below follow the MIB review checklist from Appendix A > of . > > 1.) I-D Boilerplate -- OK > > 2.) Title, Abstract, and Discussion sections -- several changes > are suggested for these parts of the document. > > Title: RFC Editor policy (see Section 2.6 of > ) states that acronyms in a > title should generally be expanded except when they are so > well-known that every member of the IETF should be expected to > recognize them immediately. While IPsec probably qualifies, I don't > think that's true of DOI (at least, that one was not obvious to me). > So I suggest a revision along the following lines: > > IPsec Domain of Interpretation (DOI) Textual Conventions MIB > > Abstract: if the MIB module is restructured per the recommendations > then the abstract needs to be rewritten. Something along the > following lines is suggested: > > This document defines textual conventions that represent parameters > that appear in IPsec protocol messages. In particular, it defines > textual conventions for parameters that have value assignments in > "magic number" spaces. > > Discussion (Section 3): in the fourth and following paragraphs > s/MIB/MIB module/, s/seperate/separate/, s/numberous/numerous/, > and wordsmith to reflect the changes recommended at the outset > of the review comments. Here is the suggested text: > > This MIB module defines textual conventions for certain parameters > in ISAKMP, the IPsec DOI, and IKE. > > These are defined in a separate MIB module for two reasons. > > o There will be variables with a syntax corresponding to these > textual conventions in numerous MIB modules that will be > defined for the IPsec architecture. > > o All of the parameters modelled by these textual conventions > have value assignments in "magic number" spaces, and it is > useful to have a single pointer to the registry entries or > documents where the value assignments are recorded instead of > having that information repeated in each object definition. > > One of the objectives for these textual conventions is to have the > data representation for MIB objects defined with them be as close > as possible to the on-the-wire representation of the ISAKMP/IKE > protocol parameters that they represent. Hence the SYNTAX value is > a subrange of Unsigned32, rather than enumerated INTEGER or BITS. > > Note: here and elsewhere where words like "along the lines of" or > "along the following lines" appear it is intended that the document > editor shall wordsmith the suggested text as he or she sees fit. > > 3.) MIB Boilerplate -- the title of Section 2 needs to be changed to > "The Internet-Standard Management Framework" (as documented in > http://www.ops.ietf.org/mib-boilerplate.html) and the second > paragraph (i.e., the sentence at the end of page 2) needs to be > removed (it is a duplicate of the first sentence on page 3). > > 4.) IPR Notices -- OK, subject to one condition. Section 5 contains > the required verbatim copies of the IPR notices specified in bullets > (A) and (B) of Section 10.4 of RFC 2026; however, the WG must > affirm that bullet (D) is not needed because there are no IPR claims > known to the WG that are relevant to this document. > > 5.) References -- if the DESCRIPTION clause change recommendations > suggested in (11) below are accepted as is, then a normative > reference to RFC 2119 will need to be added. Content is otherwise > OK, but the style differs from that used in recent RFCs. Although > the RFC Editor can fix this, it might save some time if the document > author would do so instead. > > 6.) Security Considerations Section -- s/MIB/MIB module/, otherwise > it is OK. > > 7.) IANA Considerations Section -- should not be required if the > recommended changes are implemented, since the WG (and not the > IANA) will be maintaining the MIB module. > > 8.) Copyright notices -- OK > > 9.) MIB compilation -- OK. No diagnostics were reported by the > smilint e-mail robot with default switches other than the expected > warnings for unreferenced TCs. With the additional switch > "-i type-unref" to suppress these warnings no diagnostics were > reported at all: > > This is an automatically generated mail message in response to a > mail message you (or someone else who used your address) sent to > . If you want to learn more about this > mail service, send a mail message with the "Subject: help" to > . > > This command (smilint 0.4.2-pre1, as of Sat Mar 08 10:42:09 2003) > has been processed to get the following results: > smilint -m -s -l 6 -i namelength-32 -i type-unref > IPSEC-ISAKMP-IKE-DOI-TC > > no errors found. > > NOTE: this will have to be re-checked after the recommended changes > to the SYNTAX clauses and DESCRIPTION clauses are incorporated. > > 10.) Other issues -- if the DESCRIPTION clause change recommendations > suggested in (11) below are accepted as is, then a section defining > the use of the MUST, MAY, etc. keywords will need to be added (this > is in addition to adding a normative reference to RFC 2119, per (5) > above). See section 2 of http://www.ietf.org/ID-nits.html > > 11.) Technical content -- here are the comments on the MIB module > itself. > > (a) I suggest changing the following > > IMPORTS > -- delete next line before release > experimental, > MODULE-IDENTITY, Unsigned32 FROM SNMPv2-SMI > -- uncomment next line before release > -- mib-2 FROM RFC1213-MIB > TEXTUAL-CONVENTION FROM SNMPv2-TC; > > to > > IMPORTS > -- RFC Ed.: delete next line & remove this note before publication > experimental, > -- RFC Ed.: uncomment next line & remove this note before > publication > -- mib-2, > MODULE-IDENTITY, Unsigned32 FROM SNMPv2-SMI > TEXTUAL-CONVENTION FROM SNMPv2-TC; > > The purpose of this change is to import mib-2 from SNMPv2-SMI > rather than the by now out-of-date RFC1213-MIB and to make it > clear to the RFC editor which comment line are editor's > instructions that need to be removed when carried out. Making > similar changes to all other ASN.1 comments that are editor's > instructions is likewise recommended. > > (b) Please change the MODULE-IDENTITY descriptor from > ianaIPsecIsakmpIkeDoiTcMib to iPsecIsakmpIkeDoiTcMib (or > perhaps even better, to iPsecIsakmpIkeDoiTc -- that would > be in line with the naming conventions recommendeded by > Appendix E of ). > > (c) Please change the ORGANIZATION clause of the MODULE-IDENTITY > invocation to contain the official IPsec working group name and > please add the working group web page and mailing list info to > the CONTACT-INFO clause. See section 4.5 of > for details. > > (d) Please delete the second paragraph of the DESCRIPTION clause > of the MODULE-IDENTITY invocation, since it will no longer apply. > > (e) The DESCRIPTION clause for IpsecDoiSituation should state that > the object is a 32-bit (not a four (4) octet) bit mask, since the > data type is Unsigned32 and not OCTET STRING (SIZE(4)), and it > should point to the appropriate IANA registry entry for the assigned > values instead of listing them. Also, the REFERENCE clause should > point to RFC 2407 Section 6.1 (not 6.2). Finally, the ASN.1 comment > at the end explaining why the data type is Unsigned32 rather than > BITS is no longer needed if the change to the last paragraph of > Section 3 recommended in (2) above is accepted. A revised > definition along the following lines is suggested: > > IpsecDoiSituation ::= TEXTUAL-CONVENTION > DISPLAY-HINT "x" > STATUS current > DESCRIPTION "The IPsec DOI Situation is a 32-bit bitmask that > provides information which can be used by a > responder to make a policy determination about how > to process an incoming Security Association request. > > Situation assignments for the low-order 30 bits are > managed by the Internet Assigned Numbers Authority > (IANA). Assigned values are recorded in the IPSEC > Situation Definition section of the IANA Internet > Security Association and Key Management Protocol > (ISAKMP) Identifiers registry (a URL for which is > http://www.iana.org/assignments/isakmp-registry). > > The upper two bits (0x80000000 and 0x40000000) > are reserved for private use amongst cooperating > systems. It is RECOMMENDED that implementations > document the usage of such values in an > AGENT-CAPABILITIES statement." > REFERENCE "RFC 2407 sections 4.2 and 6.1" > SYNTAX Unsigned32 (0..4294967295) > > NOTE: the IpsecDoiSituation TC is not used in any of the > four MIB modules (IPSEC-SA-MON-MIB, ISAKMP-DOI-IND-MON-MIB, > IKE-MON-MIB, and IPSEC-POLICY-MIB) that currently import TCs > from IPSEC-ISAKMP-IKE-DOI-TC. Be aware that TCs which are not > used to define MIB objects that are included in two independent > implementations must be deprecated or obsoleted before the spec > containing them can advance beyond Proposed Standard. > > (f) Per the general recommendations above, the SYNTAX value for > IpsecDoiSecProtocolId should be changed to Unsigned32 (0..255), > and the DESCRIPTION clause should point to the appropriate IANA > registry entry for the assigned values and should recommend that an > agent-caps statement document use of "private use" values. Also, > the REFERENCE clause should point to RFC 2407 section 6.2 (in > addition to section 4.4.1). A revised definition along the > following lines is suggested: > > IpsecDoiSecProtocolId ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION "Managed objects of this type represent IPsec DOI > values for the IP Security Protocol Identifier > (Protocol ID) field in an ISAKMP Proposal Payload. > They may also represent values of the Protocol ID > field in the Notification Payload and the Delete > Payload. > > The value zero does not identify any particular > security protocol. It MAY be used in MIB objects > to indicate that the security protocol is unknown > or that none applies. Any such usage MUST be > documented in the MIB object's DESCRIPTION clause. > > Values between 1 and 248, inclusive, are managed > by the Internet Assigned Numbers Authority (IANA). > Assignments are recorded in the IPSEC Security > Protocol Identifiers section of the IANA Internet > Security Association and Key Management Protocol > (ISAKMP) Identifiers registry (a URL for which is > http://www.iana.org/assignments/isakmp-registry). > > The values 249-255 are reserved for private use > amongst cooperating systems. It is RECOMMENDED > that implementations document the usage of such > values in an AGENT-CAPABILITIES statement." > REFERENCE "RFC 2407 sections 4.4.1 and 6.2" > SYNTAX Unsigned32 (0..255) > > (g) The SYNTAX value for IpsecDoiTransformIdent should be changed to > Unsigned32 (0..255), and its DESCRIPTION clause should point to the > appropriate IANA registry entry for the assigned values and should > recommend that an agent-caps statement document use of the "private > use" values. A revised definition along the lines of the one shown > in 11(f) is suggested. > > (h) The SYNTAX value for IpsecDoiAhTransform should be changed to > Unsigned32 (0..255), and its DESCRIPTION clause should point to the > appropriate IANA registry entry for the assigned values and should > recommend that an agent-caps statement document use of the "private > use" values. Also, the REFERENCE clause should point only to > RFC 2407 sections 4.4.3 and 6.4, which define the parameter and > its value assignment rules. A revised definition along the lines > of the one shown in 11(f) is suggested. > > (i) The SYNTAX value for IpsecDoiEspTransform should be changed to > Unsigned32 (0..255), and its DESCRIPTION clause should point to the > appropriate IANA registry entry for the assigned values and should > recommend that an agent-caps statement document use of the "private > use" values. Also, the REFERENCE clause should point only to RFC > 2407 sections 4.4.4 and 6.5, which define the parameter and its > value assignment rules. A revised definition along the lines of the > one shown in 11(f) is suggested. > > (j) It is suggested that the order of appearance of the definitions > of IpsecDoiAuthAlgorithm, IpsecDoiIpcompTransform, and > IpsecDoiEncapsulationMode be changed to IpsecDoiIpcompTransform, > IpsecDoiEncapsulationMode, and IpsecDoiAuthAlgorithm so that > all of the IpsecDoi-related stuff appears in the same order as its > counterparts in http://www.iana.org/assignments/isakmp-registry and > RFC 2407 (this will make it easier to audit the registries and the > specifications for mutual consistency). > > (k) The SYNTAX value for IpsecDoiAuthAlgorithm should be changed to > Unsigned32 (0..65535), and its DESCRIPTION clause should point to > the appropriate IANA registry entry for the assigned values and > should recommend that an agent-caps statement document use of the > "private use" values. Also, the introductory text in the > DESCRIPTION clause should probably say just "Authentication > Algorithm" and not "ESP Authentication Algorithm", and the REFERENCE > clause should point only to RFC 2407 section 4.5 (which defines the > parameter). A revised definition along the lines of the one shown > in 11(f) is suggested. > > (l) The SYNTAX value for IpsecDoiIpcompTransform should be changed > to Unsigned32 (0..255), and its DESCRIPTION clause should point to > the appropriate IANA registry entry for the assigned values and > should recommend that an agent-caps statement document use of the > "private use" values. Also, the REFERENCE clause should point only > to RFC 2407 sections 4.4.5 and 6.6, which define the parameter and > its value assignment rules. A revised definition along the lines of > the one shown in 11(f) is suggested (see also 11(z) below). > > (m) The SYNTAX value for IpsecDoiEncapsulationMode should be changed > to Unsigned32 (0..65535), and its DESCRIPTION clause should point to > the appropriate IANA registry entry for the assigned values and > should recommend that an agent-caps statement document use of the > "private use" values. Also, a REFERENCE clause which points to RFC > 2407 section 4.5 should be added. A revised definition along the > lines of the one shown in 11(f) is suggested. > > (n) The SYNTAX value for IpsecDoiIdentType should be changed to > Unsigned32 (0..255), and its DESCRIPTION clause should point to > the appropriate IANA registry entry for the assigned values and > should recommend that an agent-caps statement document use of the > "private use" values. Also, the REFERENCE clause should point only > to RFC 2407 sections 4.6.2.1 and 6.9, which define the parameter and > its value assignment rules. A revised definition along the lines of > the one shown in 11(f) is suggested. > > (o) Although there are no private used values for IsakmpDOI, it is > still inappropriate to use an enumerated INTEGER type if values in > the range 2147483648..4294967295 need to be represented, as stated > in the DESCRIPTION clause and by RFC 2408 section 3.4. One must > instead use a SYNTAX value of Unsigned32 (0..4294967295) and either > point to a registry entry where assigned values can be found or list > them in the DESCRIPTION clause. Since this assigned values for this > parameter are not listed in any IANA registry the second option is > suggested. Also, the REFERENCE clause should to RFC 2408 (not RFC > 2048) and should probably mention sections 3.14 and 3.15 (in > addition to section 3.4) since the payloads documented in those > sections also contain a DOI value. A revised definition along the > following lines is suggested: > > IsakmpDOI ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION "Managed objects of this type represent Domain of > Interpretation (DOI) values for the ISAKMP Protocol. > They are 32-bit unsigned values used in the Domain > of Interpretation field of the Security Association > Payload, the Notification Payload, and the Delete > Payload. Currently assigned values are: > > isakmp(0) generic ISAKMP SA in used for > any protocol in Phase 2 > > ipsecDOI(1) the IPsec DOI as specified in > RFC 2407 > > At the present time there is no assigned number > registry for ISAKMP DOI values. A registry may > be established and additional values may be > assigned by the IANA at some future date." > REFERENCE "RFC 2408 sections 3.4, 3.14, and 3.15" > SYNTAX Unsigned32 (0..4294967295) > > (p) Unlike all the other enumerated INTEGER TCs in this MIB module, > there are no private use values for IsakmpCertificateEncoding and > its value range is easily accomodated by the INTEGER data type, so > the only technical objection to the existing definition is that it > does not have an enumeration of corresponding to the value NONE = 0 > that is listed in Section 3.9 of RFC 2408. While this could be > easily remedied by adding none(0) to the enumeration list, there > would still remain the issue of how to keep the enumeration list > properly maintained. It turns out, however, that this TC is not > used in any of the four MIB modules IPSEC-SA-MON-MIB, > ISAKMP-DOI-IND-MON-MIB, IKE-MON-MIB, and IPSEC-POLICY-MIB that > import TCs from IPSEC-ISAKMP-IKE-DOI-TC. So the recommended course > of action is to remove it from this MIB module and worry about the > issue when there is an actual need to do so. An alternative course > of action would be to change the SYNTAX value to Unsigned32 (0..255) > and re-write the DESCRIPTION clause along the lines of 11(o) above. > > (q) The SYNTAX value for IsakmpExchangeType should be changed to > Unsigned32 (0..31 | 240..255), and its DESCRIPTION clause should be > revised to specify that it represents only the values in the > DOI-independent or private-use ranges defined in RFC 2408 and to > recommend documenting use of the latter in an agent-caps statement. > A revised definition along the following lines is suggested: > > IsakmpExchangeType ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION "Managed objects of this type represent > DOI-independent values of the Exchange > Type field in the ISAKMP header. > > The value zero signifies an exchange type of NONE. > It MAY be used in MIB objects to indicate that the > exchange type is unknown or that none applies. Any > such usage MUST be documented in the MIB object's > DESCRIPTION clause. > > Values between 1 and 31, inclusive, represent > DOI-independent exchange types specified in > RFC 2408 Section 3.1. At the present time there > is no assigned number registry for DOI-independent > ISAKMP exchange type values. A registry may be > established and additional DOI-independent values > may be assigned by the IANA at some future date. > > The values 240-255 are reserved for private use > amongst cooperating systems. It is RECOMMENDED > that implementations document the usage of such > values in an AGENT-CAPABILITIES statement." > REFERENCE "RFC 2408 section 3.1" > SYNTAX Unsigned32 (0..31 | 240..255) > > NOTE: the IsakmpExchangeType TC is not used in any of > the four MIB modules (IPSEC-SA-MON-MIB, ISAKMP-DOI-IND-MON-MIB, > IKE-MON-MIB, and IPSEC-POLICY-MIB) that currently import TCs > from IPSEC-ISAKMP-IKE-DOI-TC. Be aware that TCs which are not > used to define MIB objects that are included in two independent > implementations must be deprecated or obsoleted before the spec > containing them can advance beyond Proposed Standard. > > (r) The SYNTAX value for IsakmpNotifyMessageType should be changed > to Unsigned32 (0..8191 | 16384..24575 | 32768..65535), and its > DESCRIPTION clause should be revised to specify that it represents > only the values in the DOI-independent or private-use ranges > defined in RFC 2408 and to recommend documenting use of the > latter in an agent-caps statement. A revised definition along > the following lines is suggested: > > IsakmpNotifyMessageType ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION "Managed objects of this type represent > DOI-independent values of the Notify Message > Type field in the ISAKMP Notification Payload. > > This textual convention merges the types > for error types (in the range 1-16383) and for > status types (in the range 16384-65535). > > The value zero does not not identify any particular > notify message type. It MAY be used in MIB objects > to indicate that the notify message type is unknown > or that none applies. Any such usage MUST be > documented in the MIB object's DESCRIPTION clause. > > Values between 1 and 8191, inclusive, represent > DOI-independent error message types specified in > RFC 2408 Section 3.14.1. At the present time there > is no assigned number registry for DOI-independent > ISAKMP error message type values. A registry may > be established and additional DOI-independent values > may be assigned by the IANA at some future date. > > Values between 16384 and 24575, inclusive, represent > DOI-independent status message types specified in > RFC 2408 Section 3.14.1. At the present time there > is no assigned number registry for DOI-independent > ISAKMP status message type values. A registry may > be established and additional DOI-independent values > may be assigned by the IANA at some future date. > > Values in the range 32768-40959 are reserved for > private use as status message types amongst > cooperating systems. It is RECOMMENDED that > implementations document the usage of such > values in an AGENT-CAPABILITIES statement. > > Values in the range 40960-65535 are reserved for > future use." > REFERENCE "RFC 2408 section 3.14.1" > SYNTAX Unsigned32 (0..8191 | 16384..24575 | 32768..65535) > > NOTE: RFC 2408 Section 3.14.1 states that values in the range > 8192..16383 are for private use, but also states that codes in > this range are expected to be DOI-specific. Since RFC 2407 > allocated DOI-specific error message codes from this range, the > DESCRIPTION clause above assumes that the range 8192..16383 is > DOI-specific and excludes that range from the allowed values. > > (s) The SYNTAX value for IkeExchangeType should be changed to > Unsigned32 (0..255), and its DESCRIPTION clause should point to > the appropriate IANA registry entries for the assigned values and > should recommend that an agent-caps statement document use of the > "private use" values. Also, the REFERENCE clause should point to > RFC 2408 sections 3.1 as well as RFC 2409 Appendix A. A revised > definition along the following lines is suggested: > > IkeExchangeType ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION "Managed objects of this type represent values of > the Exchange Type field in the ISAKMP header that > pertain to IKE. > > The value zero signifies an exchange type of NONE. > It MAY be used in MIB objects to indicate that the > exchange type is unknown or that none applies. Any > such usage MUST be documented in the MIB object's > DESCRIPTION clause. > > Values between 1 and 31, inclusive, represent > DOI-independent exchange types specified in > RFC 2408 Section 3.1. At the present time there > is no assigned number registry for DOI-independent > ISAKMP exchange type values. A registry may be > established and additional DOI-independent values > may be assigned by the IANA at some future date. > > Values between 32 and 239, inclusive, represent > exchange types that pertain specifically to IKE. > Assignments are recorded in the Additional > Exchanges section of the IANA Internet Key Exchange > (IKE) Attributes registry (a URL for which is > http://www.iana.org/assignments/ipsec-registry). > > The values 240-255 are reserved for private use > amongst cooperating systems. It is RECOMMENDED > that implementations document the usage of such > values in an AGENT-CAPABILITIES statement." > REFERENCE "RFC 2408 section 3.1 and RFC 2409 Appendix A" > SYNTAX Unsigned32 (0..255) > > NOTE: since the additional XCHG values for IKE are listed last > both in RFC 2409 Appendix A and in the IKE Attributes registry > http://www.iana.org/assignments/ipsec-registry, it might be a > good idea to relocate this TC just after IkePrf (this will make > it easier to audit the registries and the MIB module for mutual > consistency). > > (t) The SYNTAX value for IkeEncryptionAlgorithm should be changed to > Unsigned32 (0..65535), and its DESCRIPTION clause should point to > the appropriate IANA registry entry for the assigned values and > should recommend that an agent-caps statement document use of the > "private use" values. Also, the REFERENCE clause should point to > RFC 2409 Appendix A only, as this is the reference that defines the > parameter. A revised definition along the following lines is > suggested: > > IkeEncryptionAlgorithm ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION "Managed objects of this type represent values > for encryption algorithms negotiated for the > ISAKMP SA by IKE in Phase I. These are values > for SA Attribute type Encryption Algorithm (1). > > The value zero does not not identify any particular > encryption algorithm. It MAY be used in MIB objects > to indicate that the exchange type is unknown or > that none applies. Any such usage MUST be > documented in the MIB object's DESCRIPTION clause. > > Values between 1 and 65000, inclusive, are managed > by the Internet Assigned Numbers Authority (IANA). > Assignments are recorded in the Encryption > Algorithm section of the IANA Internet Key Exchange > (IKE) Attributes registry (a URL for which is > http://www.iana.org/assignments/ipsec-registry). > > Values 65001-65535 are for private use among > mutually consenting parties. It is RECOMMENDED > that implementations document the usage of such > values in an AGENT-CAPABILITIES statement." > REFERENCE "RFC 2409 appendix A" > SYNTAX Unsigned32 (0..65535) > > (u) The SYNTAX value for IkeHashAlgorithm should be changed to > Unsigned32 (0..65535), and its DESCRIPTION clause should point to > the appropriate IANA registry entry for the assigned values and > should recommend that an agent-caps statement document use of the > "private use" values. Also, the REFERENCE clause should point to > RFC 2409 Appendix A only, as this is the reference that defines the > parameter. A revised definition along the lines of the one shown > in 11(t) is suggested. > > (v) The SYNTAX value for IkeAuthMethod should be changed to > Unsigned32 (0..65535), and its DESCRIPTION clause should point to > the appropriate IANA registry entry for the assigned values and > should recommend that an agent-caps statement document use of the > "private use" values. Also, the REFERENCE clause should point to > RFC 2409 Appendix A only, as this is the reference that defines the > parameter. A revised definition along the lines of the one shown > in 11(t) is suggested. > > (w) The SYNTAX value for IkeGroupDescription should be changed to > Unsigned32 (0..65535), and its DESCRIPTION clause should point to > the appropriate IANA registry entry for the assigned values and > should recommend that an agent-caps statement document use of the > "private use" values. Also, the REFERENCE clause should point to > RFC 2409 Appendix A only, as this is the reference that defines the > parameter. A revised definition along the lines of the one shown > in 11(t) is suggested. > > (x) The SYNTAX value for IkeGroupType should be changed to > Unsigned32 (0..65535), and its DESCRIPTION clause should point to > the appropriate IANA registry entry for the assigned values and > should recommend that an agent-caps statement document use of the > "private use" values. A revised definition along the lines of the > one shown in 11(t) is suggested. > > NOTE: the IkeGroupType TC is not used in any of the four MIB > modules (IPSEC-SA-MON-MIB, ISAKMP-DOI-IND-MON-MIB, IKE-MON-MIB, > and IPSEC-POLICY-MIB) that currently import TCs from > IPSEC-ISAKMP-IKE-DOI-TC. Be aware that TCs which are not used > to define MIB objects that are included in two independent > implementations must be deprecated or obsoleted before the spec > containing them can advance beyond Proposed Standard. > > (y) The DESCRIPTION clause for IkePrf should point to the > appropriate IANA registry entry for the assigned values and should > recommend that an agent-caps statement document use of the "private > use" values. A revised definition along the lines of the one shown > in 11(t) is suggested. > > (z) The SYNTAX value for IkeNotifyMessageType should be changed to > Unsigned32 (0..65535), and its DESCRIPTION clause should point to > the appropriate IANA registry entries for the assigned values and > should recommend that an agent-caps statement document use of the > "private use" values. A revised definition along the following > lines is suggested: > > IsakmpNotifyMessageType ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION "Managed objects of this type represent values > of the Notify Message Type field in the ISAKMP > Notification Payload. > > This textual convention merges the types > for error types (in the range 1-16383) and for > status types (in the range 16384-65535). > > The value zero does not not identify any particular > notify message type. It MAY be used in MIB objects > to indicate that the notify message type is unknown > or that none applies. Any such usage MUST be > documented in the MIB object's DESCRIPTION clause. > > Values between 1 and 8191, inclusive, represent > DOI-independent error message types specified in > RFC 2408 Section 3.14.1. At the present time there > is no assigned number registry for DOI-independent > ISAKMP error message type values. A registry may > be established and additional DOI-independent values > may be assigned by the IANA at some future date. > > Values between 8192 and 16383, inclusive, represent > DOI-specific error message types. Assignments are > recorded in the Notify Messages - Error Types > subsection of the IPSEC Notify Message Types section > of the IANA Internet Security Association and Key > Management Protocol (ISAKMP) Identifiers registry > (http://www.iana.org/assignments/isakmp-registry). > > Values between 16384 and 24575, inclusive, represent > DOI-independent status message types specified in > RFC 2408 Section 3.14.1. At the present time there > is no assigned number registry for DOI-independent > ISAKMP status message type values. A registry may > be established and additional DOI-independent values > may be assigned by the IANA at some future date. > > Values between 24576 and 32767, inclusive, represent > DOI-specific status message types. Assignments are > recorded in the Notify Messages - Status Types > subsection of the IPSEC Notify Message Types section > of the IANA Internet Security Association and Key > Management Protocol (ISAKMP) Identifiers registry > (http://www.iana.org/assignments/isakmp-registry). > > Values in the range 32768-40959 are reserved for > private use as status message types amongst > cooperating systems. It is RECOMMENDED that > implementations document the usage of such > values in an AGENT-CAPABILITIES statement. > > Values in the range 40960-65535 are reserved for > future use." > REFERENCE "RFC 2408 section 3.14.1 and RFC 2407 sections 4.6.3 > and 6.10" > SYNTAX Unsigned32 (0..65535) > > > 12.) The following minor editorial changes are requested: > > (a) s/Attrbute/Attribute/ in all the IkeXyz TC DESCRIPTION clauses > where it appears. > > (b) Please change phrases such as "when used in a MIB" to "when used > in a MIB module" throughout the document. > > Note that if the change recommendations above are accepted, then > some minor changes will also have to be made to some of the modules > that import TCs from IPSEC-ISAKMP-IKE-DOI-TC. Here are the modules > that are known to import from IPSEC-ISAKMP-IKE-DOI-TC: > > Client Module Internet Draft > > IPSEC-SA-MON-MIB > ISAKMP-DOI-IND-MON-MIB > IKE-MON-MIB > IPSEC-POLICY-MIB > > The (minimum) required changes would be as follows: > > IPSEC-SA-MON-MIB none known > > ISAKMP-DOI-IND-MON-MIB none known > > IKE-MON-MIB The DESCRIPTION clauses of ikeSaTable > and ikeSaEntry refer to 'ipsecDOI(1)'. > The DESCRIPTION clause of ipsecSaInSuiteSpi > refers to 'protoIpcomp(4)'. These clauses > should be edited to reflect the fact that > these enums will no longer exist. > > IPSEC-POLICY-MIB The DEFVAL clause of ipspSaPreActActionType > will need to be changed from '{ tunnel }' > to '{ 1 } -- tunnel', or else the object > needs to get a stand-alone definition > independent of a TC, as was done for > ipspIpsecActMode. Also, the DESCRIPTION > clauses for ipspIpsecPropProtocolId and > ipspIpsecTranType refer to protoIsakmp(1). > These clauses should be edited to reflect > the fact that this enum will not exist. > > Other changes might also be required (e.g., to comply with the > proposed requirement to document how the special value 0 is used). > The authors/editors of these MIB modules have been bcc:'d. > > One last point: it is acknowledged that the main recommendations in > this review are controversial. Understand that all recommendations > are presented as advice to the OPS AD responsible for Network > Management (see http://www.ops.ietf.org/mib-doctors.html), and any > recommendation with which folks do not agree may be challenged. > > Regards, > > Mike Heard > From owner-ipsec@lists.tislabs.com Tue Apr 29 06:42:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TDgqi2090822; Tue, 29 Apr 2003 06:42:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04542 Tue, 29 Apr 2003 09:05:58 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16046.31147.326247.386514@pkoning.dev.equallogic.com> Date: Tue, 29 Apr 2003 09:10:03 -0400 From: Paul Koning To: pbaker@verisign.com Cc: jzhang@elmic.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com Subject: RE: Crypto algorithms for IKEv2 References: X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Phillip" == Phillip Hallam-Baker writes: Phillip> At the RSA crypto panel Bruce told folk to use AES. better Phillip> we all use the same thing. Phillip> At this point I would rather we start deprecating algorithms Phillip> rather than add more. Phillip> I would especially like to get rid of RC4, including a Phillip> stream cipher in a list of block ciphers is real bad news, Phillip> especially when the traditional default has been a block Phillip> cipher. There are lots of unexpected problems that occur Phillip> with stream ciphers which is why lots of folk avoid them in Phillip> designs. Considering that IPsec doesn't work with stream ciphers, that would seem to be a very good idea. paul From owner-ipsec@lists.tislabs.com Tue Apr 29 08:53:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TFrGi2099595; Tue, 29 Apr 2003 08:53:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04956 Tue, 29 Apr 2003 11:10:40 -0400 (EDT) Message-Id: <200304291515.h3TFFJmk003576@marajade.sandelman.ottawa.on.ca> To: Paul Hoffman / VPNC cc: ipsec@lists.tislabs.com Subject: Re: Crypto algorithms for IKEv2 In-reply-to: Your message of "Mon, 28 Apr 2003 11:11:58 PDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Apr 2003 11:15:19 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Editorial comments/questions: Where are the ENCR_DES_IV32 and ENCR_RC4 defined? RFC2401bis? Or? From owner-ipsec@lists.tislabs.com Tue Apr 29 08:57:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TFv1i2099807; Tue, 29 Apr 2003 08:57:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05001 Tue, 29 Apr 2003 11:22:46 -0400 (EDT) Message-Id: <200304291527.h3TFRe1j003878@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Crypto algorithms for IKEv2 In-reply-to: Your message of "Mon, 28 Apr 2003 11:11:58 PDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Apr 2003 11:27:39 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: VPNC> This document is meant to be a companion to the *next* draft of VPNC> IKEv2. In that draft, Charlie can cleanly excise from his section VPNC> 3.3.2 the cryptographic tables labeled "For Transform Type 1", "For VPNC> Transform Type 2", "For Transform Type 3", and "For Transform Type VPNC> 4", leaving Transform Type 5, which is not cryptographic. He can also VPNC> remove the MUST, SHOULD, and MAY statements in Appendix B. Paul, I think that this is a very good way to organize things. I have one additional suggestion, which you may or may not like. Split this document into two documents: Document 1 title: Security Algorithms for IKEv2 sections 1, 1.3, 2. Document 2 title: A VPN profile for IKEv2 section 3, plus all MANDATORY statements from other sections. Rational for this: a) This makes Document 1 really the initial IANA registry. Very simple for IANA to grok. Very simple for implementors to reference as well. b) Document 2 now becomes readable to end-users, to system support people, and even to marketing. c) Your document claims it is for VPN use, so make it so. d) I do not believe that any statements about "MUST" can really be made in isolation of the application area. We have long endless debates about what is "best" because we have differing goals, and therefore different risk/benefit tradeoffs. e) "Note that the suites listed here are for use of IPsec in virtual private networks. Other uses of IKEv2 and IPsec will probably want to define their own suites and give them different names." This is perfectly fine with me. By naming the document to reflect this, you open up the floor to having other users define their own needs. In the end, a customer will specify a device that is RFC-Document2 compliant for their VPN use, and things will work. It might be that after doing this that Document 1 isn't worth removing from IKEv2. I don't care one way or another. One final question is that it might be there there should still be a MUST for some IKEv2 transforms. This might permit a mobile VoIP phone to be able to get far enough in negotiation with a VPN-only box to determine that they share no common phase 2 protocols. I don't know if this is useful. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPq6Z6IqHRg3pndX9AQFL6wP/T6Xk6wMYpkNhLP8Kf0MsIOqoBhICBPSt +GtDmrjebiQvfCD/s8I6lQbsc4gwQWHshCvQ/3085NpyNTNg6ZkMOjhE4XnZ783L axHbDU3MHxWBlNR4UmFKRACJZDdnjH2JmvpgJRZgw9ZFM9MjkThCNKaTzi1Ofx6A rsgg0RSY4/I= =iZRb -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Apr 29 10:36:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3THa3i2002737; Tue, 29 Apr 2003 10:36:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05403 Tue, 29 Apr 2003 12:56:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <000001c30de3$902b4d00$0300a8c0@riverside> References: <000001c30de3$902b4d00$0300a8c0@riverside> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 29 Apr 2003 09:35:25 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RE: Crypto algorithms for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hoffman-ipsec-algorithms-00.txt Date: Tue, 29 Apr 2003 07:39:59 -0400 Sender: owner-ietf-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Security Algorithms for IKEv2 Author(s) : P. Hoffman Filename : draft-hoffman-ipsec-algorithms-00.txt Pages : 6 Date : 2003-4-28 The IKEv2 protocol [IKEv2] relies on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IKEv2 systems cannot interoperate unless they are using the same algorithms. This document specifies an initial set of algorithms for registration with IANA, and specifies which are mandatory to implement. This document also specifies optional suites of algorithms and attributes that can be used to simplify the administration of IKEv2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-ipsec-algorithms-00.txt --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Apr 29 10:36:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3THaZi2002772; Tue, 29 Apr 2003 10:36:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05409 Tue, 29 Apr 2003 12:56:17 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200304291527.h3TFRe1j003878@marajade.sandelman.ottawa.on.ca> References: <200304291527.h3TFRe1j003878@marajade.sandelman.ottawa.on.ca> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 29 Apr 2003 09:43:47 -0700 To: Michael Richardson , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Crypto algorithms for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:27 AM -0400 4/29/03, Michael Richardson wrote: > Paul, I think that this is a very good way to organize things. > I have one additional suggestion, which you may or may not like. > >Split this document into two documents: >Document 1 title: Security Algorithms for IKEv2 > sections 1, 1.3, 2. > >Document 2 title: A VPN profile for IKEv2 > section 3, plus all MANDATORY statements from other sections. This is an interesting idea, but it kind of goes against what people had said they wanted, which was to have the MUSTs and SHOULDs with the algorithm specifiers. >Rational for this: >a) This makes Document 1 really the initial IANA registry. > Very simple for IANA to grok. > Very simple for implementors to reference as well. > >b) Document 2 now becomes readable to end-users, to > system support people, and even to marketing. > >c) Your document claims it is for VPN use, so make it so. > >d) I do not believe that any statements about "MUST" can really > be made in isolation of the application area. We have long > endless debates about what is "best" because we have differing > goals, and therefore different risk/benefit tradeoffs. > >e) "Note that the suites listed here are for use of IPsec in virtual > private networks. Other uses of IKEv2 and IPsec will probably want > to define their own suites and give them different names." All of these sound fine to me, if that's where the WG wants to go. On the other hand: a) IANA can grok whatever we give them. Also, we don't want implementers referencing the RFC: we want them referencing the IANA registry. This is one of the big problems we have had with IKEv1. b) We don't expect end users to read RFCs. If we want them to do that, someone (like VPNC) can create a "RFC xwyz in plain English" document. >In the end, a customer will specify a device that is RFC-Document2 compliant >for their VPN use, and things will work. But they don't need to be able to read that RFC in order to specify it. :-) --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Apr 29 10:43:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3THhti2003637; Tue, 29 Apr 2003 10:43:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05481 Tue, 29 Apr 2003 13:14:53 -0400 (EDT) Message-Id: <4.3.2.7.1.20030429100127.024bebe0@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Apr 2003 10:21:06 -0700 To: Jyothi , Stephen Kent From: Ramana Yarlagadda Subject: Re: Question on inbound IPSEC policy check Cc: ipsec@lists.tislabs.com In-Reply-To: <5.1.0.14.0.20030429090406.00a2fec0@172.16.1.10> References: <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Jyothi >Office1Network-----SG1---------Internet------------SG2-------Office2Network. > >SG1 contains the 2 IPSEC policies: > 1. protocol TCP and port 80 > 2. protocol ANY > >SG2 contains the one IPSEC policy of protocol ANY. > >Office2Network starts the IKE negotiation for protocol ANY, after the >negotiation SG2 will send the HTTP traffic with SAs created. > >In IKE negotiation, we are informing the allowable traffic as protocol ANY. > In this case, HTTP is part of protocol ANY. > >So, if SG1 rejects inbound traffic coming from SG2, then how SG2 knows?? > Why do you think the inbound traffic will be dropped? To my understanding the traffic will not be discarded. On SG1 the incoming SA (that is been setup by IKE) will be used to process the packet. And then it will try to find a matching IPSEC policy . The first matching entry will be protocol specific , where the SA is not of that policy. So you might be thinking that this will result to drop the packet. But if you go through section 5.2.1 you will see a NOTE where it is clearly described this case( and as follows) NOTE: The correct "matching" policy will not necessarily be the first inbound policy found. If the check in (4) fails, steps (3) and (4) are repeated until all policy entries have been checked or until the check succeeds -ramana >>>If we reject the traffic, how do we inform the peer??? >>>I think there might be some inter-operability issues. >>If the SAs are established using IKE, then the payloads passed during the >>IKE negotiations will inform the peer of the range of allowable traffic, >>so it will not be a surprise. From owner-ipsec@lists.tislabs.com Tue Apr 29 10:46:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3THk5i2003809; Tue, 29 Apr 2003 10:46:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05504 Tue, 29 Apr 2003 13:18:15 -0400 (EDT) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Crypto algorithms for IKEv2 Date: 29 Apr 2003 16:57:31 GMT Organization: University of California, Berkeley Lines: 18 Distribution: isaac Message-ID: References: <000001c30de3$902b4d00$0300a8c0@riverside> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1051635451 20981 128.32.153.211 (29 Apr 2003 16:57:31 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 29 Apr 2003 16:57:31 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jimmy Zhang wrote: >How about TWOFISH ? No, please. Stick to AES and Triple-DES; they are very fine algorithms. My strong advice is to use AES, not Twofish. There's nothing wrong with Twofish -- I'm pleased with the design and how it has held up -- but I think AES is clearly the right choice over Twofish. AES was selected for the standard over all other competitors, and I think, rightly so. Most importantly, AES is receiving far more scrutiny than Twofish. This gives a powerful reason to prefer AES over Twofish (or any of the other finalists, including Serpent, for that matter). I prefer to view Twofish as deprecated these days and to encourage people to use AES instead, unless there is some special requirement that makes AES unsuitable. Full disclosure: I was a co-designer of Twofish, so I'm probably biased. From owner-ipsec@lists.tislabs.com Tue Apr 29 10:47:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3THlii2003873; Tue, 29 Apr 2003 10:47:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05466 Tue, 29 Apr 2003 13:12:59 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16046.45969.345514.100016@pkoning.dev.equallogic.com> Date: Tue, 29 Apr 2003 13:17:05 -0400 From: Paul Koning To: mcr@sandelman.ottawa.on.ca CC: ipsec@lists.tislabs.com Subject: Re: Crypto algorithms for IKEv2 References: <200304291515.h3TFFJmk003576@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Richardson writes: Michael> Editorial comments/questions: Michael> Where are the ENCR_DES_IV32 and ENCR_RC4 defined? Michael> RFC2401bis? Nowhere, I believe. ENCR_RC4 is clearly nonsense -- IPsec cannot work with stream ciphers because IPsec works with IP datagrams. Stream ciphers like RC4 require loss-free delivery, which IP does not offer. So ENCR_RC4 is simply a mistake that was never corrected. paul From owner-ipsec@lists.tislabs.com Tue Apr 29 11:01:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TI1Oi2004194; Tue, 29 Apr 2003 11:01:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05549 Tue, 29 Apr 2003 13:24:54 -0400 (EDT) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Crypto algorithms for IKEv2 Date: 29 Apr 2003 17:04:11 GMT Organization: University of California, Berkeley Lines: 15 Distribution: isaac Message-ID: References: NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1051635851 20981 128.32.153.211 (29 Apr 2003 17:04:11 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 29 Apr 2003 17:04:11 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hallam-Baker, Phillip wrote: >At the RSA crypto panel Bruce told folk to use AES. better we all use the >same thing. > >At this point I would rather we start deprecating algorithms rather than add >more. I agree. >I would especially like to get rid of RC4, including a stream cipher in a >list of block ciphers is real bad news, especially when the traditional >default has been a block cipher. There are lots of unexpected problems that >occur with stream ciphers which is why lots of folk avoid them in designs. This seems like a very compelling argument. From owner-ipsec@lists.tislabs.com Tue Apr 29 13:40:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TKeii2009549; Tue, 29 Apr 2003 13:40:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06339 Tue, 29 Apr 2003 16:08:28 -0400 (EDT) Message-Id: <200304292013.h3TKDMBH010593@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Crypto algorithms for IKEv2 In-reply-to: Your message of "Tue, 29 Apr 2003 13:17:05 EDT." <16046.45969.345514.100016@pkoning.dev.equallogic.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Apr 2003 16:13:21 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Paul" == Paul Koning writes: >>>>> "Michael" == Michael Richardson writes: Michael> Editorial comments/questions: Michael> Where are the ENCR_DES_IV32 and ENCR_RC4 defined? Michael> RFC2401bis? Paul> Nowhere, I believe. Paul> ENCR_RC4 is clearly nonsense -- IPsec cannot work with stream ciphers Paul> because IPsec works with IP datagrams. Stream ciphers like RC4 Paul> require loss-free delivery, which IP does not offer. So ENCR_RC4 is Paul> simply a mistake that was never corrected. I thought that we had a way to synchronous a stream cipher with an offset that essentially replaces the IV. This is computationally expensive if you do it wrong, but is currently done. I don't know - I never wrote RC4. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPq7c34qHRg3pndX9AQGHpQQA6Mb+5x5RvtyC6IOMv2aUcUIJcHiU2vr4 QNyO7E3O79ycIniWV315DH03GBfBHWMrFjO09N9Gwa4b+YAZmg6SxOvtvOzxtbeM LeOLI0z7v27QpExwe5vz3/xDRv++ABDTa7aChnRP8sUS17fYc1vbihz7e93IXSEk p6fAlrHlKfQ= =g6n9 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Apr 29 13:40:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TKeii2009548; Tue, 29 Apr 2003 13:40:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06332 Tue, 29 Apr 2003 16:07:17 -0400 (EDT) Message-Id: <200304292012.h3TKC1mi010546@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Crypto algorithms for IKEv2 In-reply-to: Your message of "Tue, 29 Apr 2003 09:43:47 PDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Apr 2003 16:12:00 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: VPNC> At 11:27 AM -0400 4/29/03, Michael Richardson wrote: >> Paul, I think that this is a very good way to organize things. >> I have one additional suggestion, which you may or may not like. >> >> Split this document into two documents: >> Document 1 title: Security Algorithms for IKEv2 >> sections 1, 1.3, 2. >> >> Document 2 title: A VPN profile for IKEv2 >> section 3, plus all MANDATORY statements from other sections. VPNC> This is an interesting idea, but it kind of goes against what people VPNC> had said they wanted, which was to have the MUSTs and SHOULDs with VPNC> the algorithm specifiers. Ah. I see. VPNC> a) IANA can grok whatever we give them. Also, we don't want VPNC> implementers referencing the RFC: we want them referencing the IANA VPNC> registry. This is one of the big problems we have had with IKEv1. Good point. >> In the end, a customer will specify a device that is RFC-Document2 compliant >> for their VPN use, and things will work. VPNC> But they don't need to be able to read that RFC in order to specify it. :-) Well, the UI Suites section is pretty much readable to end-users. The purchasing people will spec it, but the admins will read the RFC when they get a product which can interop, but doesn't present UI suites in the UI. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPq7cjoqHRg3pndX9AQGSpAP/eiKjH5TyrlJf6hynWq28E+Zu/cIT9w0+ zm6pEjhJFt2D8JNrlAxQbFmCLH65jbccS8h9Tr/J+qTurQpDPlzJ9HguVUHWqLP4 F9ruXRBQ1vn8V3yqlUSk4HsOSXUrlEzg0C8zN1maJ2Wu3Kzw3kJ6l6pVo7cOZj1c y04kVNtdAI0= =/tt2 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Apr 29 14:58:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLw3i2012196; Tue, 29 Apr 2003 14:58:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06617 Tue, 29 Apr 2003 17:16:56 -0400 (EDT) Message-Id: <200304292121.h3TLLopu012327@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Plugfest in July Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Apr 2003 17:21:49 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- We are trying to make travel plans for this summer. At present there are few companies signed up for the plugfest. Are there others planning/thinking about attending? Given that summer flights are still busy, and booking ahead saves much $$$, we want to book for Vienna now. But, we don't know if this "plugtest" is worth it. Only URL that I could find was the frame itself, which seems to reparent you: http://www.etsi.org/frameset/home.htm?/plugtests/02UpcomingEvents/IPsec/IPsec_registration.htm ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPq7s6IqHRg3pndX9AQEEvAP+PUhemSE66dnAFZ880M/mX0yhLQ3xabKC HskNqPOemkTZa0P+su5h/WOFHuE7S/AtyatHIM93vDxtWSzVYAcMnjGAFQTT4+X8 2Zi1BACQNrxshjoSn5sxxL2qEzaeXLRxaygIebseQak6Bmtw7aknkhKIw+PzXlTA bsih91Ult/o= =bOVW -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Apr 29 16:58:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TNwVi2014776; Tue, 29 Apr 2003 16:58:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07045 Tue, 29 Apr 2003 19:21:54 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66CD7@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Paul Hoffman / VPNC'" , ipsec@lists.tislabs.com Subject: RE: Requirements for IKEv2 implementations Date: Tue, 29 Apr 2003 16:20:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ...Interesting silence to this post... MY WG and Security Area member perspective: Certificates are good security and we should try as much as we can to help implementations adopt them. Any worthwhile IKEv1 implementation today can handle certs. IKEv2 should be no different. My NetScreen employee perspective: Our implementations do both today, so its no big deal if certs are required. Market observer perspective: PKI has been a royal pain for many interested in IPsec VPNs. Just ask the PKI vendors. They have abandoned the application as a focus for their development, marketing and sales. At an absolute minimum, PSS is a MUST. Gregory. > -----Original Message----- > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > Sent: Saturday, April 26, 2003 4:21 PM > To: ipsec@lists.tislabs.com > Subject: Requirements for IKEv2 implementations > > > Greetings again. The -05 draft of IKEv2 introduced the > following requirements: > > For an implementation to be called conforming to this > specification, > it MUST be possible to configure it to accept the following: > > PKIX Certificates containing and signed by RSA keys of > size 1024 or > 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, > ID_RFC822_ADDR, or ID_DER_ASN1_DN. > > Shared key authentication where the ID passes is any of ID_KEY_ID, > ID_FQDN, or ID_RFC822_ADDR. > > Authentication where the responder authenticates using PKIX > Certificates and the initiator authenticates using shared key > authentication. > > I don't remember seeing this discussed in the WG before now. > > There are many reasons why an implementation might not want to > support PKIX certificates, including the fact that many vendors find > that PKIX is too complicated to support securely. In some security > environments, other forms of public key infrastructures are more > appropriate for some security uses. And, of course, for systems that > have the ability to create and distribute good shared secrets, PKIX > support is just dangerous bloat. > > The minimum that is needed for interoperability is shared secrets. > The document already has requirements for handling large shared > secrets, so we don't need to worry about limitations that reduce to > passwords. Requiring both shared secrets *and* PKIX-specific public > key support does not help interoperability, and because of the nature > of PKIX, hurts it significantly. We only need to mandate one or the > other, and given the ugly reality of PKIX, it should only be > sufficiently long shared secrets. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Tue Apr 29 17:15:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U0Fsi2015193; Tue, 29 Apr 2003 17:15:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07107 Tue, 29 Apr 2003 19:42:43 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66CD9@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Charlie_Kaufman@notesdev.ibm.com'" , Ravi Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: RE: DPD Notification messages in IKEv2 Date: Tue, 29 Apr 2003 16:40:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Hi, > > I did not see any notification messages related to DPD in IKEv2-06 > > specifications. > > Is there any plan to put these notifications in next version. > > Regards, > > Ravi > > The IKEv2 spec has said for some time that an empty exchange > (a message > with no payloads) can be used for dead peer detection since > every message > must be acknowledged including an empty one. > > Is some other form of notification message needed? I do not believe so. I think we nailed this one already. From owner-ipsec@lists.tislabs.com Tue Apr 29 17:32:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U0Wsi2015639; Tue, 29 Apr 2003 17:32:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07304 Tue, 29 Apr 2003 20:04:57 -0400 (EDT) Date: Wed, 30 Apr 2003 03:09:31 +0300 (IDT) From: Hugo Krawczyk To: Charlie_Kaufman@notesdev.ibm.com cc: IPsec WG Subject: ikev2-07: last nits In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie, thanks for taking care of my comments on 06 (and for the overall wonderful work). Here there are a few remaining editorial issues that need some polishing (nothing controversial, I hope) . The pointers refer to version 07. In most cases I am suggesting explicit text to make yuor work easier (but feel free to improve it...) (1) Page 23 sec 2.10: Current text: These nonces are used to add freshness to the key derivation technique used to obtain keys for CHILD_SAs. Proposed text: These nonces are used to add freshness to the key derivation technique used to obtain keys for CHILD_SA, and to extract strong pseudorandom bits from the Diffie-Hellman key. Explanation: I added the text after the comma which is an essential part of the rationale behind IKE's key derivation technique [SIGMA] (2) Page 26 2.14 Current text: Ni and Nr are the nonces, stripped of any headers. If the negotiated prf takes a fixed length key, Ni and Nr MUST each be truncated to one half of the fixed key length. Proposed text: Ni and Nr are the nonces, stripped of any headers. If the negotiated prf takes a fixed length key, the key Ni | Nr MUST be formed by truncating each of Ni and Nr to one half of the fixed key length (if truncation is performed then the exceeding most significant bits of each nonce are not used when forming the prf key Ni | Nr). Explanation: I added the specification that in case of truncation one uses the least significant bits of the nonces (choosing the "lsb" was arbitrary). The current text is under-specified since it says to truncate the nonces to half the key length but is silent about which bits to use. (Also, I tried to write this in a way that makes clear that the truncation is done only for the sake of forming the key to prf, but not for other uses of the nonces -- if this is still not clear maybe more explicit text on this is needed.) (3) Page 27 2.15: Current text: This is typically insecure because user chosen passwords are unlikely to have sufficient unpredictability to resist dictionary attacks. Proposed text: This is typically insecure because user chosen passwords are unlikely to have sufficient unpredictability to resist dictionary attacks, and these attacks are not prevented in this authentication method (applications using password-based authentication for bootstrapping an IKE exchange should use the authentication method in section 2.16 which is designed to prevent off-line dictionary attacks). Explanation: I added this explicit design decision, namely, not having designed pre-shared mode to prevent dictionary attacks; also it is important to say explicitly that password authentication should be used only in the framework of the EAP methods from sec 2.16. If you do not like this text here, it can be moved to security considerations. (4) Page 27 2.15 Current text: The pad string is added so that if the shared secret is derived from a password, the IKE implementation need not store the password in cleartext, but rather can store a one way transformation of it that could not be used as a password equivalent for protocols other than IKEv2. Proposed text: The pad string is added so that if the shared secret is derived from a password, the IKE implementation need not store the password in cleartext, but rather can store the value prf(Shared Secret,"Key Pad for IKEv2") that could not be used as a password equivalent for protocols other than IKEv2. Explanation: the current text is too general. The above is more specific and then probably clearer. (5) Page 29 2.17 Current text: For CREATE_CHILD_SA exchanges with PFS the keying material is defined as: KEYMAT = prf+(SK_d, g^ir (ph2) | Ni | Nr ) Proposed text: erase g^ir (ph2) Explanation: this is a leftover from 06. You erased g^ir from other places where it was unneeded but this one stayed. If I understand correctly, the value SK_d used in this derivation is computed in section 2.18 using SKEYSEED which, in turn, is already derived from g^ir (new) . Thus re-using g^ir (ph2) (here `ph2' and `new' refer to the same thing) under SK_d is of no help (and spoils the theoretical analysis). (6) Page 81 Sec 5 (Security Considerations) Current text: The strength of all keys are limited by the size of the output of the negotiated prf function. For this reason, a prf function whose output is less than 128 bits (e.g. 3DES-CBC) MUST never be used with this protocol. Discussion: You may want to add that a prf that outputs less bits than its own key is also unsuited for use (even if its output is longer than 128 bits). The reason for this is that SKEYSEED is produced by a (single) application of the prf and its length needs to be that of the prf key. Important: The above specifications on the usable prf's should go to the normative part of the document (sections 2.13 or 2.14) rather than in these Security Considerations. I suggest to also add there that SKEYSEED is to be at least of the length of a secure key for the negotiated prf (and if this prf is of fixed-length key then SKEYSEED is to be of exactly this length). (7) Security Considerations Add text (possibly before the last paragraph on NAT traversal): For information on the rationale of many of the cryptographic design choices in this protocol see [SIGMA]. Explanation: it is important to provide a pointer for analysts of the protocol (especially due to the many subtleties surrounding this design), and for those that may need to update/change the protocol in the future. (And for this purpose a ps/pdf document seems more useful than a ascii based rfc.) Hopefully my LAST set of comments before the closing of this WG (am I being too optimistic?) Hugo From owner-ipsec@lists.tislabs.com Tue Apr 29 17:43:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U0hFi2015821; Tue, 29 Apr 2003 17:43:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07332 Tue, 29 Apr 2003 20:11:23 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66CDA@SARATOGA.netscreen.com> From: Gregory Lebovitz To: Michael Choung Shieh , "'ddukes@cisco.com'" , Ravi , ipsec@lists.tislabs.com Subject: RE: Peer liveliness Date: Tue, 29 Apr 2003 17:09:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [WE] won't achieve interoperability unless it's mandated that [IMPLEMENTORS] must > reply INVALID_SPI (in clear or initiate IKE back to the > sender) whenever it > receives bad spi packets. Current IKEv2 draft doesn't > address this issue > (only states you MAY reply a clear notify message). > > IKEv1 vendors has implemented many ways to solve it which leave poor > interoperability. We should just pick a method and clarify > it in IKEv2. > =============== > Michael Shieh > We have been having quite a debate in the ICSA IPsec consortium mail list recently trying to figure out how to handle this in IKEv1 (YES, STILL!!!) Here is what we know for sure of this problem statement: (a) detecting liveness/deadness of peer is a good thing, but does not solve all the failure cases in and of itself (b) the behavior of a recently rebooted device when it receives an encrypted packet for an SPI or IKE-SA not in its SADB MUST be mandated, or else implementations will not interoperate (as is the case in IKEv1, 5 years later). (c) the behavior of a peer that receives a new IKE from a peer that it has an existing IKE-SA with (i.e. the rebooted peer that is trying to initiate a new connection) MUST be mandated, or else implementations will not interoperate (as is the case in IKEv1, 5 years later). Darren Dukes wrote: > I believe INVALID_SPI does what you are looking for. If I receive an > INVALID_SPI notify via an IKE SA I know to delete the SA and > traffic will > bring up a new one. I don't believe this will work, since it assumes that an IKE SA is established. In the scenario, the IKE-SA would have been lost along with the SPI of the CHILD-SA by the rebooted peer. Recommendations to solve the solution: - the empty notify as an aliveness check is a good idea. It accomplishes what the DPD draft did. Keep using this. - do what you can to use empty notify to detect dead peer ASAP. The faster the persisting peer can delete the old SPI and IKE-SA, the better. The best case is for Persisting Peer to detect death and initiate new IKE to rebooted peer before rebooted peer gets packets with old SPI, IKE-SA. - On the Rebooted peer side: If an implementation receives a protected packet from an unkown SPI, - simply relying on sending back an unprotected INVALID_SPI is not a good idea. It is too easy to DoS the persisting peer by simply spoofing the rebooted peer's address. - initiate IKE to the persisting peer. - On the Persisting Peer: - If you get a new IKE request from a peer already in your SADB, respond with the under-attack, 6 message method. This will mitigate the DoS attack. If you get all the way through SA and TS negotiation successfully, you are assured (unless I'm missing something) that this really is your peer, and that he re-initiated because he lost the original IKE-SA. Start using the new IKE-SA and the new CHILD-SA and delete the previous ones after some wait period. Would this proposal explicitly solve things? Gregory. From owner-ipsec@lists.tislabs.com Tue Apr 29 17:43:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U0hSi2015840; Tue, 29 Apr 2003 17:43:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07346 Tue, 29 Apr 2003 20:14:40 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66CDB@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Scott G. Kelly'" , ipsec@lists.tislabs.com Subject: RE: Confirm decision on identity handling. Date: Tue, 29 Apr 2003 17:13:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I can't believe that after so many years, we are still > paralyzed w.r.t. > this topic. What a farce. For the last several weeks, I've been trying > to get several ostensibly mature implementations to interoperate using > certs, and I've not had much success. How sad. > > Scott > Scott, you are not alone. Just ask both the ICSA and VPNC. They are both having a terrible time trying to get to interoperability using Certs. So I'm in agreement; whatever we decide MUST BE EXPLICIT. From owner-ipsec@lists.tislabs.com Tue Apr 29 18:19:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U1JYi2016975; Tue, 29 Apr 2003 18:19:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07579 Tue, 29 Apr 2003 20:49:24 -0400 (EDT) X-Originating-IP: [64.114.95.129] X-Originating-Email: [askrywan@hotmail.com] From: "Andrew Krywaniuk" To: paul.hoffman@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Crypto algorithms for IKEv2 Date: Tue, 29 Apr 2003 12:35:02 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 29 Apr 2003 16:35:02.0400 (UTC) FILETIME=[48510800:01C30E6D] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In regards to draft-hoffman-ipsec-algorithms-00-TEMP.txt, I notice that the UI ciphersuites make no mention of PFS. Are we assuming that this is an implementer decision? Come to think of it, I don't think we ever resolved the issue of what to do when the initiator of a CREATE_CHILD_SA exchange doesn't propose PFS but the responder requires it. This could be accomplished with a NOTIFY_PFS_REQUIRED_ALWAYS or NOTIFY_PFS_REQUIRED_NEXT_SA message. Not that we could really change it now, but did anyone consider the idea of acheiving PFS simply by applying a one-way hash to SKEYSEED_D, either periodically or after every CREATE_CHILD_SA exchange? Sure, there are race conditions, but I think they are easily fixed. Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From owner-ipsec@lists.tislabs.com Tue Apr 29 18:20:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U1KAi2017004; Tue, 29 Apr 2003 18:20:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07520 Tue, 29 Apr 2003 20:44:45 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66CDC@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'jknowles@SonicWALL.com'" , paul.hoffman@vpnc.org, scott@airespace.com, ipsec@lists.tislabs.com Subject: RE: Confirm decision on identity handling. Date: Tue, 29 Apr 2003 17:43:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ==Attempted summary of thread to date: - Paul proposed final text. - Gregory thought it was a bit too loose for interop, and proposed text with same intent, just more explicit (or at least I tried to). This text made it clear that interoperability bar is satisfied when when ID payload is used with certs and no connection is made between the two. It allowed for other use cases, but these would be implementation specific, and (honestly) are not guaranteed to interoperate. - Scott asserts that in order to guarantee interoperability, as a responder I will need to have the ability to ignore the ID payload and parse the cert instead for policy lookup, so why not simply treat the cert as the ID in this case, and not add superfluous ID payloads which someone may or may not ignore? Scott wants it as cut and dry as possible, for the sake of interop. - Jim K. would like the option to be able to use ID payload for policy lookup, and cert contents for credentials. - we need something for policy lookup when the cert is not included in the exchange, but are used. ID payload is a way to do this. == In order to finalize something, I would like to re-assert my proposed text and ask for either replacement text or to ratify this text: Goals of text: > - the base interoperable way is DO NOT CHECK ID matches cert. This is the only guaranteed interoperable way. > - implementations MUST be able to handle IDs that do not > match cert contents > - implementations MAY be configured to match. > - Matching will only interoperate if both sides support the > feature and have matching turned on. (ie, we may not get good interop here) > > Proposed Text: > The Identification Payload, denoted ID in this memo, allows peers to > assert an identify to one another. The receiver will > interpret the identity > payload as a unique identity string for policy lookup in its SPD. > Implementations MUST NOT mandate a check that the ID match > anything in the > certificate presented, and therefore MUST be able to accept > the case where > the identity presented does NOT match the certificate contents. > > To allow for more stringent local security policy, > implementations MAY offer > a configuration option to check that the idenity presented in > the identity > payload matches the equivalent identity type in the presented > certificate. > In such a case, interoperability will only be achieved by two > consenting > parties who both have such configuration options available on their > respective gateways and who both enable the option. Gregory. From owner-ipsec@lists.tislabs.com Tue Apr 29 19:57:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U2vNi2019687; Tue, 29 Apr 2003 19:57:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA07913 Tue, 29 Apr 2003 22:12:38 -0400 (EDT) Message-Id: <200304300217.h3U2HQEd019356@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Requirements for IKEv2 implementations In-reply-to: Your message of "Tue, 29 Apr 2003 16:20:27 PDT." <541402FFDC56DA499E7E13329ABFEA87E66CD7@SARATOGA.netscreen.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Apr 2003 22:17:25 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Gregory" == Gregory Lebovitz writes: Gregory> PKI vendors. They have abandoned the application as a focus for their Gregory> development, marketing and sales. At an absolute minimum, PSS is Gregory> a MUST. Why can't we make self-signed PKIX certificates a MUST? {This is a compromise for me. I prefer to make raw RSA keys a MUST} (sure, you can use a CA if you want, but that's not the interop-MUST) Why do we have to be dependant upon the PKI vendors? At least they have begun to honest about dropping the ball on this. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPq8yM4qHRg3pndX9AQFbAAP/WkWMQYRg5b0oO8OoOfWk0j9Hf1Ow3N0N ICgndaPonZLPdUaOxTb/46d+aANqLsMON90dXWHU4UpBFMeT6DEJAI2SlGSxP6PR 6nPIopFtWVrLp2VhhlVDKYoX9DICBXxibpmY3CsyV00guVji2ABziJCcbaHpGuI1 X+RjD/xZI9k= =TazX -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Apr 30 10:22:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UHM5i2086362; Wed, 30 Apr 2003 10:22:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09890 Wed, 30 Apr 2003 12:27:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200304300217.h3U2HQEd019356@marajade.sandelman.ottawa.on.ca> References: <200304300217.h3U2HQEd019356@marajade.sandelman.ottawa.on.ca> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 29 Apr 2003 21:00:21 -0700 To: Michael Richardson , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Requirements for IKEv2 implementations Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:17 PM -0400 4/29/03, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >>>>>> "Gregory" == Gregory Lebovitz writes: > Gregory> PKI vendors. They have abandoned the application as a >focus for their > Gregory> development, marketing and sales. At an absolute minimum, PSS is > Gregory> a MUST. > > Why can't we make self-signed PKIX certificates a MUST? Because we are only supposed to be discussing things that have already been agreed to in the WG. You have brought this up many times and gotten virtually no support for it. Nothing in IKEv2 prohibits it, but there was not enough support to make it even a SHOULD, much less a MUST. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Apr 30 10:22:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UHM5i2086363; Wed, 30 Apr 2003 10:22:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09916 Wed, 30 Apr 2003 12:39:42 -0400 (EDT) Message-ID: <3EAFFCE6.1BB90EFC@airespace.com> Date: Wed, 30 Apr 2003 09:42:14 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Gregory Lebovitz CC: "'jknowles@SonicWALL.com'" , paul.hoffman@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66CDC@SARATOGA.netscreen.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2003 16:44:11.0302 (UTC) FILETIME=[B9E69460:01C30F37] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Gregory, Thanks for summarizing and trying to bring this to a close. I still have some trepidation about the proposed text. I think we need to question our underlying assumptions and I think problems arise from considering all auth scenarios to be equivalent, and attempting to squeeze them into a framework together in which the fit isn't quite right - square and round pegs, round holes. What is the purpose of the ID payload, and how is it used? There are two overarching cases: preshared keys, and public/private keys. In the case of preshared keys, the ID payload serves as a signal from the initiator to the responder as to which psk the initiator (and therefore the responder) will use. Note that this is not the same as a policy selector, but functions similarly: wrong id payload implies selection of wrong psk, resulting in authentication failure. For non-interactive interoperability (e.g. no special config on the initiator side), the IP address is used. Other cases require explicit configuration of the initiator (key id, fqdn) in order to work. In the case of public keys, the ID payload *may* indicate which public key to use (assuming these keys are used without certs), but this has never been clearly specified. When certs are used, the ID payload *may* indicate which cert to choose, but only if the cert is not included in the exchange - otherwise, the ID payload is superfluous. And the currently defined ID payloads _don't uniquely define a cert_. A given DN or GN may appear in certs from multiple issuers. The only way to uniquely identify a cert is with explicit issuer identifying information (issuer name, verification key, serial number, etc), but these are not currently supported. So the ID payload is only a reliable policy selector with interactive pre-configuration of the initiator, in which it is explicitly told which ID to send, when the cert accompanies the ID in the exchange, and when the intiator is trusted to do the right thing. And what is the point of this? It seems to make the policy lookup slightly simpler, since you can get the ID payload from the packet instead of parsing the cert. But this is only on the front end, because you still have to parse the cert, and you have the added step of verifying that the ID matches something in the cert (if you care about security). What threat does the first approach mitigate better than the second? If I'm attacking, I can put an acceptable ID payload in the packet, and then you'll sill have to parse the cert to find out I lied - this is *more* work whether under attack or not. I think the bottom line is that some vendors have come up with proprietary ways to use the ID payload in their responder-side processing. These methods make assumptions about the implementation at the other end, and so long as these assumptions are correct (i.e. it is the vendors own implementation at the other end), this works fine - but it is not interoperable, and I think it actually incurs some additional DoS risk. I don't see the point in standardizing on non-interoperable functionality. It seems like a contradiction in terms. Scott Gregory Lebovitz wrote: > > ==Attempted summary of thread to date: > - Paul proposed final text. > > - Gregory thought it was a bit too loose for interop, and proposed text with > same intent, just more explicit (or at least I tried to). This text made it > clear that interoperability bar is satisfied when when ID payload is used > with certs and no connection is made between the two. It allowed for other > use cases, but these would be implementation specific, and (honestly) are > not guaranteed to interoperate. > > - Scott asserts that in order to guarantee interoperability, as a > responder I will need to have the ability to ignore the ID payload and > parse the cert instead for policy lookup, so why not simply treat the cert > as the ID in this case, and not add superfluous ID payloads which someone > may or may not ignore? Scott wants it as cut and dry as possible, for the > sake of interop. > > - Jim K. would like the option to be able to use ID payload for policy > lookup, and cert contents for credentials. > > - we need something for policy lookup when the cert is not included in the > exchange, but are used. ID payload is a way to do this. > > == In order to finalize something, I would like to re-assert my proposed > text and ask for either replacement text or to ratify this text: > > Goals of text: > > - the base interoperable way is DO NOT CHECK ID matches cert. This is the > only guaranteed interoperable way. > > - implementations MUST be able to handle IDs that do not > > match cert contents > > - implementations MAY be configured to match. > > - Matching will only interoperate if both sides support the > > feature and have matching turned on. (ie, we may not get good interop > here) > > > > Proposed Text: > > The Identification Payload, denoted ID in this memo, allows peers to > > assert an identify to one another. The receiver will > > interpret the identity > > payload as a unique identity string for policy lookup in its SPD. > > Implementations MUST NOT mandate a check that the ID match > > anything in the > > certificate presented, and therefore MUST be able to accept > > the case where > > the identity presented does NOT match the certificate contents. > > > > To allow for more stringent local security policy, > > implementations MAY offer > > a configuration option to check that the idenity presented in > > the identity > > payload matches the equivalent identity type in the presented > > certificate. > > In such a case, interoperability will only be achieved by two > > consenting > > parties who both have such configuration options available on their > > respective gateways and who both enable the option. > > Gregory. From owner-ipsec@lists.tislabs.com Wed Apr 30 11:19:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UIJbi2090129; Wed, 30 Apr 2003 11:19:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10154 Wed, 30 Apr 2003 13:44:35 -0400 (EDT) Message-ID: <3EB00CC9.333D63EF@enst.fr> Date: Wed, 30 Apr 2003 19:50:01 +0200 From: Ibrahim X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: ISAKMP and SSL Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, When I read RFC 2408 they described ISAKMP as a generic key management protocol for all security protocols but till now the large deployment of ISAKMP was only with IPSEC My question is, can we use it with SSL/TLS? The goal of this issue is to add new services in SSL/TLS (identity protection, attribute certificate passing for access control schemes, non-repudiation…). Thank you in advance Ibrahim -- ____________________________________________________ Ibrahim HAJJEH Ecole Nationale Supérieure des Télécommunications Departement Informatique et Réseaux Tél.:+33 01 45 81 71 06 Fax.: +33 01 45 81 31 19 46 rue Barrault, 75634 PARIS cedex 13 From owner-ipsec@lists.tislabs.com Wed Apr 30 14:02:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UL2fi2095192; Wed, 30 Apr 2003 14:02:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10549 Wed, 30 Apr 2003 16:12:53 -0400 (EDT) Message-Id: <5.2.0.9.2.20030430161520.034b0a28@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 30 Apr 2003 16:17:47 -0400 To: Gregory Lebovitz , "'Paul Hoffman / VPNC'" , ipsec@lists.tislabs.com From: Russ Housley Subject: RE: Requirements for IKEv2 implementations In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87E66CD7@SARATOGA.netscreen. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greg: I question the PSS as the mandatory to implement. While I am for an advocate for this algorithm, I do not think that it is widely deployed today. I think that RSA PKCS#1 v1.5 is a more appropriate signature algorithm for MUST. RSA PSS is the up and coming signature algorithm, and as such I think that SHOULD is the way to go. Russ At 04:20 PM 4/29/2003 -0700, Gregory Lebovitz wrote: >...Interesting silence to this post... > >MY WG and Security Area member perspective: >Certificates are good security and we should try as much as we can to help >implementations adopt them. Any worthwhile IKEv1 implementation today can >handle certs. IKEv2 should be no different. > >My NetScreen employee perspective: >Our implementations do both today, so its no big deal if certs are required. > >Market observer perspective: >PKI has been a royal pain for many interested in IPsec VPNs. Just ask the >PKI vendors. They have abandoned the application as a focus for their >development, marketing and sales. At an absolute minimum, PSS is a MUST. > >Gregory. > > > -----Original Message----- > > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > > Sent: Saturday, April 26, 2003 4:21 PM > > To: ipsec@lists.tislabs.com > > Subject: Requirements for IKEv2 implementations > > > > > > Greetings again. The -05 draft of IKEv2 introduced the > > following requirements: > > > > For an implementation to be called conforming to this > > specification, > > it MUST be possible to configure it to accept the following: > > > > PKIX Certificates containing and signed by RSA keys of > > size 1024 or > > 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, > > ID_RFC822_ADDR, or ID_DER_ASN1_DN. > > > > Shared key authentication where the ID passes is any of ID_KEY_ID, > > ID_FQDN, or ID_RFC822_ADDR. > > > > Authentication where the responder authenticates using PKIX > > Certificates and the initiator authenticates using shared key > > authentication. > > > > I don't remember seeing this discussed in the WG before now. > > > > There are many reasons why an implementation might not want to > > support PKIX certificates, including the fact that many vendors find > > that PKIX is too complicated to support securely. In some security > > environments, other forms of public key infrastructures are more > > appropriate for some security uses. And, of course, for systems that > > have the ability to create and distribute good shared secrets, PKIX > > support is just dangerous bloat. > > > > The minimum that is needed for interoperability is shared secrets. > > The document already has requirements for handling large shared > > secrets, so we don't need to worry about limitations that reduce to > > passwords. Requiring both shared secrets *and* PKIX-specific public > > key support does not help interoperability, and because of the nature > > of PKIX, hurts it significantly. We only need to mandate one or the > > other, and given the ugly reality of PKIX, it should only be > > sufficiently long shared secrets. > > > > --Paul Hoffman, Director > > --VPN Consortium > > From owner-ipsec@lists.tislabs.com Wed Apr 30 14:08:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UL8ei2095372; Wed, 30 Apr 2003 14:08:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10643 Wed, 30 Apr 2003 16:33:49 -0400 (EDT) From: jknowles@SonicWALL.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Confirm decision on identity handling. Date: Wed, 30 Apr 2003 13:38:45 -0700 Message-ID: <385918F84B55DC4E9542E0A4812F413106E29C@us0exb01.us.sonicwall.com> Thread-Topic: Confirm decision on identity handling. Thread-Index: AcMPRn2q5BhsDOHKQDidkrADg9V1VQAADuvA To: , Cc: , X-OriginalArrivalTime: 30 Apr 2003 20:38:46.0193 (UTC) FILETIME=[7F308210:01C30F58] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA10640 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, Gregory, Paul, I also appreciate the effort. Comments inline... > -----Original Message----- > From: Scott G. Kelly [mailto:scott@airespace.com] > Sent: Wednesday, April 30, 2003 9:42 AM > To: Gregory Lebovitz > Cc: Jim Knowles; paul.hoffman@vpnc.org; ipsec@lists.tislabs.com > Subject: Re: Confirm decision on identity handling. > > > Hi Gregory, > > Thanks for summarizing and trying to bring this to a close. < snip> > I think the bottom line is that some vendors have come up with > proprietary ways to use the ID payload in their responder-side > processing. Using the ID to look up policy (which is what I've asked for) is not proprietary. At least, that's my interpretation of section 4.6.2 of RFC 2407. What's proprietary is the mapping of ID-to-cert and that's because we never clearly defined the mapping. I agree that this causes interoperability pain. < snip > > > > Implementations MUST NOT mandate a check that the ID match > > > anything in the certificate presented I interpret "MUST NOT mandate" to mean that we can never require such a check. > > To allow for more stringent local security policy, > > implementations MAY offer > > a configuration option to check that the idenity presented in > > the identity > > payload matches the equivalent identity type in the presented > > certificate. Seems to contradict "MUST NOT mandate". >From Gregory's "Goals of text": > > - implementations MUST be able to handle IDs that do not > > match cert contents > > - implementations MAY be configured to match. > > - Matching will only interoperate if both sides support the > > feature and have matching turned on. (ie, we may not get good interop This seems like more consistent text. Maybe just replacing "Implementations MUST NOT mandate..." with the "implementations MUST be able to handle..." line would be better. But, it might be better to just state flatly that there is no IKEv2-defined relationship between the ID payload and any CERT payload. This doesn't answer Scott's request to ban the ID payload when a cert payload is present. Could we add a new ID type of "ID_CERT" to support the opportunistic scenario? "The ID_CERT type specifies that an identity present in the certificate sent in the CERT payload SHOULD be used in place of an explicit ID payload." Then we could say there is no other IKEv2-defined relationship between ID and CERT and that implementations MAY define such relationships locally at their own extreme interoperable peril. Regards, Jim From owner-ipsec@lists.tislabs.com Wed Apr 30 14:12:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULCai2095615; Wed, 30 Apr 2003 14:12:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10631 Wed, 30 Apr 2003 16:28:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <16046.45969.345514.100016@pkoning.dev.equallogic.com> References: <200304291515.h3TFFJmk003576@marajade.sandelman.ottawa.on.ca> <16046.45969.345514.100016@pkoning.dev.equallogic.com> Date: Wed, 30 Apr 2003 14:23:27 -0400 To: Paul Koning , mcr@sandelman.ottawa.on.ca From: Stephen Kent Subject: Re: Crypto algorithms for IKEv2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:17 PM -0400 4/29/03, Paul Koning wrote: > >>>>> "Michael" == Michael Richardson writes: > > Michael> Editorial comments/questions: > > Michael> Where are the ENCR_DES_IV32 and ENCR_RC4 defined? > Michael> RFC2401bis? > >Nowhere, I believe. > >ENCR_RC4 is clearly nonsense -- IPsec cannot work with stream ciphers >because IPsec works with IP datagrams. Stream ciphers like RC4 >require loss-free delivery, which IP does not offer. So ENCR_RC4 is >simply a mistake that was never corrected. > > paul I agree with the conclusion, but not the rationale. One could use a stream cipher with IPsec, so long as one carries the state info needed for the cipher with each packet, just like we carry an IV. Steve From owner-ipsec@lists.tislabs.com Wed Apr 30 14:17:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULH8i2095758; Wed, 30 Apr 2003 14:17:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10685 Wed, 30 Apr 2003 16:45:56 -0400 (EDT) Message-ID: <3EB0369C.59568FDC@airespace.com> Date: Wed, 30 Apr 2003 13:48:28 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: jknowles@SonicWALL.com CC: Gregory@netscreen.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <385918F84B55DC4E9542E0A4812F413106E29C@us0exb01.us.sonicwall.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2003 20:50:26.0150 (UTC) FILETIME=[20657860:01C30F5A] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Jim, I trimmed most of this in order to focus on one point: jknowles@SonicWALL.com wrote: > > Then we could say there is no other IKEv2-defined relationship > between ID and CERT and that implementations MAY define such > relationships locally at their own extreme interoperable peril. I must be missing something really obvious here. If we don't assume anything about the initiator (e.g. that it can be trusted to put an "appropriate" policy selector in the ID payload), then I think there must be security issues with blindly using whatever is passed as a policy selector, with no defined verification mechanism. As an aside, exactly what does your client put into the ID payload? It still sounds to me like we're trying to standardize proprietary behavior here. What am I missing? Scott From owner-ipsec@lists.tislabs.com Wed Apr 30 14:21:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULL3i2095887; Wed, 30 Apr 2003 14:21:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10712 Wed, 30 Apr 2003 16:49:31 -0400 (EDT) Message-Id: <5.2.0.9.2.20030430165021.0332ed28@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 30 Apr 2003 16:54:20 -0400 To: Gregory@netscreen.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com From: Russ Housley Subject: RE: Requirements for IKEv2 implementations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ooops. So much of the message was about certificates, that was the context under which I expanded the PSS acronym. Upon further reflection, it is obvious that Greg was not talking about a signature algorithm. By PSS, Greg meant "pre-shared secret." Sorry for the noise ... Russ >Date: Wed, 30 Apr 2003 16:17:47 -0400 >To: Gregory Lebovitz , "'Paul Hoffman / VPNC'" >, ipsec@lists.tislabs.com >From: Russ Housley >Subject: RE: Requirements for IKEv2 implementations > >Greg: > >I question the PSS as the mandatory to implement. While I am for an >advocate for this algorithm, I do not think that it is widely deployed >today. I think that RSA PKCS#1 v1.5 is a more appropriate signature >algorithm for MUST. RSA PSS is the up and coming signature algorithm, and >as such I think that SHOULD is the way to go. > >Russ > >At 04:20 PM 4/29/2003 -0700, Gregory Lebovitz wrote: >>...Interesting silence to this post... >> >>MY WG and Security Area member perspective: >>Certificates are good security and we should try as much as we can to help >>implementations adopt them. Any worthwhile IKEv1 implementation today can >>handle certs. IKEv2 should be no different. >> >>My NetScreen employee perspective: >>Our implementations do both today, so its no big deal if certs are required. >> >>Market observer perspective: >>PKI has been a royal pain for many interested in IPsec VPNs. Just ask the >>PKI vendors. They have abandoned the application as a focus for their >>development, marketing and sales. At an absolute minimum, PSS is a MUST. >> >>Gregory. >> >> > -----Original Message----- >> > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] >> > Sent: Saturday, April 26, 2003 4:21 PM >> > To: ipsec@lists.tislabs.com >> > Subject: Requirements for IKEv2 implementations >> > >> > >> > Greetings again. The -05 draft of IKEv2 introduced the >> > following requirements: >> > >> > For an implementation to be called conforming to this >> > specification, >> > it MUST be possible to configure it to accept the following: >> > >> > PKIX Certificates containing and signed by RSA keys of >> > size 1024 or >> > 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, >> > ID_RFC822_ADDR, or ID_DER_ASN1_DN. >> > >> > Shared key authentication where the ID passes is any of ID_KEY_ID, >> > ID_FQDN, or ID_RFC822_ADDR. >> > >> > Authentication where the responder authenticates using PKIX >> > Certificates and the initiator authenticates using shared key >> > authentication. >> > >> > I don't remember seeing this discussed in the WG before now. >> > >> > There are many reasons why an implementation might not want to >> > support PKIX certificates, including the fact that many vendors find >> > that PKIX is too complicated to support securely. In some security >> > environments, other forms of public key infrastructures are more >> > appropriate for some security uses. And, of course, for systems that >> > have the ability to create and distribute good shared secrets, PKIX >> > support is just dangerous bloat. >> > >> > The minimum that is needed for interoperability is shared secrets. >> > The document already has requirements for handling large shared >> > secrets, so we don't need to worry about limitations that reduce to >> > passwords. Requiring both shared secrets *and* PKIX-specific public >> > key support does not help interoperability, and because of the nature >> > of PKIX, hurts it significantly. We only need to mandate one or the >> > other, and given the ugly reality of PKIX, it should only be >> > sufficiently long shared secrets. >> > >> > --Paul Hoffman, Director >> > --VPN Consortium >> > From owner-ipsec@lists.tislabs.com Wed Apr 30 14:28:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULSqi2096106; Wed, 30 Apr 2003 14:28:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10718 Wed, 30 Apr 2003 16:50:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16048.14327.159144.72042@pkoning.dev.equallogic.com> Date: Wed, 30 Apr 2003 16:54:15 -0400 From: Paul Koning To: kent@bbn.com Cc: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com Subject: Re: Crypto algorithms for IKEv2 References: <200304291515.h3TFFJmk003576@marajade.sandelman.ottawa.on.ca> <16046.45969.345514.100016@pkoning.dev.equallogic.com> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Stephen" == Stephen Kent writes: Stephen> At 1:17 PM -0400 4/29/03, Paul Koning wrote: >> >>>>> "Michael" == Michael Richardson >> writes: >> Michael> Editorial comments/questions: >> Michael> Where are the ENCR_DES_IV32 and ENCR_RC4 defined? Michael> RFC2401bis? >> Nowhere, I believe. >> >> ENCR_RC4 is clearly nonsense -- IPsec cannot work with stream >> ciphers because IPsec works with IP datagrams. Stream ciphers >> like RC4 require loss-free delivery, which IP does not offer. So >> ENCR_RC4 is simply a mistake that was never corrected. >> >> paul Stephen> I agree with the conclusion, but not the rationale. One Stephen> could use a stream cipher with IPsec, so long as one carries Stephen> the state info needed for the cipher with each packet, just Stephen> like we carry an IV. I suppose that is true, though handling out of order packets would be extremely painful. In any case, there is no "how to use RC4 with IPsec" RFC, and I suggest that no one should contemplate writing one. paul From owner-ipsec@lists.tislabs.com Wed Apr 30 14:49:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULn4i2096780; Wed, 30 Apr 2003 14:49:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10853 Wed, 30 Apr 2003 17:12:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <5.1.0.14.0.20030429090406.00a2fec0@172.16.1.10> References: <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> <5.1.0.14.0.20030429090406.00a2fec0@172.16.1.10> Date: Wed, 30 Apr 2003 17:14:18 -0400 To: Jyothi From: Stephen Kent Subject: Re: Question on inbound IPSEC policy check Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:58 AM +0530 4/29/03, Jyothi wrote: >Hi, > >Office1Network-----SG1---------Internet------------SG2-------Office2Network. > >SG1 contains the 2 IPSEC policies: > 1. protocol TCP and port 80 > 2. protocol ANY > >SG2 contains the one IPSEC policy of protocol ANY. > >Office2Network starts the IKE negotiation for protocol ANY, after >the negotiation SG2 will send the HTTP traffic with SAs created. > >In IKE negotiation, we are informing the allowable traffic as protocol ANY. > In this case, HTTP is part of protocol ANY. > >So, if SG1 rejects inbound traffic coming from SG2, then how SG2 knows?? > >Thanks >Jyothi I don't understand all of the assumptions underlying your example. Note that SPD entries are directional, and thus must be separately defined for inbound and outbound traffic flows. So, please restate your example in those terms, and let's see if there is a problem. Ramana's message indicated why this might not be a problem, but until you state the full set of assumptions about the SPDs at each end, I don't know how to interpret the example. Steve From owner-ipsec@lists.tislabs.com Wed Apr 30 15:06:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UM6Ri2097226; Wed, 30 Apr 2003 15:06:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11017 Wed, 30 Apr 2003 17:39:07 -0400 (EDT) To: Ibrahim Cc: ipsec@lists.tislabs.com Subject: Re: ISAKMP and SSL References: <3EB00CC9.333D63EF@enst.fr> Reply-To: EKR From: Eric Rescorla Date: 30 Apr 2003 14:49:24 -0700 In-Reply-To: <3EB00CC9.333D63EF@enst.fr> Message-ID: Lines: 39 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > When I read RFC 2408 they described ISAKMP as a generic key management > protocol for all security protocols but till now the large deployment of > ISAKMP was only with IPSEC > My question is, can we use it with SSL/TLS? > The goal of this issue is to add new services in SSL/TLS (identity > protection, attribute certificate passing for access control schemes, > non-repudiation…). The basic answer here is no. TLS has its own key management scheme and really isn't designed to have pluggable key management. That said, with respect to your specific desired security services: (1) You can get identity protection for TLS in a number of ways, none quite as good as you would get with IPsec. (a) do an initial anonymous DH exchange and then do the ordinary handshake. This still allows an active attacker to get both identities. (b) do an initial cert-based exchange (this exposes the server's identity) and then rehandshake to have the client identify. (c) combine the above two techniques :) (2) TLS has an extensions mechanism so you could use that to pass around attribute certificates. (3) ISAKMP doesn't really offer non-repudiation either, so you wouldn't get any benefit from melding it with TLS. -Ekr -- [Eric Rescorla ekr@rtfm.com] Web Log: http://www.rtfm.com/movabletype From owner-ipsec@lists.tislabs.com Wed Apr 30 15:07:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UM76i2097243; Wed, 30 Apr 2003 15:07:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11042 Wed, 30 Apr 2003 17:41:09 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <3EB00CC9.333D63EF@enst.fr> References: <3EB00CC9.333D63EF@enst.fr> Date: Wed, 30 Apr 2003 17:40:50 -0400 To: Ibrahim , ipsec@lists.tislabs.com From: Stephen Kent Subject: Re: ISAKMP and SSL Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA11039 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:50 PM +0200 4/30/03, Ibrahim wrote: >Hi all, >When I read RFC 2408 they described ISAKMP as a generic key management >protocol for all security protocols but till now the large deployment of >ISAKMP was only with IPSEC >My question is, can we use it with SSL/TLS? >The goal of this issue is to add new services in SSL/TLS (identity >protection, attribute certificate passing for access control schemes, >non-repudiation…). >Thank you in advance >Ibrahim > SSL/TLS has its own, tightly couple key management protocol, so it would not be appropriate to try to use ISAKMP. From owner-ipsec@lists.tislabs.com Wed Apr 30 15:08:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UM8gi2097268; Wed, 30 Apr 2003 15:08:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11033 Wed, 30 Apr 2003 17:40:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <16048.14327.159144.72042@pkoning.dev.equallogic.com> References: <200304291515.h3TFFJmk003576@marajade.sandelman.ottawa.on.ca> <16046.45969.345514.100016@pkoning.dev.equallogic.com> <16048.14327.159144.72042@pkoning.dev.equallogic.com> Date: Wed, 30 Apr 2003 17:44:25 -0400 To: Paul Koning From: Stephen Kent Subject: Re: Crypto algorithms for IKEv2 Cc: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:54 PM -0400 4/30/03, Paul Koning wrote: > >>>>> "Stephen" == Stephen Kent writes: > > Stephen> At 1:17 PM -0400 4/29/03, Paul Koning wrote: > >> >>>>> "Michael" == Michael Richardson > >> writes: > >> > Michael> Editorial comments/questions: > >> > Michael> Where are the ENCR_DES_IV32 and ENCR_RC4 defined? > Michael> RFC2401bis? > >> Nowhere, I believe. > >> > >> ENCR_RC4 is clearly nonsense -- IPsec cannot work with stream > >> ciphers because IPsec works with IP datagrams. Stream ciphers > >> like RC4 require loss-free delivery, which IP does not offer. So > >> ENCR_RC4 is simply a mistake that was never corrected. > >> > >> paul > > Stephen> I agree with the conclusion, but not the rationale. One > Stephen> could use a stream cipher with IPsec, so long as one carries > Stephen> the state info needed for the cipher with each packet, just > Stephen> like we carry an IV. > >I suppose that is true, though handling out of order packets would be >extremely painful. > >In any case, there is no "how to use RC4 with IPsec" RFC, and I >suggest that no one should contemplate writing one. > > paul we are in agreement on that point. From owner-ipsec@lists.tislabs.com Wed Apr 30 15:19:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UMJci2097463; Wed, 30 Apr 2003 15:19:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10989 Wed, 30 Apr 2003 17:35:19 -0400 (EDT) Importance: Normal Subject: Re: Confirm decision on identity handling. To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.6 December 14, 2000 Message-ID: From: David Wierbowski Date: Wed, 30 Apr 2003 17:39:46 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V602_04202003|April 20, 2003) at 04/30/2003 17:39:48 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree. I think it is safer to trust an identify contained within a certificate than it is to trust an identity sent in a payload. If I understand this thread correctly the expectation is that I should make a policy decision based solely on an identify payload and I should use the certificate as a credential only. What ties the identify to the credential? Do I have to now configure a mapping of acceptable policies to identities and a list of credentials that I trust to send me a valid identity payload? I do not understand what interoperability issues result by requiring the identity to be contained within the cert. Isn't the verification of one's identity a reason for using certificates in general? Dave Wierbowski "Scott G. Kelly" @lists.tislabs.com on 04/30/2003 04:48:28 PM Sent by: owner-ipsec@lists.tislabs.com To: jknowles@SonicWALL.com cc: Gregory@netscreen.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. Hi Jim, I trimmed most of this in order to focus on one point: jknowles@SonicWALL.com wrote: > > Then we could say there is no other IKEv2-defined relationship > between ID and CERT and that implementations MAY define such > relationships locally at their own extreme interoperable peril. I must be missing something really obvious here. If we don't assume anything about the initiator (e.g. that it can be trusted to put an "appropriate" policy selector in the ID payload), then I think there must be security issues with blindly using whatever is passed as a policy selector, with no defined verification mechanism. As an aside, exactly what does your client put into the ID payload? It still sounds to me like we're trying to standardize proprietary behavior here. What am I missing? Scott From owner-ipsec@lists.tislabs.com Wed Apr 30 15:49:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UMnFi2098106; Wed, 30 Apr 2003 15:49:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11238 Wed, 30 Apr 2003 18:12:04 -0400 (EDT) Message-Id: <200304302217.h3UMH2RM015453@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-reply-to: Your message of "Wed, 30 Apr 2003 09:42:14 PDT." <3EAFFCE6.1BB90EFC@airespace.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 30 Apr 2003 18:17:01 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Scott, to summarize, your summary: *If* using public keys carried in CERTs AND there is a CERT payload AND the CERT contents are meaningful to the receiver THEN the ID payload is superfluous for the sender. (I avoid initiator/responder here on purpose) ***************** please confirm ************* The problem that I have with this is that sender is making an assumption about the responder. Right now, I can make a system that does not support certificates in the IKE *at all* interoperate with one that does by taking the certificate (which I might get in a CERT payload written to disk or logged), extracting the public key and putting it into my configuration file/into DNS/etc. How do I know this? I do it all the time. That's how one gets RACOON and FreeSWAN to interoperate using RSA public keys. Every night my NetBSD backup server talks to a dozen FreeSWAN boxes to back them up. Did it take configuration? Yes. Of course. I don't know of any VPNs that do not take some configuration. So, my problem with dropping the ID payload is that you are depending upon the sender to know details about the receiver. If you know all of those details, why not just copy the public keys? (Oh, yeah. You told me. Because some products are just broken) So, the situation where all of your conditions hold true is the road warrior case, where access is granted not by configuration, but by permitting any client to connect that has a certificate signed by some CA. I.e. the situation where you can omit the ID payload is one the one where you have intentionally mixed authentication with authorization. So, I'd vote not to do this. I can't say that I'd be happy about the current document if I was payed to care a lot of PKIX. In fact, I'd be fuming. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPrBLXIqHRg3pndX9AQEaLgQAqlqKxI7ICD8z3PXPhi5ciK7vWcnJm38b eb4Czyv0NeHDfdvDnhhAaIQIj7k4ipviZ7BSvx1cVLhlcR07f/aMXyPg/X39HUyy 6uLRMd1UWTaN5WwXLPEWVMyRfjPXlCflF3Ndf28VVUAetwI8g1T0IvuxeaQUehWU dSJSozMrywo= =7Ysx -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Apr 30 16:20:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UNKji2098948; Wed, 30 Apr 2003 16:20:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11527 Wed, 30 Apr 2003 18:48:31 -0400 (EDT) From: jknowles@SonicWALL.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Confirm decision on identity handling. Date: Wed, 30 Apr 2003 15:53:26 -0700 Message-ID: <385918F84B55DC4E9542E0A4812F413106E29D@us0exb01.us.sonicwall.com> Thread-Topic: Confirm decision on identity handling. Thread-Index: AcMPWiF+hCZdwxugRXequ7L4DTBWVQABI49A To: Cc: , , X-OriginalArrivalTime: 30 Apr 2003 22:53:27.0374 (UTC) FILETIME=[4FF2DEE0:01C30F6B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA11524 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, The verification/authentication is the cert. I haven't proposed removing the authentication, so I'm not sure why you say there's no defined verification mechanism. You had earlier proposed omitting the ID payload and just using the cert as policy selector. Which identity in the cert would you use? That's local policy as well. You may authenticate the cert and still reject the identity based on your policy. You've eliminated the requirement for configuring which ID payload to send. That's fine - less headaches although you still need to configure which cert to send. At least there's no ID payload/cert impedence mismatch. But, I don't see any security issue with allowing an ID payload. Our client puts the certificate subjectName or subjectAltName into the ID payload depending on the ID type. The ID type has to be configured. As you know, certain ID types could be in either subjectName or subjectAltName or both. We had to make implementation decisions about which of these to send as ID. We took as much guidance as possible from the RFCs. Some things are rather vague :-). Yeah, this can make inter-vendor configuration more fun than it needs to be. So, I understand your desire to omit the ID payload. Rather than make it optional or ban it, we can explicitly say "ignore me, use the cert" via a new ID type. Since I still see a use for the ID payload, I'd prefer this. Regards, Jim > -----Original Message----- > From: Scott G. Kelly [mailto:scott@airespace.com] > Sent: Wednesday, April 30, 2003 1:48 PM > To: Jim Knowles > Cc: Gregory@netscreen.com; paul.hoffman@vpnc.org; > ipsec@lists.tislabs.com > Subject: Re: Confirm decision on identity handling. > > > Hi Jim, > > I trimmed most of this in order to focus on one point: > > jknowles@SonicWALL.com wrote: > > > > Then we could say there is no other IKEv2-defined relationship > > between ID and CERT and that implementations MAY define such > > relationships locally at their own extreme interoperable peril. > > I must be missing something really obvious here. If we don't assume > anything about the initiator (e.g. that it can be trusted to put an > "appropriate" policy selector in the ID payload), then I think there > must be security issues with blindly using whatever is passed as a > policy selector, with no defined verification mechanism. As an aside, > exactly what does your client put into the ID payload? > > It still sounds to me like we're trying to standardize proprietary > behavior here. What am I missing? > > Scott > From owner-ipsec@lists.tislabs.com Wed Apr 30 16:21:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UNL6i2098968; Wed, 30 Apr 2003 16:21:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11487 Wed, 30 Apr 2003 18:45:38 -0400 (EDT) Message-Id: <5.1.1.5.2.20030430154837.04a592f8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 30 Apr 2003 15:49:23 -0700 To: Stephen Kent From: Mark Baugher Subject: Re: ISAKMP and SSL Cc: Ibrahim , ipsec@lists.tislabs.com In-Reply-To: References: <3EB00CC9.333D63EF@enst.fr> <3EB00CC9.333D63EF@enst.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA11484 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 05:40 PM 4/30/2003 -0400, Stephen Kent wrote: >At 7:50 PM +0200 4/30/03, Ibrahim wrote: >>Hi all, >>When I read RFC 2408 they described ISAKMP as a generic key management >>protocol for all security protocols but till now the large deployment of >>ISAKMP was only with IPSEC >>My question is, can we use it with SSL/TLS? >>The goal of this issue is to add new services in SSL/TLS (identity >>protection, attribute certificate passing for access control schemes, >>non-repudiation…). >>Thank you in advance >>Ibrahim > >SSL/TLS has its own, tightly couple key management protocol, so it would >not be appropriate to try to use ISAKMP. I think the confusion comes from the fact that the ISAKMP RFC says it could be applied to TLS. Mark From owner-ipsec@lists.tislabs.com Wed Apr 30 16:54:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UNsQi2099463; Wed, 30 Apr 2003 16:54:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11688 Wed, 30 Apr 2003 19:18:36 -0400 (EDT) From: jknowles@SonicWALL.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Confirm decision on identity handling. Date: Wed, 30 Apr 2003 16:23:35 -0700 Message-ID: <385918F84B55DC4E9542E0A4812F413106E2A0@us0exb01.us.sonicwall.com> Thread-Topic: Confirm decision on identity handling. Thread-Index: AcMPbdECuOjJoFHyQoqTqYNm8rPgGAAAGgJQ To: , X-OriginalArrivalTime: 30 Apr 2003 23:23:35.0717 (UTC) FILETIME=[85CE1D50:01C30F6F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA11685 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi David, comments inline... > -----Original Message----- > From: David Wierbowski [mailto:wierbows@us.ibm.com] > Sent: Wednesday, April 30, 2003 2:40 PM > To: ipsec@lists.tislabs.com > Subject: Re: Confirm decision on identity handling. > > I agree. I think it is safer to trust an identify contained within a > certificate than it is to trust an identity sent in a payload. The identity payload is authenticated via the cert in the case we were discussing. How is this unsafe? > > If I understand this thread correctly the expectation is that > I should make > a policy decision based solely on an identify payload and I > should use the > certificate as a credential only. What I proposed was that the a new ID payload could explicitly state that the identity is in the cert, so it would not be solely used as a credential. > What ties the identify to the > credential? The auth payload. > Do I have to now configure a mapping of > acceptable policies to > identities and a list of credentials that I trust to send me a valid > identity payload? You may. If you are mapping all credentials that you trust to a single policy, you can ignore the identities. Your choice. In any case, you configure your trust of credentials in some way. > > I do not understand what interoperability issues result by > requiring the > identity to be contained within the cert. None that I can see. Current (v1) interoperability issues are mainly from the ID-to-cert mapping. > Isn't the > verification of one's > identity a reason for using certificates in general? > > Dave Wierbowski Regards, Jim From owner-ipsec@lists.tislabs.com Wed Apr 30 17:47:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h410lLi2000457; Wed, 30 Apr 2003 17:47:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA12014 Wed, 30 Apr 2003 20:15:21 -0400 (EDT) From: "Mark Siler" To: Subject: IPSec Passthrough Date: Wed, 30 Apr 2003 10:07:43 -0500 Message-ID: <1772A2E865ABD411B18900508BB1B88F05ED7D8C@SVARLEXC07> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01C30F00.577C33C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_005E_01C30F00.577C33C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm curious on how IPSec passthrough works. I know AH prevents a traditional NAT from occurring, but how do the SOHO routers (Linksys, D-Link, Ascend, etc) accomplish the IPSec passthrough? Do they encapsulate the entire IPSec packet from the client? I keep reading about a Transparent Mode and Tunnel Mode, but some of the SOHO routers don't offer that option. They offer a check box for turning on and off IPSec Passthrough. Thanks in advance Mark ------=_NextPart_000_005E_01C30F00.577C33C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I m curious on how IPSec passthrough = works. I know AH prevents a traditional NAT from occurring, but how do the = SOHO routers (Linksys, D-Link, Ascend, etc) accomplish the IPSec passthrough? = Do they encapsulate the entire IPSec packet from the client? I keep = reading about a Transparent Mode and Tunnel Mode, but some of the SOHO routers don t offer that option. They offer a check box for turning on and off = IPSec Passthrough. Thanks in advance Mark ------=_NextPart_000_005E_01C30F00.577C33C0-- From owner-ipsec@lists.tislabs.com Wed Apr 30 17:47:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h410lWi2000469; Wed, 30 Apr 2003 17:47:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11993 Wed, 30 Apr 2003 20:13:21 -0400 (EDT) Message-ID: <421CB3B9B2D2F645B548D213C0A90E5501168AF7@edgmsmsg01.eu.thmulti.com> From: Van Aken Dirk To: "'Paul Hoffman / VPNC'" , ipsec@lists.tislabs.com Subject: RE: Crypto algorithms for IKEv2 Date: Wed, 30 Apr 2003 08:18:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30EE0.46770818" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C30EE0.46770818 Content-Type: text/plain; charset="ISO-8859-1" Hi Paul, Looking at section 2.1 of your draft RFC or section 3.3 of the IKE draft, I guess it is now possible to configure IKE with the NULL encryption algorithm isn't it ? I like this capability because I have now a simple means to perform low level troubleshooting with tools such as Ethereal. Wouldn't it be interesting to have a MUST implement or SHOULD implement statement for IKE - NULL encryption ? As such I can rely on this capability as different vendors will implement it and will shorten troubleshooting interoperability issues. Best regards - Dirk 2.1 Transform type 1: encryption algorithms Name Number Defined in RESERVED 0 ENCR_DES_IV64 1 RFC 1827 ENCR_DES 2 RFC 2405 ENCR_3DES 3 RFC 2451 ENCR_RC5 4 RFC 2451 ENCR_IDEA 5 RFC 2451 ENCR_CAST 6 RFC 2451 ENCR_BLOWFISH 7 RFC 2451 ENCR_3IDEA 8 RFC 2451 ENCR_DES_IV32 9 ENCR_RC4 10 ENCR_NULL 11 RFC 2410 ENCR_AES_128_CBC 12 ENCR_AES_128_CTR 13 ------_=_NextPart_001_01C30EE0.46770818 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Crypto algorithms for IKEv2 Hi Paul, Looking at section 2.1 of your draft RFC or section = 3.3 of the IKE draft, I guess it is now possible to configure IKE with = the NULL encryption algorithm isn't it ? I like this capability because I have now a simple = means to perform low level troubleshooting with tools such as = Ethereal. Wouldn't it be interesting to have a MUST implement = or SHOULD implement statement for IKE - NULL encryption ? As such I can rely on this capability as different = vendors will implement it and will shorten troubleshooting = interoperability issues. Best regards - Dirk 2.1 Transform type 1: encryption algorithms Name = ; Number = Defined in RESERVED &= nbsp; 0 ENCR_DES_IV64 = 1 RFC 1827 ENCR_DES &= nbsp; = 2 RFC 2405 ENCR_3DES = 3 = RFC 2451 ENCR_RC5 &= nbsp; = 4 RFC 2451 ENCR_IDEA = 5 = RFC 2451 ENCR_CAST = 6 = RFC 2451 ENCR_BLOWFISH = 7 RFC 2451 ENCR_3IDEA = ; 8 RFC = 2451 ENCR_DES_IV32 = 9 ENCR_RC4 &= nbsp; 10 ENCR_NULL = 11 RFC = 2410 ENCR_AES_128_CBC 12 ENCR_AES_128_CTR 13 ------_=_NextPart_001_01C30EE0.46770818-- From owner-ipsec@lists.tislabs.com Wed Apr 30 17:56:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h410uBi2000603; Wed, 30 Apr 2003 17:56:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11987 Wed, 30 Apr 2003 20:12:21 -0400 (EDT) X-Originating-IP: [64.114.95.129] X-Originating-Email: [askrywan@hotmail.com] From: "Andrew Krywaniuk" To: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. Date: Wed, 30 Apr 2003 19:09:19 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Apr 2003 23:09:19.0754 (UTC) FILETIME=[879C86A0:01C30F6D] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >And what is the point of this? It seems to make the policy lookup >slightly simpler, since you can get the ID payload from the packet >instead of parsing the cert. But this is only on the front end, because >you still have to parse the cert, and you have the added step of >verifying that the ID matches something in the cert (if you care about >security). Some people have been referring to the id as a "key for policy lookup". The idea is that if you have a decorrelated database (or an ordered database where more specific rules serve only to grant privileges and not to take them away), a unique id can allow a very fast policy lookup. However, once this lookup is complete, you can throw the id away. It is not necessary to check the id against a field in the certificate. You only have to check the certificate against the policy (and the signature against the public key and the validity of the cert chain). I wish people would stop saying thing like "you can check the id against the certificate if you require a more stringent policy check." Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-ipsec@lists.tislabs.com Wed Apr 30 17:56:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h410uXi2000616; Wed, 30 Apr 2003 17:56:34 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA12063 Wed, 30 Apr 2003 20:28:28 -0400 (EDT) Message-ID: <3EB06AC3.7440A2A8@airespace.com> Date: Wed, 30 Apr 2003 17:30:59 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: jknowles@SonicWALL.com CC: Gregory@netscreen.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <385918F84B55DC4E9542E0A4812F413106E29D@us0exb01.us.sonicwall.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2003 00:32:57.0698 (UTC) FILETIME=[368A0420:01C30F79] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Jim, Comments inline... jknowles@SonicWALL.com wrote: > > Hi Scott, > > The verification/authentication is the cert. I > haven't proposed removing the authentication, so > I'm not sure why you say there's no defined > verification mechanism. I'm saying this because the proposed language says the ID payload does not have to match anything in the cert. If we allow this and you choose your policy based on the ID payload, I may be able to misdirect you to the "wrong" policy by simply enclosing the "right" ID payload. > You had earlier proposed > omitting the ID payload and just using the cert as > policy selector. Which identity in the cert would > you use? That's local policy as well. This is precisely my point: since it's the responder's decision, and since there are multiple choices and combinations, how can the initiator reliably know what to put in the ID payload? And supposing the responder tells the intiator in advance, what is the responder to do if the ID payload is the "wrong" one? It only works if the responder verifies the ID payload against the credential, and in this case, there is nothing saved by using the separate payload, rather than simply extracting it from the cert. > You may > authenticate the cert and still reject the identity > based on your policy. You've eliminated the > requirement for configuring which ID payload > to send. That's fine - less headaches although > you still need to configure which cert to send. > At least there's no ID payload/cert impedence > mismatch. But, I don't see any security issue > with allowing an ID payload. The security issues arise if you decouple the ID payload from the cert, i.e. when the ID payload is no longer a reliable policy selector. > Our client puts the certificate subjectName or > subjectAltName into the ID payload depending on > the ID type. The ID type has to be configured. > As you know, certain ID types could be in either > subjectName or subjectAltName or both. We had > to make implementation decisions about which of > these to send as ID. We took as much guidance as > possible from the RFCs. Some things are rather > vague :-). ...which is why I *really* want us to get it right this time. > Yeah, this can make inter-vendor > configuration more fun than it needs to be. > So, I understand your desire to omit the ID > payload. Rather than make it optional or ban > it, we can explicitly say "ignore me, use the > cert" via a new ID type. Since I still see > a use for the ID payload, I'd prefer this. It sounds like your client is putting something that can be verified against the cert into the ID payload. So long as you verify this against the cert, this is probably okay, though as I said in an earlier post, there really is no computational benefit to this, and I think it actually may complicate the processing. The main point, though, is that your implementation appears to verify the ID payload against the cert - the proposed language I'm disgreeing with says this is not required. Scott From owner-ipsec@lists.tislabs.com Wed Apr 30 18:30:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h411UVi2001523; Wed, 30 Apr 2003 18:30:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA12253 Wed, 30 Apr 2003 21:04:35 -0400 (EDT) Message-ID: <3EB0733B.80BA8E5B@airespace.com> Date: Wed, 30 Apr 2003 18:07:07 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson CC: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <200304302217.h3UMH2RM015453@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2003 01:09:06.0376 (UTC) FILETIME=[432C0480:01C30F7E] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Michael, Michael Richardson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Scott, to summarize, your summary: > > *If* using public keys carried in CERTs > AND there is a CERT payload > AND the CERT contents are meaningful to the receiver > THEN the ID payload is superfluous for the sender. > > (I avoid initiator/responder here on purpose) > > ***************** please confirm ************* If the cert contents are not meaningful to the receiver, the discussion is moot, is it not? That aside, I think it's a bit more complex than you say, but you might be able to summarize it like this: *If* using public keys carried in CERTs AND there is a CERT payload then only the receiver knows what identifer contained in the cert is acceptable as a policy selector for the receiver *If* using public keys carried in CERTs AND there is a CERT payload AND there is an ID payload AND the receiver uses this ID payload to select a policy THEN the receiver risks choosing the wrong policy, UNLESS it verifies the ID payload against the cert And I might add *If* using public keys carried in CERTs AND there is NOT a CERT payload then any currently defined ID chosen by the sender does not unambiguously define exactly one certificate (or public key) > The problem that I have with this is that sender is making > an assumption about the responder. > > Right now, I can make a system that does not support certificates > in the IKE *at all* interoperate with one that does by taking > the certificate (which I might get in a CERT payload written > to disk or logged), extracting the public key and putting it > into my configuration file/into DNS/etc. > > How do I know this? I do it all the time. That's how one gets > RACOON and FreeSWAN to interoperate using RSA public keys. Every night > my NetBSD backup server talks to a dozen FreeSWAN boxes to back them up. > Did it take configuration? Yes. Of course. I don't know of any VPNs > that do not take some configuration. > > So, my problem with dropping the ID payload is that you are depending upon > the sender to know details about the receiver. If you know all of those > details, why not just copy the public keys? (Oh, yeah. You told me. > Because some products are just broken) See filtering example below... > So, the situation where all of your conditions hold true is the > road warrior case, where access is granted not by configuration, but > by permitting any client to connect that has a certificate signed by > some CA. No, this is not the only case. I may construct a policy filter which looks like this: ISSUER: me DN FILTER: c=*,o=ietf,ou=ipsec-wg,cn=Michael*,* GN FILTER: * In this case, if you know that I require the DN, you can send it, or I can simply extract it from the cert. But what if I want to construct filters using things other than DN and GN? If I use issuerName, there is no ID payload you can send me that makes sense. If I require multiple criteria to be satisfied (e.g. issuer + dn fields + gn fields), there is no way to express this using currently defined IDs - and why should you, as the sender, have to know what to extract from the cert? > I.e. the situation where you can omit the ID payload is one the > one where you have intentionally mixed authentication with authorization. Can't really argue with you there, but I don't see how this can be avoided. > So, I'd vote not to do this. > > I can't say that I'd be happy about the current document if I was payed > to care a lot of PKIX. In fact, I'd be fuming. As I said in my first post on this topic, I think the next best thing is to require that the ID payload, when present, match something in the cert. The text on the table renders this optional. I think that's a mistake. Scott From owner-ipsec@lists.tislabs.com Wed Apr 30 23:47:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h416lVi2018529; Wed, 30 Apr 2003 23:47:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA12954 Thu, 1 May 2003 02:01:02 -0400 (EDT) Subject: Re: IPSec Passthrough From: Vinay K Nallamothu To: Mark Siler Cc: ipsec@lists.tislabs.com In-Reply-To: <1772A2E865ABD411B18900508BB1B88F05ED7D8C@SVARLEXC07> References: <1772A2E865ABD411B18900508BB1B88F05ED7D8C@SVARLEXC07> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 01 May 2003 11:40:03 +0530 Message-Id: <1051769403.1131.40.camel@lima.royalchallenge.com> Mime-Version: 1.0 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 2003-04-30 at 20:37, Mark Siler wrote: > I'm curious on how IPSec passthrough works. I know AH prevents a > traditional NAT from occurring, but how do the SOHO routers (Linksys, > D-Link, Ascend, etc) accomplish the IPSec passthrough? These devices track the IPsec connections by looking at the SPI in IKE/ESP headers. When they first see the IKE packets from the client behind the NAT they note down the SPI value, client address and then masquarade the packet as usual with its own IP. When they see the packets from the remote IPsec peer, it looks into the table using SPI and replaces the destination with client's IP. This mechanism works only with ESP and not with AH which is fine as most of the road warriors connect to IPsec gateways. You can get more details about this in sections 9.0 to 9.3 of draft-ietf-ipsec-ikev2-tutorial-01.txt. > Do they > encapsulate the entire IPSec packet from the client? No > I keep reading > about a Transparent Mode and Tunnel Mode, For NAT-T unware IPsec peers, the above mentioned mechanism is not visible and hence called transparent. Further this works only when the client behind the NAT is a road warrior. vinay From owner-ipsec@lists.tislabs.com Wed Apr 30 23:48:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h416mFi2018661; Wed, 30 Apr 2003 23:48:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA13022 Thu, 1 May 2003 02:15:24 -0400 (EDT) Message-ID: <3EB0C060.30104@cdac.ernet.in> Date: Thu, 01 May 2003 12:06:16 +0530 From: puja User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IPSec iterated tunneling Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all I want to set up a LAN-to-LAN scenerio in which I have a policy between the two edge gateways across the Lan also an end to end security policy between the clients which are behind the gateways. For eg: Client1---Gateway1===================Gateway2-----Client2 Policy between Gateway 1-Gateway 2 AH tunnel mode. Policy between Client 1 - Client 2 ESP transport mode. I am setting the policy at both the gateways: bypass IPSec ESP transport mode between client 1 and client 2. Will this suffice ? What extra functionality/configuration has to be done at the gateways/clients to do this ? Thanks in advance Puja Puri