Subject: [Ipsec] Applications over IPsec

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 14 Apr 2006 14:50:17 -0700

Hi,

I had pointed out another issue regarding RFC4305. As we have decided to
rehash the RFC I thought we may want to revisit the issue.

The link to an earlier discussion is:
http://www.atm.tut.fi/list-archive/ipsec-2005/msg00755.html

To put the issue more generally, can we have an application which specifies
the use of IPsec but states a different set of MUST and SHOULD from RFC4305.
In a sense contradicting the RFC4305. L2TP for example makes Transport mode
a MUST though IPsec RFC's state that Tunnel mode is a MUST and and Transport
mode is a MAY.

Thanks,
Vishwas
_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Apr 2006 10:52:21 -0400

At 2:50 PM -0700 4/14/06, Vishwas Manral wrote:
>Hi,
>
>I had pointed out another issue regarding RFC4305. As we have 
>decided to rehash the RFC I thought we may want to revisit the issue.
>
><http://www.atm.tut.fi/list-archive/ipsec-2005/msg00755.html>http://www.atm.tut.fi/list-archive/ipsec-2005/msg00755.html
>
>To put the issue more generally, can we have an application which 
>specifies the use of IPsec but states a different set of MUST and 
>SHOULD from RFC4305. In a sense contradicting the RFC4305. L2TP for 
>example makes Transport mode a MUST though IPsec RFC's state that 
>Tunnel mode is a MUST and and Transport mode is a MAY.
>
>Thanks,
>Vishwas

The only relevant (IPsec) RFC re specification of when to support 
each of these modes is RFC 4301. It describes when each of these 
modes MUST be available, depending on the type of device and the way 
IPsec is used. We modified the text from 2401 to address valid, 
additional use cases as discussed in the WG, e.g., use of transport 
mode for overlay nets.

It's generally viewed as OK for a protocol using IPsec to require 
more stringent requirements when it profiles a base standard, but it 
is not OK to remove requirements. That's the general notion of 
"profiling" use of one standard in another. In that sense, 
transforming a MAY into a MUST is just fine. Conversely, transforming 
a MUST into a MAY is not.

Steve

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 17 Apr 2006 18:09:47 -0700

Hi Stephen,

I see issues in drafts using IPsec then:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txtstates
that transport mode is a MUST and Tunnel mode is a MAY. This is more
related to RFC4301 though.

Regarding the algorithms to be supported for ESP and AH(RFC4305), I will add
a clear recommendation for applications to use.

Thanks,
Vishwas

On 4/17/06, Stephen Kent <[email-masked]> wrote:
> specifies the use of IPsec but states a different set of MUST and SHOULD
> from RFC4305. In a sense contradicting the RFC4305. L2TP for example makes
> Transport mode a MUST though IPsec RFC's state that Tunnel mode is a MUST
> and and Transport mode is a MAY.
>
> Thanks,
>
> Vishwas
>
>
> The only relevant (IPsec) RFC re specification of when to support each of
> these modes is RFC 4301. It describes when each of these modes MUST be
> available, depending on the type of device and the way IPsec is used. We
> modified the text from 2401 to address valid, additional use cases as
> discussed in the WG, e.g., use of transport mode for overlay nets.
>
> It's generally viewed as OK for a protocol using IPsec to require more
> stringent requirements when it profiles a base standard, but it is not OK to
> remove requirements. That's the general notion of "profiling" use of one
> standard in another. In that sense, transforming a MAY into a MUST is just
> fine. Conversely, transforming a MUST into a MAY is not.
>
> Steve
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Apr 2006 09:53:21 -0400

At 6:09 PM -0700 4/17/06, Vishwas Manral wrote:
><http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txt>http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txt 
>states that transport mode is a MUST and Tunnel mode is a MAY. This 
>is more related to RFC4301 though.
>
>Regarding the algorithms to be supported for ESP and AH(RFC4305), I 
>will add a clear recommendation for applications to use.
>
>Thanks,
>Vishwas

yes, I am aware of the OSPFv3 security I-D.  The MUST vs. MAY re 
tunnel and transport modes does not bother me.  These folks are 
defining what an OSPF router has to do as a HOST in the routing 
environment, not as a GATEWAY. The same would be tyrue if one 
employed IPsec to protect BGP sessions.

The bigger problem is that OSPF needs multicast support and we don't 
have what they need.  The MSEC WG did not provide the necessary 
extensions to the SPD and SAD to accommodate multicast uses ala OSPF. 
Thus the OSPF folks tried to make do with what was defined, and the 
result is not pretty.

Steve

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 18 Apr 2006 10:11:22 -0700

Hi Stephen,

This is very interesting.

I thought because we got a superset of functionality in the tunnel mode(wrt
transport mode), we were trying to reduce the number of options we wanted to
support in IPsec by mandating support for Tunnel mode as a MUST. But if we
have applications state that Transport mode is a MUST while a Tunnel mode is
a MAY, we may have to be supporting both modes. We do not know what
applications may run on top right?

BTW, the new draft which will obsolete RFC4305 is posted at
http://www.ietf.org/internet-drafts/draft-manral-ipsec-rfc4305-bis-errata-00.txt
and any comments will be very welcome.

Thanks,
Vishwas

On 4/18/06, Stephen Kent <[email-masked]> wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txtstates that transport mode is a MUST and Tunnel mode is a MAY. This is more
> Regarding the algorithms to be supported for ESP and AH(RFC4305), I will
> add a clear recommendation for applications to use.
>
> Thanks,
>
> Vishwas
>
>
>
> yes, I am aware of the OSPFv3 security I-D.  The MUST vs. MAY re tunnel
> and transport modes does not bother me.  These folks are defining what an
> OSPF router has to do as a HOST in the routing environment, not as a
> GATEWAY. The same would be tyrue if one employed IPsec to protect BGP
> sessions.
>
> The bigger problem is that OSPF needs multicast support and we don't have
> what they need.  The MSEC WG did not provide the necessary extensions to the
> SPD and SAD to accommodate multicast uses ala OSPF. Thus the OSPF folks
> tried to make do with what was defined, and the result is not pretty.
>
> Steve
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Apr 2006 15:50:46 -0400

At 10:11 AM -0700 4/18/06, Vishwas Manral wrote:
>I thought because we got a superset of functionality in the tunnel 
>mode(wrt transport mode), we were trying to reduce the number of 
>options we wanted to support in IPsec by mandating support for 
>Tunnel mode as a MUST. But if we have applications state that 
>Transport mode is a MUST while a Tunnel mode is a MAY, we may have 
>to be supporting both modes. We do not know what applications may 
>run on top right?

In the case of OSPv3,. which you cited, the application is very 
specific and thus the argument you make above does not seem to apply.

Mandated support for tunnel vs. transport mode is specific to the 
implementation context and intended use.  Tuunnel mode is not 
mandated in all contexts. It is mandated for gateways wrt subscriber 
traffic. A gateway/router MAY use transport mode for management 
functions in that device, and not support tunnel mode at all if it 
does not offer IPsec for subscribers. A host MUST support transport 
mode, but also MAY support tunnel mode.

Steve

---

From: George Gross <[email-masked]>
Date: Tue, 18 Apr 2006 15:46:17 -0400 (EDT)

Hi Steve,

On Tue, 18 Apr 2006, Stephen Kent wrote:

<snip for brevity>

> Thus the OSPF folks tried to make do with what was defined, and the

I was not aware of the OSPF working group's security requirements.
AFAICT, no one from the OSPF working group ever posted to MSEC to express
those requirements. since MSEC is in the process of composing the MSEC
IPsec extensions draft, what exactly are those missing "necessary
extensions"?

could what OSPF needs from MSEC IPsec be generalized to handle other use
cases?

tia,
	George

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Apr 2006 09:17:18 -0400

>could what OSPF needs from MSEC IPsec be generalized to handle other use

George,

Talk with the MSEC WG chairs. The security ADs made them aware of the 
"missing links" problem several months ago.

Steve

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 20 Apr 2006 10:15:31 -0700

At 06:53 AM 4/18/2006, Stephen Kent wrote:
>extensions to the SPD and SAD to accommodate multicast uses ala 
>OSPF. Thus the OSPF folks tried to make do with what was defined, 
>and the result is not pretty.

As I read through this thread, I will try and respond to the MSEC 
work on IPsec extensions.  There is in fact work underway on Russ's 
request to provide extensions to IPsec to support multicast.  We've 
never received requirements from the OSPF group.  I recall someone 
(Sandy perhaps) making a statement at some point that there is 
interest from the OSPF WG.  I will ping the OSPF chairs today to see what's up.

thanks and regards,
Lakshminath