Re: [Ipsec] Applications over IPsec

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 <kent@bbn.com> wrote:
>
> 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.
>
> 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
>
>
> 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
>