Subject: [IPsec] Pasi's AD comments on roadmap doc - RFCs to add/delete

From: "Frankel, Sheila E." <[email-masked]>
Date: Mon, 8 Mar 2010 13:13:14 -0500

Here are the RFCs that Pasi suggested adding/removing from the roadmap doc. If anyone has any strong opinions either pro or con, now's the time to speak up.

Sheila and Suresh

----------------------------------------------------------------------------

several groups of RFCs that Pasi wants us to remove:

1) RFCs that define how to configure IPsec for use in other protocols, but don't 
   modify/extend how IPsec works (We would prefer to keep these in the roadmap):
	8.1.1.  RFC 4093, Problem Statement: Mobile IPv4 Traversal of Virtual Private 
		Network (VPN) Gateways
	8.1.2.  RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways
	8.1.5.  RFC 5213, Proxy Mobile IPv6
	8.1.6.  RFC 5268, Mobile IPv6 Fast Handovers
	8.1.7.  RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
	8.2.1.  RFC 4552, Authentication/Confidentiality for OSPFv3

2) MIKEY: creates security associations for SRTP, not IPsec -- so it's not really 
   relevant for this document
	6.7.  RFC 3830, MIKEY: Multimedia Internet KEYing
	6.8.  RFC 4738, MIKEY-RSA-R: An Additional Mode of Key Distribution in 
	      Multimedia Internet KEYing (MIKEY)
	6.9.  RFC 5197, On the Applicability of Various Multimedia Internet KEYing 
	      (MIKEY) Modes and Extensions
	6.10.  RFC 4563, The Key ID Information Type for the General Extension Payload 
               in Multimedia Internet KEYing (MIKEY)
	6.12.  RFC 4650, HMAC-Authenticated Diffie-Hellman for Multimedia Internet 
	       KEYing (MIKEY)
	6.13.  RFC 5410, Multimedia Internet KEYing (MIKEY) General Extension Payload 
	       for Open Mobile Alliance BCAST 1.0

3) I'm not sure what 4534/4535 have to do with IPsec; it doesn't look like it supports 
   creating IPsec SAs, for example.
	6.5.  RFC 4535, GSAKMP: Group Secure Association Key Management Protocol
	6.6.  RFC 4534, Group Security Policy Token v1

4) not about IPsec, but non-IPsec approaches to securing multicast; so they don't 
   really belong here.
	6.14.  RFC 4082, Timed Efficient Stream Loss-Tolerant Authentication (TESLA): 
	       Multicast Source Authentication Transform Introduction
	6.15.  RFC 4442, Bootstrapping Timed Efficient Stream Loss-Tolerant 
	       Authentication (TESLA)
	6.16.  RFC 4383, The Use of Timed Efficient Stream Loss-Tolerant Authentication 
	       (TESLA) in the Secure Real-time Transport Protocol

----------------------------------------------------------------------------
RFCs that Pasi suggests adding:
	RFC 2521, ICMP Security Failures Messages (E, Mar 1999)
	RFC 2709, Security Model with Tunnel-mode IPsec for NAT domains (I, Oct 1999)
	RFC 3329, Security Mechanism Agreement for the Session Initiation Protocol 
		  (SIP) (S, Jan 2003)
	RFC 4322, Opportunistic Encryption using the Internet Key Exchange (IKE)
		  (I, Dec 2005)
	RFC 4705, GigaBeam High-Speed Radio Link Encryption (I, Oct 2006)
	RFC 5026, Mobile IPv6 Bootstrapping in Split Scenario (S, Oct 2007)

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Mar 2010 10:34:11 -0800

>Here are the RFCs that Pasi suggested adding/removing from the roadmap doc. If anyone has any strong opinions either pro or con, now's the time to speak up.

I agree with Sheila and Suresh, and disagree with Pasi: these should stay in the roadmap. IPsec implementers should be aware that these other IETF protocols have specific profiles for IPsec.

>	       (TESLA) in the Secure Real-time Transport Protocol

I'm fine with removing all of those.

I agree about adding 3329, 4322, and 5026. The others seem superfluous.

--Paul Hoffman, Director
--VPN Consortium

---

From: <[email-masked]>
Date: Mon, 15 Mar 2010 12:42:40 +0100

Paul Hoffman wrote:

> >1) RFCs that define how to configure IPsec for use in other
> >   protocols, but don't modify/extend how IPsec works (We would prefer
> >   to keep these in the roadmap):
> >
> >	8.1.1.  RFC 4093, Problem Statement: Mobile IPv4 Traversal of
> >             Virtual Private Network (VPN) Gateways
> I agree with Sheila and Suresh, and disagree with Pasi: these should
> stay in the roadmap. IPsec implementers should be aware that these
> other IETF protocols have specific profiles for IPsec.

Well, my question was more about why list *these* particular Mobile IP
protocol features, and not several MIP features, and several other
protocols (Diameter, RADIUS, TGREP, iSCSI, ...) that also have
specific profiles for IPsec?

Best regards,
Pasi