Supporting Authentication Trailer for OSPFv3
draft-ietf-ospf-auth-trailer-ospfv3-11

[Ballot comment]
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.

[Ballot comment]
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 discussed:

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.

[Ballot comment]
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.

[Ballot discuss]
S4.6: when replay is detected, the OSPFv3 packet MUST be dropped.
  When authentication fails, the OSPFv3 packet MUST be discarded and
  an error event SHOULD be logged.  Why are these handled differently?

[Ballot comment]
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.

[Ballot 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.?

[Ballot discuss]
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.

[Ballot comment]
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.

[Ballot discuss]
#1) s3, s4.1, s4.3: So these might just be typos, but I'm trying to make sure something sinister isn't going on :)

s3 The "Authentication Algorithm" bullet indicates authentication algorithm id isn't sent on the wire.
s3 The SA ID bullet indicates that "Each SA ID specifies two independent parts, the authentication protocol and the authentication key, as explained below."
s4.1 SA ID indicates that it "identifies the algorithm and the secret key".
s4.3 indicates "As noted earlier, the SA ID implicitly specifies the algorithms used to generate and verify the message digest."

I assume authentication protocol and authentication algorithm are supposed to be different? So should s4.1 be "identifies the authentication protocol and the secret key"?  If they're different the statement in s4.3 doesn't make sense because it would only imply the authentication protocol not the algorithm.  Maybe authentication protocol and authentication algorithm are supposed to be the same thing!?

#2) Implicit algorithm identification:

NIST has done some funny things in draft FIPS 180-4.  They defined SHA-512/224 and SHA-512/256 that are optimized for 64-bit OSes.  They output size for SHA-512/224 is the same as SHA-224 and the output size for SHA-512/256 is the same as SHA-256.  Who really knows what they're going to do with the SHA-3 options, but what I heard at IETF 81 (from Tim Polk at SAAG) is that the winners are going to also end up using the same output sizes to allow them to be more easily be dropped in existing protocols.  This doesn't even take in to account somebody else coming up with the greatest hash algorithm ever that also has the same output lengths as SHA-*.  The way you've got it set up another algorithm can't be implicitly identified that that has the same output sizes as what you've defined.

I think it is really, really short sighted to use implicitly algorithm selection.  Was explicit algorithm discussed in the WG?

#3) So we normally require that new security mechanisms support automated key management.  This one doesn't - are we okay with giving this one a waiver?

#4) This draft claims to support replay protection, but if it's using AKM and the key expires then while you're waiting to swap the key out you're vulnerable to replay attacks.

#5) I've been told that there's a significant installed base that supports IPsec. Why are we trying to switch horses here?

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
S4.6: when replay is detected, the OSPFv3 packet MUST be dropped.
  When authentication fails, the OSPFv3 packet MUST be discarded and
  an error event SHOULD be logged.  Why are these handled differently?

[Ballot comment]
#1) s1: Mentioned AH in the 1st paragraph but don't say anything about why it's not viable.

#2) s1: RFC 6234 obsoleted RFC 4634 so please update the reference.

#3) s4.1/s7: Auth Type 1 - Maybe make it HMAC Cryptographic Authentication. Cryptograph Authentication is pretty darn generic.  It would be nice if you maybe indicated the mechanism - i.e., HMAC.

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

#5) s4.6: Need to add a pointer back to s4.5 in the last paragraph for the verification algorithm.

#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.?

[Ballot discuss]
#1) s3, s4.1, s4.3: So these might just be typos, but I'm trying to make sure something sinister isn't going on :)

s3 The "Authentication Algorithm" bullet indicates authentication algorithm id isn't sent on the wire.
s3 The SA ID bullet indicates that "Each SA ID specifies two independent parts, the authentication protocol and the authentication key, as explained below."
s4.1 SA ID indicates that it "identifies the algorithm and the secret key".
s4.3 indicates "As noted earlier, the SA ID implicitly specifies the algorithms used to generate and verify the message digest."

I assume authentication protocol and authentication algorithm are supposed to be different? So should s4.1 be "identifies the authentication protocol and the secret key"?  If they're different the statement in s4.3 doesn't make sense because it would only imply the authentication protocol not the algorithm.  Maybe authentication protocol and authentication algorithm are supposed to be the same thing!?

#2) Implicit algorithm identification:

NIST has done some funny things in draft FIPS 180-4.  They defined SHA-512/224 and SHA-512/256 that are optimized for 64-bit OSes.  They output size for SHA-512/224 is the same as SHA-224 and the output size for SHA-512/256 is the same as SHA-256.  Who really knows what they're going to do with the SHA-3 options, but what I heard at IETF 81 (from Tim Polk at SAAG) is that the winners are going to also end up using the same output sizes to allow them to be more easily be dropped in existing protocols.  This doesn't even take in to account somebody else coming up with the greatest hash algorithm ever that also has the same output lengths as SHA-*.  The way you've got it set up another algorithm can't be implicitly identified that that has the same output sizes as what you've defined.

I think it is really, really short sighted to use implicitly algorithm selection.  Was explicit algorithm discussed in the WG?

[Ballot comment]
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?!

[Ballot comment]
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.

[Ballot discuss]
The DISCUSS is based on comments made by Joel Jaegli in his OPS-DIR review.

1. In Section 5, the first sentence -

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

I would rather make this recommendation in a crisper manner by dropping 'In general' and capitalizing SHOULD

All OSPFv3 routers participating on a link SHOULD be
  migrated to OSPFv3 Authentication at the same time. 

2. It would be worth mentioning that unlike other potential or implemented extensions to ospfv3 e.g. rfc 5838 downward/backward compatibility isn't feasible to implement, either you support this extension or you do not. The approach described in section 5 while possible in some environments implies the simultanious operation of protected and un-protected ospf on the same devices.

3. also in section 5:

  An implementation MAY have a transition mode where it includes the
  Authentication Trailer in the packets but does not verify this
  information.  This is provided as a transition aid for networks in
  the process of migrating to the mechanism described in this draft.

should be noted that this entails risk that something that is thought to be working is in fact not and that it will fail when enabled

[Ballot comment]
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?

[Ballot comment]
(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 ? When is ?  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.

IANA understands that, upon approval of this document, there are two
actions which IANA must complete.

First, in the OSPFv3 Options (24 bits) registry in the Open Shortest
Path First v3 (OSPFv3) Parameters registry located at:

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

a new OSPFv3 option is to be registered as follows:

Value:
Description: AT-bit
Reference: [ RFC-to-be ]

Second, IANA is to create a new registry in the Open Shortest Path First
v3 (OSPFv3) Parameters registry located at:

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

called the OSPFv3 "Authentication Trailer Types Registry"

The registration policy for this new registry is "Standards Action" as
defined by RFC 5226. The initial values for the registry are as follows:

Value Designation Reference
----- ---------------------------- -------------------
0 Reserved [ RFC-to-be ]
1 Cryptographic Authentication [ RFC-to-be ]
2-65535 Unassigned

IANA understands that these two actions are the only ones that need to
be completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
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 a 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 2011-08-16. 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 OSPFv3 uses IPsec for authenticating protocol packets.
  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.  This draft proposes an alternative
  mechanism that can be used so that OSPFv3 does not depend upon IPsec
  for authentication.




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

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ospf-auth-trailer-ospfv3/


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

(1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

        Abhay Roy, Yes

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

        Yes, No

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

        No

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

        No

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

        This draft is taking a proven concept from OSPFv2 (message
        digest) and introducing in OSPFv3. There was extensive review
        from OSPF and Security (KARP in particular) folks. The WG review
        discussion was around the length of Crypto Sequence Number (changed
        from 32 bit to 64 bit during WG review) and inclusion of IPv6
        Source Address in digest calculation.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

        No

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

        Yes

--------------------------------------------------------------------------------
idnits 2.12.12

draft-ietf-ospf-auth-trailer-ospfv3-05.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (May 10, 2011) is 25 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Obsolete informational reference (is this intentional?): RFC 4634
    (Obsoleted by RFC 6234)


    Summary: 0 errors (**), 0 warnings (==), 2 comments (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.
--------------------------------------------------------------------------------

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

        Yes, No

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

        Yes (to all questions above)

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

        N/A

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

    Currently OSPFv3 uses IPsec for authenticating protocol packets.
    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. This draft proposes a new mechanism
    based on OSPFv2 "message digest" approach. Additionally this document
    describes how HMAC-SHA authentication can be used for OSPFv3.

    Working Group Summary

    The only dicsussion worth noting was around the size of Crypto
    Sequence Number. After much debate it was agreed to increase it
    from 32 bit to 64 bit.   

    Document Quality

    This extension is similar to OSPFv2 Cryptographic Authentication
    where a message digest is appended to the end of the ospf packet.
    There is no known implementation at this time.