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

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:manav.bhatia@alcatel-lucent.com]
Sent: Wednesday, November 03, 2010 12:47 PM
To: Obrien, John W; ospf@ietf.org
Subject: EXTERNAL: RE: [OSPF] [Technical Errata Reported] RFC4552 (2599)

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

> -----Original Message-----
> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On
> Behalf Of Obrien, John W
> Sent: Wednesday, November 03, 2010 10.00 PM
> To: ospf@ietf.org
> Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599)
>
> [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:vishwas.ietf@gmail.com]
> Sent: Tuesday, November 02, 2010 8:05 PM
> To: RFC Errata System
> Cc: mukesh.gupta@tropos.com; nmelam@juniper.net;
> stbryant@cisco.com; adrian.farrel@huawei.com;
> acee@redback.com; akr@cisco.com; ospf@ietf.org; Obrien, John W
> Subject: EXTERNAL: Re: [OSPF] [Technical Errata Reported]
> RFC4552 (2599)
>
> 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
> <rfc-editor@rfc-editor.org> wrote:
> >
> > 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 <john.w.obrien@lmco.com>
> >
> > 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
> > _______________________________________________
> > OSPF mailing list
> > OSPF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ospf
> >
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>