Subject: Questions about OSPF v3 security draft

From: Mike Fox <[email-masked]>
Date: Fri, 11 Feb 2005 07:34:08 -0700

Regarding 
http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt, 
and the previous drafts, a couple of questions have come up in our shop. 

1) Section 7, 2nd paragraph says "the implementations MUST use manually 
configured keys with same SA for inbound and outbound traffic (as shown in 
figure 3).  I assume the "same SA" MUST rule applies to multicast traffic 
only and not unicast traffic. This is because an SA is defined as an SPI, 
security protocol (AH or ESP), and destination IP address. For unicast 
addresses, by definition there will be as many SAs as there are unicast 
destination addresses. Therefore, I don't think it is possible to apply 
this MUST rule given the current IPSec definition (RFC 2401 section 4.1) 
of an SA for unicast. Assuming the intention of the draft was to apply 
only to multicast and given the number of potential SAs carrying unicast 
traffic, it would seem that using IKE to setup the SAs dynamically would 
be a reasonable alternative to manual keying. 
 
2)Section 9, 2nd paragraph discusses setting up a "secure IPSec channel 
dynamically once it acquires the required information".  Since this 
traffic is unicast only, IKE could easily set up the required SAs without 
knowing the specific IP addresses in advance. Creating SAs dynamically do 
not fit easily within scope of manual SA functional capabilities. Why not 
use IKE for this traffic? Is this an acceptable option? 

Mike

-----------------------------------------------------------------------
Enterprise Network Solutions
-----------------------------------------------------------------------
Research Triangle Park, NC  USA

---

From: Erblichs <[email-masked]>
Date: Fri, 11 Feb 2005 12:58:10 -0800

Regarding

1) First, if the title specifies OSPFv3, should this RFC be making
comparisons to OSPFv2?

2) There are two expriration dates specified on the first page:
Auguest 2005 and June 2005, the later with the page 1 header.

3) Doesn't OSPFv3 specifiy Instance values in the headers so
multiple instances can be matched with Authentication? This is
a major diff between OSPFv2 and OSPFv3. Without the Instance
field, only Auth/Encrypt could be used to distinguish multiple
instances.

You hide part of this when dealing with multiple SAs per link
in section 8.

4) Isn't NULL authtication supported in v3? When we support NULL
Auth, is that a must support for Auth? "Section 3. Implimentations
conforming to this specification MUST support Authentication for
OSPFv3." Does this prevent NULL auth? Is this right?

5) Why must v3 packets be sliently discarded when authentication/
confidentially is enabled? Why shouldn't their be calls into
OSPF so OSPF can log these dropped packets.

"4. Confidentiality * OSPFv3 packets that are not
   protected ... MUST be silently discarded."

  Doesn't silent discards prevent administrators from identifing
  adj failures, unsucessful secutity probing, non-synchronized
  keyrollovers, etc...

6) If a Implimentation does not support confidentiiality
   and conforms to this specifiecation, is the packet discard
   behaviour UNDEFINED?  "implimentations ... SHOULD Support... ."

7) 5. Distinguishing OSPFv3 from OSPFv2
  "OSPF version field in the OSPF header cannot be used"

   Then what was the use of this version field? 

    Are you saying that if a implimentor pushes OSPFv3 packets
    into a IPv4 domain, then they must be processed as OSPFv2
    pkts??????

    I remember a discussion of pushing OSPFv2 into the IPv6
    domain and/or OSPFv3 into IPv4. What was the result of
    this? Did the result invalidate this section?

 8) "version field in IP header can be used"

     What if an implimentation strips the IP header before
     it passes it to OSPF?? Shouldn't they be stripped before
     lower layers are called?

 9) 7. Key Managemement

    "it is not scalable"   This means that you can't use even
    2 communcation channels when different SAs are used for
    inbound and outbound traffic.

    It may be more proper to say that "it does not scale well".

Mitchell Erblich