Vishwas, Fair enough, I was equating the LSA with the OSPFv2 message that carried the LSA. In the case of cryptographic authentication, the message digest is appended to the message. The point is that there is the provision for computing a message digest over the entire
Actually, I believe that your conclusion is erroneous. RFC 2740 was accepted while RFC 2401 was still in effect. As a result, the assumption was that AH was still required. I believe that the real issue is the following: 1. Simply authenticating the message contents, as in the case of ESP-NULL, does not authenticate the sender. 2. Since ESP-NULL does not provide confidentiality, anyone can view the message contents. 3. As a result, any one can retransmit the message with a different source IPv6 address, any one can masquerade as the original router. 4. Since the Router ID in IPv6 is not the router's IPv6 address but a 32-bit unsigned integer, a spoofed router advertisement with a valid router advertisement is assumed to come from the IPv6 source address 5. Some one can spoof router updates and redirect traffic to themselves If I am incorrect, please correct me. I would prefer to believe that we can dispense with AH and focus on integrity and confidentiality being associated with individual users and not IP addresses. Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. -----Original Message----- From: Vishwas Manral [mailto:[EMAIL PROTECTED] Sent: Thursday, March 06, 2008 2:45 PM To: Dunn, Jeffrey H. Cc: Brian E Carpenter; [EMAIL PROTECTED]; ipv6@ietf.org Subject: Re: Security Requirements for IPv6 Node Req summary Hi Jeff, You are close but still not quite there. OSPFv2 had some fields in all packets (LSA is not a packet but a content in a packet) to send a Hash along with the packet for authetication. It was not used in OSPFv3 because of the assumption that all nodes will support ESP and the packets can anyway be encapsulated in the ESP header. This does not however anyway justify why AH should be made a SHOULD. Thanks, Vishwas On Thu, Mar 6, 2008 at 8:24 AM, Dunn, Jeffrey H. <[EMAIL PROTECTED]> wrote: > 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 --------------------------------------------------------------------
