Skip to main content

Supporting Authentication Trailer for OSPFv3
RFC 6506

Yes

(Stewart Bryant)

No Objection

(Gonzalo Camarillo)
(Pete Resnick)
(Robert Sparks)
(Ron Bonica)
(Wesley Eddy)

Note: This ballot was opened for revision 11 and is now closed.

(Adrian Farrel; former steering group member) Yes

Yes (2011-11-01)
These issues do not rate a Discuss because they are not central to the
document, but I wish you would sort them out.

---

Abstract
         
This is just about to become an RFC. Please change:
s/draft/document/
s/proposes/defines/

Similar in the Introduction

---

I am disappointed by the following paragraph in the Introduction.

   However, there are some environments, e.g., Mobile Ad-hoc Networks
   (MANETs), where IPsec is difficult to configure and maintain, and
   this mechanism cannot be used.  There is also an issue with IPsec not
   being available on some platforms.

It would make a lot of sense to give a citation for the assertion or
take the time to explain the problems with IPsec so that we can 
evaluate why the solution in this document is better.

I also think that the lack of availability of IPsec on some platforms
is not relevant. After all, *no* platforms support the features
described in this document.

---

Section 1.1

Please remove

   When used in lowercase, these words convey their typical use in
   common language, and are not to be interpreted as described in
   RFC2119 [RFC2119].

---

Figure 1

The text does not describe the figure, and the caption does not
correctly indicate the content of the figure.

---

Section 2.1

   OSPFv3 routers MUST set the AT-bit in
   OSPFv3 Hello and Database Description packets to indicate that the
   OSPFv3 router will include the authentication trailer in all OSPFv3
   packets on the link.

I find this ambiguous because I read left to right. Thus I read: 
   OSPFv3 routers MUST set the AT-bit in OSPFv3 Hello and Database
   Description packets

Could you flip the order of words?

---

Section 2.1

I see no value and possible minor downside to the inclusion of the
figure that shows the list of existing OSPFv3 options. This list is
maintained by IANA, and including it here creates potential conflict
etc.

Additionally, you need to consider whether this section is mandating
that bit 13 is used as the AF-bit. It is sort of implied, but the
IANA section doesn't quite make this clear, and there is no cross-
reference between the two sections.

---

Section 2.2

s/much same as/much the same as/

---

Section 3

   In the event that the last key associated
   with an interface expires, it is unacceptable to revert to an
   unauthenticated condition, and not advisable to disrupt routing.
   Therefore, the router should send a "last Authentication Key
   expiration" notification to the network manager and treat the key as
   having an infinite lifetime until the lifetime is extended, the key
   is deleted by network management, or a new key is configured

I really tnk tat both sentences need RFC 2119 language.

---

Section 5

   In general, all OSPFv3 routers participating on a link should be
   migrated to OSPFv3 Authentication at the same time.

What does this mean?!

(Jari Arkko; former steering group member) Yes

Yes (2011-11-03)
I like this document.

But I did see one issue: is the seq# space per router or per SA per router? I can't find text in the document that would tell me this. It seems to be talk about it almost as if it was per router... but most other designs such as IPsec use per SA seq#.

Can you clarify this aspect before you approve the document? Thanks.

(Stewart Bryant; former steering group member) Yes

Yes ()

                            

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection (2011-11-01)
1. section 4.1

      OSPFv3 routers implementing this specification SHOULD use
      available mechanisms to preserve the sequence number's strictly
      increasing property for the deployed life of the OSPFv3 router
      (including cold restarts).  Techniques such as sequence number
      space partitioning and non-volatile storage preservation can be
      used but are beyond the scope of this specification.

While there are certainly ways to produce such a number that do not incur the saving of state (number of miliseconds since the epoc would be a good initialization value, requires an accurate clock before an adjacency is formed). This is a rather strong requirement. e.g. it implies preserving ephemeral state across hardware replacement. Probably more implementation advice is required.

2. section 6.

The assertion that this offers more security  than 5340 essentially hinges on the ability to offer replay protection. it does essentially abandon the use of ipsec for ospf protection and in doing so means theirs three ways to deploy ospfv3 (no security, ipsec wrapped, auth trailer) assuming the later ends up being preferred to ipsec there likely will be a protracted period where 2 methods are required on given network, which has potentially interesting routing considerations. The final assessment in the section about 'not causing undue implementation, deployment, or operational complexity' may not always be true.

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()

                            

(Pete Resnick; former steering group member) No Objection

No Objection ()

                            

(Ralph Droms; former steering group member) No Objection

No Objection (2011-10-29)
Two comments about this text from section 4.1.1:

4.1.1.  Sequence Number Wrap

   When incrementing the sequence number for each transmitted OSPFv3
   packet, the sequence number should be treated as an unsigned 64-bit
   value.  If the lower order 32-bit value wraps, the high order 64-bit
   value should be saved in non-volatile storage.  [...]
   Once the keys have been changes, the higher order
   sequence number can be reset to 0 and saved to non-volatile
   storage.

* I don't understand the second sentence.
* s/changes/changed/

I apologize if I'm missing something obvious: where is the format of
the SA ID defined?

(Robert Sparks; former steering group member) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (2011-11-03)
S1, para 1: please add a sentence that explains that AH and ESP are
  part of IPsec.  Otherwise, the claim that IPsec does not work well in
  certain environments has no linkage to the text about AH and ESP.

  S4.5, step 1: to me, it would be more clear to say: "In this
  application, Ko is always L octets long, and it is computed as
  follows:"

  S4.6: please add a paragraph to the end that says the cryptographic
  sequence number is saved for future replay checks now that all of the
  checks have been successful.

  The Gen-ART Review by Wassim Haddad on 1-Nov-2011 points out another
  minor issue:  The draft mentions twice "MANETs" in the abstract and
  introduction without elaborating on that nor giving any reference
  specific to it.  MANETs have a set of routing protocols.  To avoid
  confusion, some further clarification about OSPFv3 in that context
  would be helpful.

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2011-11-28)
I'm updating this to move my discuss to a comment.

#1) addressed in -10

#2) addressed in -10

#3) addressed in -10

#4) s4.2: Had the same question Stephen did.

#5) addressed in -10

#6) s6: Isn't it more secure than 5430 but only when IPsec isn't used?

#7) s6: Need some motherhood and apple pie info about issues with manual keying, or you could point to RFC 4552 for manual keying security considerations.  Also, is there someplace you could point to a statement like: keep the private key private, when manually exchanging the key do it securely, etc.?

were discusses:

This is an updated discuss based on -10

#1) cleared

#2) I may have not been clear when I first wrote the discuss:

I was thinking that an implementer might assume that the implicit identification of the algorithm meant that they could guess the HMAC algorithm from the size of the HMAC output.  It's true now for the algs you've got defined, but might not be true if some crazy new new alg comes out that has the same output size.  Do you think an implementer might make that leap.  If so, then maybe a NOTE to say something like:

 Though the SA ID implicitly implies the algorithm, the HMAC output
 size should not be used by implementers as an implicit hint because
 additional algorithms may be defined in the future that have the
 same output size. 

#3) cleared

#4) cleared

#5) cleared

#6) This names of the SA field managed need to match the karp key table draft.

(Stephen Farrell; former steering group member) No Objection

No Objection (2011-10-24)
(Thanks for persevering with the overlong discussion of 
cross-protocol attacks back in August:-)

- abstract: maybe s/not depend/not only depend/?

- section 2, 1st para: maybe s/as, the/as the/ and s/trailer/trailer,/ 

- last sentence of section 2.1 - would s/must/MUST/ be better here?

- Does 2.1 mean that if the AT bit is set in the Hello or Database
description packets then it MUST be set in all subsequent packets
until <sometime>? When is <sometime>?  This may be my ignorance of
OSPF but "is preserved" isn't clear to me - it may be entirely clear
to OSPF experts though. Or maybe a forward reference to 4.5
and section 5 would be good. Not sure.

- end of section 3 is missing a full stop.

- I wasn't clear on whether or not you're requiring all coders
to support the key lifecycle scheme in section 3. The "MUST" 
in the 2nd last paragraph sort-of seems to make it so, but
being explicit would be better I think.

- section 4.1 s/length in octet/length in octets/

- Just checking - in 4.2 if a sender ignores the SHOULD and sets the
header checksum, and inputs that (non-zero value) to AT calculation,
is a receiver supposed to ignore that or barf the packet? (I assume
it ignores it if all else is ok?) Might be no harm to be explicit about
that.

- Maybe s/password/authentication key/ in section 6.

- I'd suggest you encourage deployments to use long random values
for the authentication key - while they could use the string
"password," that'd seem like a waste;-) Maybe the following text
might work: "Deployments SHOULD use sufficiently long and random
values for the authentication key so that guessing and other
cryptographic attacks on the key are infeasible in their
environment." If you wanted to RECOMMEND those be at least 128 good
pseudo-random bits that'd be even better. You might also want to
encourage implementers to accept ascii-hex input or something to
avoid potential I18N issues with typed values. 

(Wesley Eddy; former steering group member) No Objection

No Objection ()