Subject: Re: Security Requirements for IPv6 Node Req summary

From: Tim Enos <[email-masked]>
Date: Thu, 06 Mar 2008 18:55:32 -0600 (CST)

Mea culpa. I stand corrected on that particular point, and am glad FWIW that RFC 4552 does in fact state:

"In order to provide authentication to OSPFv3, implementations MUST
>   support ESP and MAY support AH."

Couldn't have written it better myself.

Best regards,

Tim Enos
Ps 84:10-12

>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-masked]> 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-masked] [mailto:[email-masked]] On Behalf Of
>>  >Brian E Carpenter
>>  >Sent: Wednesday, March 05, 2008 4:22 PM
>>  >To: [email-masked]
>>  >Cc: [email-masked]
>>  >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-masked] wrote:
>>  >> Sorry, that was a cut & paste mistake. AH is a MAY.
>>  >>
>>  >> John
>>  >>
>>  >>> -----Original Message-----
>>  >>> From: ext Vishwas Manral [mailto:[email-masked]]
>>  >>> Sent: 05 March, 2008 12:12
>>  >>> To: Loughney John (Nokia-OCTO/PaloAlto)
>>  >>> Cc: [email-masked]
>>  >>> 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-masked]> 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-masked]
>>  >>>>  Administrative Requests:
>>  >https://www.ietf.org/mailman/listinfo/ipv6
>>  >>>>
>>  >--------------------------------------------------------------------
>>  >>>>
>>  >> --------------------------------------------------------------------
>>  >> IETF IPv6 working group mailing list
>>  >> [email-masked]
>>  >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>  >> --------------------------------------------------------------------
>>  >>
>>  >--------------------------------------------------------------------
>>  >IETF IPv6 working group mailing list
>>  >[email-masked]
>>  >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>  >--------------------------------------------------------------------
>>  >--------------------------------------------------------------------
>>  >IETF IPv6 working group mailing list
>>  >[email-masked]
>>  >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>  >--------------------------------------------------------------------
>>
>>  --------------------------------------------------------------------
>>  IETF IPv6 working group mailing list
>>  [email-masked]
>>  Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>  --------------------------------------------------------------------
>>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------