Supporting Authentication Trailer for OSPFv3
draft-ietf-ospf-rfc6506bis-05

[Ballot comment]

- intro: I'm not entirely sure but I don't buy that
there's no way to distinguish plain and ciphertext in ESP
as a justification for this.  I'd say delete the point or
justify it properly (which could be be reference).
There's suggested changes on this point from the
secdir review as well, please consider those.

- intro: do you really need all those hash functions?
Why? That seems like a recipe for lack of interop for no
security benefit. (Agility is a benefit, but there's no
need to populate every option you can think of just for
fun.)

- intro: Why the "believed" there? And I don't think any
RFC is "mathematically identical" to anything, not even
itself!

- 2.1: Does the AT bit really mean that an AT will be used
for all packets on this link for all time? Won't that
cause deployment problems if you ever need to deploy an
"AT++" trailer signalled via a different bit in the
header? Maybe you need to qualify the "all" some more?
Similarly, if there's any load balancing done on the
source end of a link, mightn't this rule cause problems
when you initiate turning on AT and there's a delay
between getting that into place betweeen two load-balanced
speakers? (That last might be nonsense, I've no idea how
OSPF if deployed in anything like that manner, but some
other systems are. The first point though I think is valid
ignoring any load-balancing.)

- section 3: is a 16 bit SA-ID enough? That allows
guessing fairly trivially and if there's any real DoS or
timing attack then an attacker could search that space
very quickly.

- section 3: I wondered why referring to the karp key
table wouldn't have been a good idea here instead of a
"key chain"?

- 4.1: why is the 64-bit sequence number OSPFv3 packet
type specific? That seems to uselessly call for more
storage on the validator side. If there's a good reason, I
don't get it. I also don't get why you're insisting on
strict monotonic increase here but then say that packets
can arrive out of order. Is something broken there in the
text?

- 4.2: An example would really help here. Omitted vs.  set
to zero is confusing, as stated.

- 4.5: You're *still* copy and pasting the HMAC algorithm
internals? How many times do you intend to do this before
you consider it a bad plan?  I think that's a bad idea and
wish I'd DISCUSSed it out of you before;-)

- Appendix A: I thought HMAC was invented by Hugo and not
NIST. You might want to check the ack there. And thanks
for thanking me before I'd even seen this draft! Are you
perhaps copy and pasting too much here again? (Or, did you
just assume I'd have some dumb comment to make for sure:-)

[Ballot comment]
[Sorry for the re-send. Forgot one bit.]

Asking with no insight into the actual technology: The number of changes between 6506 and these seem pretty minimal to me. Is there a reason this is recycling at Proposed Standard and not being offered for Internet Standard? Do you expect that you still haven't gotten it quite right?

6506 is an Informative reference, not a Normative reference.

[Ballot comment]
Asking with no insight into the actual technology: The number of changes between 6506 and these seem pretty minimal to me. Is there a reason this is recycling at Proposed Standard and not being offered for Internet Standard? Do you expect that you still haven't gotten it quite right?

6506 is an Informative reference, not a Normative reference.

[Ballot comment]
Asking with no insight into the actual technology: The number of changes between 6506 and these seem pretty minimal to me. Is there a reason this is recycling at Proposed Standard and not being offered for Internet Standard? Do you expect that you still haven't gotten it quite right?

[Ballot comment]
Is there anyway that we can just point to the OSPFv2 AT RFC for the crypto aspects?  It looks very similar just in a numbered list as opposed to separate sections.

spt

[Ballot comment]
Thanks for this work and especially for the clear Section 1.2.

There are just two minor Comments I'd like you to look at...

---

Except for noting the fact that this document obsoletes 6506, the
Abstract gives no clue that this document is not a new definition of
the Authentication Trailer. I'd like something like:

  The OSPFv3 Authentication Trailer we originally defined in RFC 6506. 
  This document obsoletes RFC 6506 by providing a revised definition
  including clarifications and refinements of the procedures.

---

I want to be clear that it is not your intention (as it was not the
intention in RFC 6506) that the procedures in this document will form
part of OSPFv3. That is, in your opinion, a new implementation of OSPFv3
is free to ignore this document and not consider it an essential part of
the protocol.

If I have stated it correctly, there is nothing for you to do. If I have
it wrong then some changes to the document are needed (at least "updates
5340").

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ospf-rfc6506bis-02.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has questions about the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are no IANA Actions that need completion.  IANA requests that the IANA Considerations section of the document remain in place upon publication.

IANA notes that the IANA Considerations section makes reference to the AT-bit (0x000400) in the "OSPFv3 Options (24 bits)" registry located at:

http://www.iana.org/assignments/ospfv3-parameters/

this option was registered as part of the IANA actions for RFC 6506.
Should the reference for this option be updated to [ RFC-to-be ]?

Also, IANA notes that the IANA Considerations section makes reference to two registries that already exist and that are populated with the entries indicated in the text of the IANA Considerations section. These registries are:

the "OSPFv3 Authentication Types" registry (http://www.iana.org/assignments/ospfv3-authentication-trailer-options)

and,

the "Authentication Cryptographic Protocol ID" registry
(http://www.iana.org/assignments/authentication-cryptographic-protocol-id)

Should these registries have their references updated to [ RFC-to-be ]?
Or,
Should these two registries be moved to the existing OSPFv3 Parameters
registry located at http://www.iana.org/assignments/ospfv3-parameters?

Also, we notices that Open Shortest Path First v3 (OSPFv3) is part of
the title of the "OSPFv3 Authentication Types" registry whereas OSPFv3
is not listed anywhere in the "Authentication Cryptographic Protocol
ID" registry.  Question: should OSPFv3 be included in the title of
the "Authentication Cryptographic Protocol ID" registry?

Please see: the IANA protocol matrix located at:

http://www.iana.org/protocols

In fact, it appears that the texts in the IANA Considerations section
in this bis document is a copy of the IC section of RFC 6506.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Supporting Authentication Trailer for OSPFv3) to Proposed Standard


The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'Supporting Authentication Trailer for OSPFv3'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-11-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism
  for authenticating protocol packets.  This behavior is different from
  authentication mechanisms present in other routing protocols (OSPFv2,
  Intermediate System to Intermediate System (IS-IS), RIP, and Routing
  Information Protocol Next Generation (RIPng)).  In some environments,
  it has been found that IPsec is difficult to configure and maintain
  and thus cannot be used.  This document defines an alternative
  mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does
  not only depend upon IPsec for authentication.  This document
  obsoletes RFC 6506.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ospf-rfc6506bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ospf-rfc6506bis/ballot/


No IPR declarations have been submitted directly on this I-D.