Hi Acee, On Fri, Oct 3, 2014 at 4:34 PM, Acee Lindem (acee) <[email protected]> wrote:
> Hi Alia, > Thanks for the review. See inline. > > From: Alia Atlas <[email protected]> > Date: Friday, October 3, 2014 at 3:52 PM > To: Ospf Chairs <[email protected]>, " > [email protected]" < > [email protected]>, Vishwas > Manral <[email protected]>, OSPF WG List <[email protected]> > Subject: [OSPF] AD review of > draft-ietf-ospf-security-extension-manual-keying-08 > > As I do with all drafts that are ready to progress, I have done my AD > review of this > draft-ietf-ospf-security-extension-manual-keying-08. In this case, I > apologize for it taking so long. > > The draft is very clear and well-written. I do have a few comments, but > I have sent it to IETF Last Call for review while we discuss. Assuming > that goes smoothly and comments (including mine below) are taken into > account, I expect the draft to go to IESG telechat for Oct 30. > > Major Comment: > > My one concern is that in Section 3, it says: > > "Additionally, the 64-bit sequence number is moved to the first 64-bits > following the OSPFv2 packet and is protected by the authentication > digest." > > but I do not see any other place where RFC 5709 is updated to include > that sequence number. In Sec 3.3, RFC 5709 says: > > First-Hash = H(Ko XOR Ipad || (OSPFv2 Packet)) > > > and I think it would be most excellent for this draft to clearly > > update that to be (OSPFv2 Packet + Sequence Number). > > > With this draft, we attempted to avoid Stephen Farrell’s ire by not > repeating the authentication algorithm as we have done when apply SHAx-HMAC > authentication to each routing protocol. Note that RFC 5709 includes the > statement: > > Implementation Notes: > > Note that the First-Hash above includes the Authentication > Trailer containing the Apad value, as well as the OSPF packet, > as per RFC 2328, Section D.4.3. > > In section 5, we wukk add: > > The 64-bit sequence number will be included in > the First-Hash along with the Authentication > Trailer and OSPF packet (Refer to Section 3.3 > in RFC 5709). > That sounds good to add to clarify the point. > Minor Comments: > > > Should the meta-data and header indicate that this updated RFC 5709? It > certainly looks like it. > > > I don’t feel strongly on this. However, this is a new type of OSPFv2 > cryptographic authentication and RFC 5709 authentication will continue to > be supported by implementations that support it. So, one could argue that > it updates RFC 2328 rather than RFC 5709. The whole issue of when to use > the “Updates” would be a good topic for WG chair discussion. > I believe (and Adrian may have additional perspective) that Updates is appropriate when a new implementation should use the updated RFC. Of course there will be implementations that stay RFC 5709 compliant. Looking more closely, I would agree that this draft should update both RFC 2328 (due to the packet format) and RFC 5709 (due to the algorithm changes). Using Updates provides nice pointers to both RFCs. I'd recommend bringing up the question of when the use "Updates" in the next chairs' chat. I'll add it to my list of potential topics. Thanks, Alia Thanks, > Acee > > > > > Thanks for the hard work on a good draft to make routing more secure! > > > Alia > > >
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
