Vishwas and Tim, I would prefer to require one or the other. This is because a router implementing OSPFv3 MUST provide some means of authenticating messages. The options are:
1. ESP-NULL: ESP without confidentiality and with integrity 2. ESP-ENC: ESP with confidentiality 3. AH: AH with integrity I suggest we require implementations to do one or more. Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. -----Original Message----- From: Vishwas Manral [mailto:[EMAIL PROTECTED] Sent: Thursday, March 06, 2008 1:10 PM To: Tim Enos Cc: Brian E Carpenter; Dunn, Jeffrey H.; [EMAIL PROTECTED]; ipv6@ietf.org Subject: Re: Security Requirements for IPv6 Node Req summary Hi Tim, You may have not read the OSPFv3 security RFC - RFC4552. It states clearly: In order to provide authentication to OSPFv3, implementations MUST support ESP and MAY support AH. Thanks, Vishwas On Thu, Mar 6, 2008 at 9:49 AM, Tim Enos <[EMAIL PROTECTED]> wrote: > I too would be in favor of a SHOULD for the AH requirement, with language dedicated both to a specific example of where AH is arguably a MUST (e.g. for nodes implementing OSPFv3), and other language which at least outlines where AH is and is not applicable. > > Best regards, > > Tim Enos > Ps 84:10-12 > > > > >I also suggest that the AH requirement be SHOULD, or even better MUST, > >for nodes implementing OSPFv3, RFC 2740. This is based on the removal > >of the authentication LSA from OSPFv3, which was done with the > >expectation that AH would be mandatory. Thoughts? > > > >Best Regards, > > > >Jeffrey Dunn > >Info Systems Eng., Lead > >MITRE Corporation. > >-----Original Message----- > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > >Brian E Carpenter > >Sent: Wednesday, March 05, 2008 4:22 PM > >To: [EMAIL PROTECTED] > >Cc: ipv6@ietf.org > >Subject: Re: Security Requirements for IPv6 Node Req summary > > > >If we write a SHOULD we really do need some guidance > >as to when it doesn't apply. Otherwise we make it too > >easy for product managers to simply cross it off the list. > >How about > > > > The normal expectation is that a complete IPv6 stack > > includes an implementation of ESP. However, it is > > recognized that some stacks, implemented for low-end > > devices that will be deployed for special purposes > > where strong security is provided by other protocol > > layers, may omit ESP. > > > >Regards > > Brian Carpenter > > University of Auckland > > > > > >On 2008-03-06 09:14, [EMAIL PROTECTED] wrote: > >> Sorry, that was a cut & paste mistake. AH is a MAY. > >> > >> John > >> > >>> -----Original Message----- > >>> From: ext Vishwas Manral [mailto:[EMAIL PROTECTED] > >>> Sent: 05 March, 2008 12:12 > >>> To: Loughney John (Nokia-OCTO/PaloAlto) > >>> Cc: ipv6@ietf.org > >>> Subject: Re: Security Requirements for IPv6 Node Req summary > >>> > >>> Hi John, > >>> > >>> RFC4301 states AH is optional. Is there a reason why we are > >>> making it a MUST be supported feature. Below quoting RFC4301: > >>> > >>> "IPsec implementations MUST support ESP and MAY > >>> support AH." > >>> > >>> Thanks, > >>> Vishwas > >>> > >>> On Wed, Mar 5, 2008 at 11:46 AM, <[EMAIL PROTECTED]> wrote: > >>>> Hi all, > >>>> > >>>> The RFC 4294-bis draft has the following requirement, which comes > >>>> from the initial RFC. > >>>> > >>>> 8.1. Basic Architecture > >>>> > >>>> Security Architecture for the Internet Protocol [RFC-4301] MUST > >be > >>>> supported. > >>>> > >>>> 8.2. Security Protocols > >>>> > >>>> ESP [RFC-4303] MUST be supported. AH [RFC-4302] MUST be > >>> supported. > >>>> We have had a lot of discussion that people basically feel > >>> that these > >>>> requirements are not applicable and should be moved to SHOULD. I > >>>> would say that there is rough WG Consensus on this. Do > >>> people feel > >>>> if there should be additional text to explain this? > >>>> > >>>> I suggest that the WG Chairs and our ADs discuss this with the > >>>> Security ADs to ensure that this is a reasonable consensus > >>> to adopt > >>>> - so that we do not run into issues during the eventual IETF/IESG > > > >>>> review. I am not sure that we can go much further in > >>> discussions in > >>>> the WG. > >>>> > >>>> Does anyone have comments on this approach? > >>>> > >>>> John > >>>> > >>>> > >-------------------------------------------------------------------- > >>>> IETF IPv6 working group mailing list > >>>> ipv6@ietf.org > >>>> Administrative Requests: > >https://www.ietf.org/mailman/listinfo/ipv6 > >>>> > >-------------------------------------------------------------------- > >>>> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
