Authentication/Confidentiality for OSPFv3
draft-ietf-ospf-ospfv3-auth-08

Reviewed by Spencer Dawkins, Gen-ART

A DISCUSS that has been turned into a comment:

I can not find in section 8 where it defines what keying shall be used for
virtual links.  Either the intention is that a single key be used over the
whole domain, which would need to be stated, with its security
implications, or else IKE needs to be used, in which case that needs to be
stated, along with moving IKE to a normative reference.  Or maybe there is
some alternative I have missed.

My grumble: With all the work that's been sunk into multicast security, is it really not possible to do any better than "broadcast media requires static keying with one key per medium"?

However, I trust Steve and Russ to do as well as can be done over this.

The discussion of how often manual keys need to be changed is poorly
worded.  It states as facts that hmac-SHA1 is more secure than
hmac-MD5 and that DES plus hmac-MD5 is more secure than hmac-MD5
alone.  These are reasonable assumptions to make, but they are not
facts; the section would be improved by stating these as assumptions.

In the abstract, s/using IPv6/using an IPv6/

Not blocking since the blocking portion of it is covered in Steve's DISCUSS, but I
also found Section 9 on Changing Keys fairly weak and Section 6's discussion of
manual keying and multicast light.  I think the reader would benefit from
a discussion of how the limitations on manual keying for multicast will affect
the deployment of this mechanism--does it imply, for example, something
about appropriate multicast group sizes?

> 2. OSPFv2 to OSPFv3
> 
>    Security concerns MUST be taken away from OSPFv3 protocol and IPv6
>    stack MUST provide inherent security to OSPFv3 by using AH/ESP
>    extension headers.  It means OSPFv3 protocol MUST NOT receive any
>    unauthenticated packets.  As OSPFv2 has its own security mechanisms,
>    no inherent security needs to be provided by the IPv4 stack.  As
>    OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, the distinction
>    between the packets can be easily made by IP version.

wording poor. sounds like you MUST use AH/ESP. Surely, it is optional
when one chooses to use it.

>    Encryption and Authentication Algorithms
>       The implementations MUST be conformant to the RFCs that describe
>       mandatory-to-implement algorithms for use with ESP and AH.

Cite the RFC please...

>    So, all the neighbor routers on a network/subnet MUST use the same SA
>    and the same SA MUST be used for inbound and outbound processing.

and how does this impact replay protection?

>    Different SA than the SA of underlying interface MUST be provided for
>    virtual links.  Packets sent out on virtual links use unicast site-
>    local or global IPv6 addresses as the IPv6 source address and all the
>    other packets use multicast and unicast link local addresses.  This
>    difference in the IPv6 source address is used in order to
>    differentiate the packets sent on interfaces and virtual links.

given the deprecation of site local, can the above be rewritten to say
"non-link local" rather than mentioning site-local?

Also, is this necessary? Why do use of virtual links have standards
implications? In general, virtual links are just implementation
tricks. Protocols should not  need to know about them.

>   links are learnt during the routing table build up process.  The

s/learnt/learned/

>    To maintain the security of a link, it may be desirable to change the
>    key values from time to time.  The following three-step procedure MAY
>    be provided to rekey the routers on a link without dropping OSPFv3
>    protocol packets or disrupting the adjacency.

This is only a MAY? Seems like a SHOULD or MUST.

Security considerations seems pretty weak..