Supporting Authentication Trailer for OSPFv3
RFC 6506
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
(Adrian Farrel; former steering group member) Yes
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
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
(Dan Romascanu; former steering group member) (was Discuss) No Objection
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
(Pete Resnick; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
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
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
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
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
(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