[OSPF] Re: secdir review of draft-ietf-ospf-mt-06.txt

Peter Psenak <ppsenak@cisco.com> Tue, 31 October 2006 11:13 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GerYN-0003qj-1u; Tue, 31 Oct 2006 06:13:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GerYK-0003qC-Od; Tue, 31 Oct 2006 06:13:08 -0500
Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GerYE-0006id-S9; Tue, 31 Oct 2006 06:13:08 -0500
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id k9VBD1b06375; Tue, 31 Oct 2006 12:13:01 +0100 (CET)
Received: from [144.254.245.179] (dhcp-144-254-245-179.cisco.com [144.254.245.179]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id k9VBCxP17660; Tue, 31 Oct 2006 12:12:59 +0100 (CET)
Message-ID: <45472FBA.8000705@cisco.com>
Date: Tue, 31 Oct 2006 12:12:58 +0100
From: Peter Psenak <ppsenak@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en, zh, ja, ko, de, ar, ru, fr, es, it, pt
MIME-Version: 1.0
To: j.schoenwaelder@iu-bremen.de
References: <20061030165712.GA6104@boskop.local> <45465B70.2040000@cisco.com>
In-Reply-To: <45465B70.2040000@cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213
Cc: secdir@mit.edu, ospf@ietf.org, iesg@ietf.org
Subject: [OSPF] Re: secdir review of draft-ietf-ospf-mt-06.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Juergen,

please see inline:

Peter Psenak wrote:

> 
> 
> Juergen Schoenwaelder wrote:
> 
>> Hi!
>>
>> As part of the security directorate review effort, I was asked to
>> review draft-ietf-ospf-mt-06 and below is my report.
>>
>> The document specifies how OSPF can be used multiple independent IP
>> topologies. The security considerations simply point to the security
>> considerations in RFC 2328 (the OSPF spec) which explains how OSPF
>> authentication works (by pointing to the relevant portions of the
>> spec). I do not really see a problem with this approach for this OSPF
>> extension and find it adequate.
>>
>> While reviewing the document, I found (besides editorial issues) two
>> things that remain rather unclear to me (and which I would love to get
>> clarified):
>>
>> - The IANA considerations confused me. What is IANA expected to do?

We have received comment from IANA and we agreed that we will state in 
the IANA considerations that we do NOT want IANA to manage the MT space.

>>
>> - Question: Will the MIB interfaces still work with the MT extension
>>   or are extensions to the OSPF-MIB needed to support OSPF-MT?

MIB interface should work as today what regards to the base topology. 
draft-rawat-ospf-mt-mib-01.txt has been submitted to extend the OSPFv2 
MIB to support multiple topologies.

>>
>> Editorial:

we will include below comments/corrections in the next version.

thanks,
Peter

>>
>> - Avoid acronyms and references in the abstract.
>>
>> - Some references use RFC number style, others to not. You may want to
>>   use a consistent approach.
>>
>> - There are a number of missing articles and such things. Rather than
>>   writing this up in details, I edited the document and I am attaching
>>   a unified context diff with the delta.
>>
>> --- ./draft-ietf-ospf-mt-06.txt    2006-02-01 21:46:37.000000000 +0100
>> +++ ./draft-ietf-ospf-mt-06-hacked.txt    2006-10-30 
>> 17:33:35.000000000 +0100
>> @@ -188,10 +188,10 @@
>>     Multi-topology routing differs from RFC 1583 TOS based routing in the
>>     following ways:
>>  
>> -   1.  With RFC 1583 TOS routing, the TOS or DSCP in the IP header is
>> -       mapped directly to the the corresponding OSPF SPF calculation and
>> +   1.  With RFC 1583 TOS routing, the TOS or DSCP value in the IP 
>> header is
>> +       mapped directly to the corresponding OSPF SPF calculation and
>>         routing table.  This limits the number and definition of the
>> -       topologies to the 16 TOS values specified is section 12.3 of RFC
>> +       topologies to the 16 TOS values specified in section 12.3 of RFC
>>         1583 [RFC1583].  With multi-topology routing, the classification
>>         of what type of traffic maps to which topology is not within the
>>         scope of the document.
>> @@ -324,9 +324,9 @@
>>     to a set of MTs, it will advertise the corresponding cost for each
>>     MT-ID.
>>  
>> -   By default, all links are included in default topology and all
>> +   By default, all links are included in the default topology and all
>>     advertised prefixes belonging to the default topology will use the
>> -   TOS0 metric the same as in standard OSPF [OSPF].
>> +   TOS0 metric, the same as in standard OSPF [OSPF].
>>  
>>     Each MT has its own MT-ID metric field.  When a link is not part of a
>>  
>> @@ -339,8 +339,9 @@
>>  
>>     given MT, the corresponding MT-ID metric is excluded from the LSA.
>>  
>> -   The Network-LSA does not contain any MT information since the DR is
>> -   shared by all MTs.  Hence, there is no change to the Network-LSA.
>> +   The Network-LSA does not contain any MT information since the
>> +   Distinguished Router (DR) is shared by all MTs.  Hence, there is no
>> +   change to the Network-LSA.
>>  
>>  3.4.2  Inter-Area and External Routing
>>  
>> @@ -409,7 +410,7 @@
>>  
>>  3.8  Forwarding in MT
>>  
>> -   It's outside of the scope of this document to specify how the
>> +   It is outside of the scope of this document to specify how the
>>     information in various topology specific forwarding structures are
>>     used during packet forwarding or how incoming packets are associated
>>     with the corresponding topology.  For correct operation, both
>> @@ -456,7 +457,7 @@
>>     from the default topology and reserve them for some specific classes
>>     of traffic.
>>  
>> -   The multi-topologies extension for default topology link or prefix
>> +   The multi-topologies extension for the default topology link or 
>> prefix
>>     exclusion is described in the following subsections.
>>  
>>  4.1  Exclusion of Links in the Default Topology
>> @@ -467,7 +468,7 @@
>>     Router-LSAs in the default topology and to alternately use the MT-
>>     ID#0 metric to advertise the metric associated with the default
>>     topology.  Hence, all routers within an area MUST agree on how the
>> -   metric for default topology will be advertised.
>> +   metric for the default topology will be advertised.
>>  
>>     The unused T-bit is defined as the MT-bit in the option field in
>>     order to  assure that a multi-topology link-excluding capable router
>> @@ -478,7 +479,7 @@
>>             |DN |O  |DC |EA |NP |MC |E  |MT |
>>             +---+---+---+---+---+---+---+---+
>>  
>> -       MT-bit: If DefaultExclusionCapability is enable, this bit MUST
>> +       MT-bit: If DefaultExclusionCapability is enabled, the MT bit MUST
>>                 be set in Hello packets and SHOULD be set in Database
>>                 Description packet (see Section 4.2).
>>  
>> @@ -519,10 +520,10 @@
>>     If DefaultExclusionCapability is enabled:
>>  
>>     o  The MT-bit MUST be set in Hello and SHOULD be set in Database
>> -      Description packets
>> +      Description packets.
>>  
>>     o  The router will only accept a Hello packet if the MT-bit is set
>> -      (see Section 4.3)
>> +      (see Section 4.3).
>>  
>>     When DefaultExclusionCapability is set to enabled a router is said to
>>     be operating in DefaultExclusionCapability mode.
>> @@ -532,9 +533,9 @@
>>     In order to have a smooth transition from a non-MT area to an MT-
>>     area, an MT router with DefaultExclusionCapability disabled will form
>>     adjacencies with non-MT routers and will include all links as part of
>> -   default topology.
>> +   the default topology.
>>  
>> -   A link may cease participating in default topology if
>> +   A link may cease participating in the default topology if
>>     DefaultExclusionCapability is set to enabled.  In this state, a
>>     router will only form adjacency with routers that set the MT-bit in
>>     their Hello packets.  This will ensure that all routers have
>> @@ -545,7 +546,7 @@
>>     modified as follows:
>>  
>>     o  If the DefaultExclusionCapability in the Area Data structure is
>> -      set to enabled, Hello packets are discarded if the the received
>> +      set to enabled, Hello packets are discarded if the received
>>        packet does not have the MT-bit set in the header options.
>>  
>>     Receiving OSPF Database Description packets as defined in section
>> @@ -574,13 +575,13 @@
>>  
>>  4.5  OSPF LSA Advertisement and SPF Computation for Excluded Links
>>  
>> -   When DefaultExclusionCapability is enabled and the link does not
>> +   When the DefaultExclusionCapability is enabled and the link does not
>>     participate in the default topology, the MT-ID#0 metric is not
>>     advertised.  The link's TOS0 metric is ignored during the default
>>     topology SPF computation.
>>  
>> -   When DefaultExclusionCapability is enabled and a link participates in
>> -   the default topology, MT-ID#0 metric is used to advertise the metric
>> +   When the DefaultExclusionCapability is enabled and a link 
>> participates in
>> +   the default topology, the MT-ID#0 metric is used to advertise the 
>> metric
>>     associated with the default topology.  The link's TOS0 metric is
>>     ignored during the default topology SPF computation.
>>  
>> @@ -590,7 +591,7 @@
>>     o  If the prefix or router does not exist in the default topology,
>>        the TOS0 metric is set to infinity (0xFFFFFF).
>>  
>> -   o  If the prefix or router exists in default the topology, the TOS0
>> +   o  If the prefix or router exists in the default the topology, the 
>> TOS0
>>        metric is used to advertise the metric in the default topology.
>>  
>>     During the summary and external prefix calculation for the default
>> @@ -698,10 +699,10 @@
>>         interaction required with non-MT routers.  In this mode, the
>>         default topology can be excluded on links as required.
>>  
>> -   3.  If there is more than one non-backbone areas where MT is being
>> -       used, it is desirable that the backbone area first be upgraded to
>> -       be MT capable so that inter-area routing is assured for MT
>> -       destinations in different areas.
>> +   3.  If there are multiple (more than one) non-backbone areas where
>> +       MT is being used, it is desirable that the backbone area first
>> +       be upgraded to be MT capable so that inter-area routing is
>> +       assured for MT destinations in different areas.
>>  
>>     4.  Gradually the whole network can be made MT capable.
>>  
>> @@ -1019,7 +1020,7 @@
>>     router-LSA.  The LSA describes the state and cost of the router's
>>     links (i.e., interfaces) to the area.  All of the router's links to
>>     the area must be described in a single router-LSA.  For details
>> -   concerning the construction of router-LSAs, see Section 12.4.1
>> +   concerning the construction of router-LSAs, see Section 12.4.1 of
>>     [OSPF].
>>  
>>  
>> @@ -1078,7 +1079,7 @@
>>     The distance from the network to all attached routers is zero.  This
>>     is why metric fields need not be specified in the network-LSA.  For
>>     details concerning the construction of network-LSAs, see Section
>> -   12.4.2 [OSPF].
>> +   12.4.2 of [OSPF].
>>  
>>  
>>       0                   1                   2                   3
>> @@ -1101,7 +1102,7 @@
>>       |                              ...                              |
>>  
>>     Note that network LSA does not contain any MT-ID fields as the cost
>> -   of the network to the attached routers is 0 and DR is shared by all
>> +   of the network to the attached routers is 0 and the DR is shared 
>> by all
>>     topologies.
>>  
>>  B.3  Summary-LSAs
>> @@ -1109,7 +1110,7 @@
>>     Summary-LSAs are the Type 3 and 4 LSAs.  These LSAs are originated by
>>     area border routers.  Summary-LSAs describe inter-area destinations.
>>     For details concerning the construction of summary- LSAs, see Section
>> -   12.4.3 [OSPF].
>> +   12.4.3 of [OSPF].
>>  
>>     Type 3 summary-LSAs are used when the destination is an IP network.
>>     In this case the LSA's Link State ID field is an IP network number
>> @@ -1122,7 +1123,7 @@
>>  
>>  
>>     (if necessary, the Link State ID can also have one or more of the
>> -   network's "host" bits set; see Appendix E [OSPF] for details).  When
>> +   network's "host" bits set; see Appendix E of [OSPF] for details).  
>> When
>>     the destination is an AS boundary router, a Type 4 summary-LSA is
>>     used, and the Link State ID field is the AS boundary router's OSPF
>>     Router ID.  (To see why it is necessary to advertise the location of
>> @@ -1161,12 +1162,12 @@
>>     AS-external-LSAs are the Type 5 LSAs.  These LSAs are originated by
>>     AS boundary routers, and describe destinations external to the AS.
>>     For details concerning the  construction of AS-external-LSAs, see
>> -   Section 12.4.3 [OSPF].
>> +   Section 12.4.3 of [OSPF].
>>  
>>     AS-external-LSAs usually describe a particular external destination.
>>     For these LSAs the Link State ID field specifies an IP network number
>>     (if necessary, the Link State ID can also have one or more of the
>> -   network's "host" bits set; see Appendix E [OSPF] for details).  AS-
>> +   network's "host" bits set; see Appendix E of [OSPF] for details).  
>> AS-
>>     external-LSAs are also used to describe a default route.  Default
>>     routes are used when no specific route exists to the destination.
>>  
>> @@ -1178,7 +1179,7 @@
>>  
>>  
>>     When describing a default route, the Link State ID is always set to
>> -   DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0.
>> +   the DefaultDestination (0.0.0.0) and the Network Mask is set to 
>> 0.0.0.0.
>>  
>>  
>>        0                   1                   2                   3
>> @@ -1224,7 +1225,7 @@
>>     boundary routers local to an NSSA, and describe destinations external
>>     to the AS.  The changes to NSSA-LSAs are identical to those for
>>     External-LSAs (Appendix A.4.5).  For details concerning the
>> -   construction of NSSA-LSAs see Section 2.4 [NSSA].
>> +   construction of NSSA-LSAs see Section 2.4 of [NSSA].
>>  
>> /js
>>
> 

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf