Subject: [OSPF] [Technical Errata Reported] RFC4552 (2599)

From: RFC Errata System <[email-masked]>
Date: Tue, 2 Nov 2010 08:53:16 -0700 (PDT)

The following errata report has been submitted for RFC4552,
"Authentication/Confidentiality for OSPFv3".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4552&eid=2599

--------------------------------------
Type: Technical
Reported by: John W. O'Brien <[email-masked]>

Section: 3

Original Text
-------------
In order to provide authentication to OSPFv3, implementations MUST support ESP and MAY support AH.

Corrected Text
--------------
In order to provide authentication to OSPFv3, implementations MUST support AH and MAY support ESP.

Notes
-----
Authentication can be provided by an implementation that supports AH only.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4552 (draft-ietf-ospf-ospfv3-auth-08)
--------------------------------------
Title               : Authentication/Confidentiality for OSPFv3
Publication Date    : June 2006
Author(s)           : M. Gupta, N. Melam
Category            : PROPOSED STANDARD
Source              : Open Shortest Path First IGP
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 2 Nov 2010 17:05:16 -0700

Hi,

This errata is wrong. ESP provides authentication as well as
confidentiality, have a look at RFC 4301.

Thanks,
Vishwas

On Tue, Nov 2, 2010 at 8:53 AM, RFC Errata System
<[email-masked]> wrote:
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: Acee Lindem <[email-masked]>
Date: Wed, 3 Nov 2010 11:50:04 -0400

Hi Vishwas,
Do you recall the reason for making ESP mandatory and AH optional for OSPFv3 IPsec? 
Thanks,
Acee

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 3 Nov 2010 21:34:31 +0530

Hi Acee,

That's because 4301 requires all Ipsec implementations to MUST support ESP and MAY support AH. 

Cheers, Manav

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Acee Lindem
> Sent: Wednesday, November 03, 2010 9.20 PM
> To: Vishwas Manral
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; RFC Errata System
> Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599)
> 
> Hi Vishwas,
> >> In order to provide authentication to OSPFv3, 
> implementations MUST support ESP and MAY support AH.
> >> 
> >> 
> >> Corrected Text
> >> --------------
> >> In order to provide authentication to OSPFv3, 
> implementations MUST support AH and MAY support ESP.
> >> 
> >> Notes
> >> -----

---

From: Mukesh Gupta <[email-masked]>
Date: Wed, 3 Nov 2010 09:09:24 -0700

Manav is right.  That was mainly the reason behind making ESP a MUST and AH a SHOULD.

Excerpt from section 3.2 of RFC 4301:

   IPsec implementations MUST support ESP and MAY
   support AH. (Support for AH has been downgraded to MAY because
   experience has shown that there are very few contexts in which ESP
   cannot provide the requisite security services.  Note that ESP can be
   used to provide only integrity, without confidentiality, making it
   comparable to AH in most contexts.)

- Mukesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Wednesday, November 03, 2010 9:05 AM
To: Acee Lindem; Vishwas Manral
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Suresh Melam; RFC Errata System
Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599)

Hi Acee,

Cheers, Manav

---

From: "Obrien, John W" <[email-masked]>
Date: Wed, 03 Nov 2010 12:29:44 -0400

[My original reply was rejected by the list. Resent for posterity now that I've subscribed.]

Vishwas,

Thanks for your prompt response.

I do not dispute that ESP provides authentication as well, but I don't believe that fact invalidates this errata. My stated rationale still holds, does it not? If an implementation desires to provide authentication without also providing confidentiality (as is permitted by 4552), AH alone can perform that function. Furthermore, AH authenticates more of the packet than does ESP. What is the rationale, therefore, for attaching the stronger "MUST" to ESP and the weaker "MAY" to AH in Section 3, Authentication?

The errata may be invalid because the authors' intention is to mandate ESP support in all cases, regardless of the line of thought above, which I accept. That would mean that my comment against the specification should be submitted and discussed in a different forum.

Regards,
John

-----Original Message-----
From: Vishwas Manral [mailto:[email-masked]]
Sent: Tuesday, November 02, 2010 8:05 PM
To: RFC Errata System
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Obrien, John W
Subject: EXTERNAL: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599)

Hi,

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 3 Nov 2010 09:30:44 -0700

Hi Acee,

The reason IPsec mandates ESP as for most part ESP is a superset of AH
and the aim is to somehow not have 2 ways to do things when they can
be done with just one protocol.

Thanks,
Vishwas

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 3 Nov 2010 22:17:14 +0530

John,

There are several 4301 compliant implementations that may NOT support AH. If 4552 mandates AH, then many implementations that are Ipsec compliant today will not be able to provide security for OSPF as they may not be supporting AH (and may also not have in their roadmap to support it in the future).

BTW, RFC 5796, which explains how PIM-SM can use Ipsec to secure its packets also has ESP as a MUST and AH as a MAY.

Cheers, Manav

> Behalf Of Obrien, John W
> Sent: Wednesday, November 03, 2010 10.00 PM
> To: [email-masked]
> I do not dispute that ESP provides authentication as well, 
> but I don't believe that fact invalidates this errata. My 
> stated rationale still holds, does it not? If an 
> implementation desires to provide authentication without also 
> providing confidentiality (as is permitted by 4552), AH alone 
> can perform that function. Furthermore, AH authenticates more 
> of the packet than does ESP. What is the rationale, 
> therefore, for attaching the stronger "MUST" to ESP and the 
> weaker "MAY" to AH in Section 3, Authentication?
> 
> The errata may be invalid because the authors' intention is 
> to mandate ESP support in all cases, regardless of the line 
> of thought above, which I accept. That would mean that my 
> comment against the specification should be submitted and 
> discussed in a different forum.
> 
> Regards,
> John
> 
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; Obrien, John W

---

From: "Obrien, John W" <[email-masked]>
Date: Wed, 03 Nov 2010 14:05:48 -0400

Manav,

So it sounds like this is really a question of systems engineering philosophy. As written, 4552 (and 5796, and surely others) duplicates material from 4301 in a manner that exceeds its scope but for arguably good reasons. That is, 4552 covers how to correctly implement IPsec, not just how to correctly apply IPsec to secure OSPFv3.

I can see that there would be a potential benefit to this approach, since an implementation that is compliant to 4552 would necessarily be compliant to 4301. However, I would advocate for cleaner separation between the standards; keeping the items that are concerned with the general implementation of IPsec in 4301, and those that are concerned with specific applications of IPsec in 4552, etc.

Just my $0.02.

In any case, I recognize that my submission is not a valid technical errata and agree that it should be rejected as such.

Regards,
John

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]]
Sent: Wednesday, November 03, 2010 12:47 PM
To: Obrien, John W; [email-masked]
Subject: EXTERNAL: RE: [OSPF] [Technical Errata Reported] RFC4552 (2599)

John,

Cheers, Manav