Re: [IPsec] Roadmap doc

<Pasi.Eronen@nokia.com> Fri, 24 October 2008 08:48 UTC

Return-Path: <ipsec-bounces@ietf.org>
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C17928B56A; Fri, 24 Oct 2008 01:48:24 -0700 (PDT)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2C053A67D9 for <ipsec@core3.amsl.com>; Fri, 24 Oct 2008 01:48:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.418
X-Spam-Level:
X-Spam-Status: No, score=-6.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgJL3IM2S2wi for <ipsec@core3.amsl.com>; Fri, 24 Oct 2008 01:48:20 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id AF4BF3A6A0E for <IPsec@ietf.org>; Fri, 24 Oct 2008 01:48:19 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9O8nT7n017404; Fri, 24 Oct 2008 11:49:38 +0300
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 11:48:59 +0300
Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 11:48:55 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 24 Oct 2008 11:48:54 +0300
Message-ID: <1696498986EFEC4D9153717DA325CB72020058F0@vaebe104.NOE.Nokia.com>
In-Reply-To: <20081023111335.93181fsvzkllr3q7@webmail.nist.gov>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [IPsec] Roadmap doc
Thread-Index: Ack1If8JUgXJOaK6QAijr3ACgZHeMwAkoVBA
References: <20081023111335.93181fsvzkllr3q7@webmail.nist.gov>
From: Pasi.Eronen@nokia.com
To: sheila.frankel@nist.gov, IPsec@ietf.org
X-OriginalArrivalTime: 24 Oct 2008 08:48:55.0662 (UTC) FILETIME=[591438E0:01C935B5]
X-Nokia-AV: Clean
Subject: Re: [IPsec] Roadmap doc
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

BTW, yesterday IESG approved a similar roadmap document about SIP:

http://tools.ietf.org/html/draft-ietf-sip-hitchhikers-guide

Also, TCPM WG did a roadmap about TCP specs a while ago:

http://tools.ietf.org/html/rfc4614

You might want to take a look at these, and copy some of their
ideas about organizing the document etc.

IMHO we should include the "version 2" IPsec specs (RFC 24xx) since
they're widely used (and perhaps even mention "version 1" IPSec,
RFC 18xx, in a "Historical Documents" appendix or something, even
if just saying "these are for historical interest only").

Best regards,
Pasi

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] 
> On Behalf Of ext Sheila Frankel
> Sent: 23 October, 2008 18:14
> To: IPsec@ietf.org
> Subject: [IPsec] Roadmap doc
> 
> We expect to post a version of the roadmap doc before the 
> Minneapolis  
> IETF. Meanwhile, we wanted to request input from the list on 
> the doc's  
> contents.
> 
> Here is the proposed TOC for the roadmap doc:
> 
> 1.  Introduction
> 2.  IPsec/IKE Background Information
>     2.1.  Interrelationship of IPsec/IKE Documents
>     2.2  Versions of IPsec
>     2.2.1.     Differences between "old" IPsec and "new" IPsec
>     2.3.  Versions of IKE
>     2.3.1.     Differences between IKEv1 and IKEv2
> 3.  IPsec Documents
>     3.1.  Base Documents
>       3.1.1.  "Old" IPsec
>       3.1.2.  "New" IPsec
>     3.2.  Policy
>     3.3.  MIBs
>     3.4.  Additions to IPsec
>     3.5.  General Considerations
> 4.  IKE Documents
>     4.1.  Base Documents
>       4.1.1.  IKEv1 (IKE)
>       4.1.2.  IKEv2
>     4.2.  Additions and Extensions
>       4.2.1.  Peer Authentication Methods
>       4.2.2.  Certificate Contents and Management
>       4.2.3.  Dead Peer Detection
> 5.  Cryptographic Algorithms and Suites
>     5.1.  Encryption Algorithms
>     5.2.  Integrity-Protection (Authentication) Algorithms
>       5.2.1.  General Considerations
>     5.3.  Combined Algorithms
>       5.2.1.  General Considerations
>     5.4.  Pseudo-Random Functions (PRFs)
>     5.5.  Cryptographic Suites
>     5.6.  Diffie-Hellman Algorithms
> 6.  IPsec/IKE for Multicast
> 7.  Outgrowths of IPsec/IKE
>     7.1.  IPComp (Compression)
>     7.2.  IKEv2 Mobility and Multihoming (MobIKE)
>     7.3.  Better-than-Nothing Security (Btns)
>     7.4.  Kerberized Internet Negotiation of Keys (Kink)
>     7.5.  IPsec Secure Remote Access (IPSRA)
>     7.6.  IPsec Keying Information Resource Record (IPsecKEY)
> 8.  Other Protocols that use IPsec/IKE
>     8.1.  Mobile IP (MIPv4 and MIPv6)
>     8.2.  Open Shortest Path First (OSPF)
>     8.3.  Host Identity Protocol (HIP)
>     8.4.  Extensible Authentication Protocol (EAP) Method 
> Update (EMU) 10
>     8.5.  Stream Control Transmission Protocol (SCTP)
>     8.6.  Fibre Channel
> 9.  Security Considerations
> 10.  IANA Considerations
> 11. References
>     11.1. Normative References
>     11.2. Informative References
> 
> Sections 1 and 2 will contain introductory material about IPsec and  
> IKE: their functions, placement in the stack, 
> inter-relationships, etc.
> 
> The rest of the doc will basically be a list of RFCs, with a brief  
> description of each. For the cryptographic algorithms, each section  
> will describe where each type of algorithm is used within 
> IPsec and/or  
> IKE. For each algorithm, the following information will be included:  
> whether it applies to IPsec, IKE, or both; requirement level (MUST  
> etc.); special considerations (e.g. cannot be used with manual  
> keying); how widely/commonly it is deployed. Section 8 (other  
> protocols that use IPsec/IKE) will very briefly mention the 
> context in  
> which each protocol and/or RFC uses IPsec/IKE.
> 
> Questions for the list:
> 1) Are there any other topics that should be discussed?
> 2) Are there other classes of RFCs that should be included?
> 3) The doc currently includes "old" IPsec and IKEv1. Should they be  
> eliminated?
> 
> Sheila and Suresh
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec