I believe that the purpose of this document is to list a minimum set of components that will allow for layer 3/4 interoperation. So yes, that is a baseline specification.
I think that anything beyond that really is better left to vendors and purchasers. Regards Brian Carpenter University of Auckland On 2008-03-07 17:02, Dunn, Jeffrey H. wrote: > Brian, > > Your question points up my entire problem with this document. If we > try to define the lowest common denominator for an IPv6 > Capable/Complaint/Compatible device (note the lack of any real > nomenclature), we risk setting the expectation level at ground. As a > result, I question the need for the document. What problem are we > trying to solve? > > Best Regards, > > Jeffrey Dunn > Info Systems Eng., Lead > MITRE Corporation. > > -----Original Message----- > From: Brian E Carpenter [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 06, 2008 7:16 PM > To: Dunn, Jeffrey H. > Cc: Vishwas Manral; Tim Enos; [EMAIL PROTECTED]; [email protected] > Subject: Re: Security Requirements for IPv6 Node Req summary > > I don't see why this would belong in a generic IPv6 node > requirement. It belongs in the OSPFv3 spec. > > Brian > > On 2008-03-07 08:57, Dunn, Jeffrey H. wrote: >> 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]; >> [email protected] >> 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: [email protected] >>> >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: [email protected] >>> >>> 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 >>> >>>> [email protected] >>> >>>> Administrative Requests: >>> >https://www.ietf.org/mailman/listinfo/ipv6 >>> >>>> >>> >>> -------------------------------------------------------------------- >>> >>>> >>> >> >> -------------------------------------------------------------------- >>> >> IETF IPv6 working group mailing list >>> >> [email protected] >>> >> Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >>> >> >> -------------------------------------------------------------------- >>> >> >>> >>> -------------------------------------------------------------------- >>> >IETF IPv6 working group mailing list >>> >[email protected] >>> >Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >>> -------------------------------------------------------------------- >>> >IETF IPv6 working group mailing list >>> >[email protected] >>> >Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >>> > -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> [email protected] >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
