Re: [OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-07

Sun, 11 Oct 2015 06:09:08 -0700 

David,


>Injection of tag values from the outside (e.g., forge OSPF traffic that 
>appears to be from a node in the domain and carries administrative tag values) 
>is >at least a possible denial-of-service attack vector, and could also be 
>used for more nefarious purposes (e.g., reroute otherwise unobservable [to the 
>>attacker] VPN traffic via a route where the attacker can observe it).  
>Measures should be taken to prevent injection of outside OSPF traffic in 
>general >to protect not only tags, but all OSPF routing functionality.

<Shraddha> The -08 version contains reference to RFC 4593 and RFC 6863 which 
discuss in-detail on different security vulnerabilities and OSPF authentication 
mechanisms described in RFC 2328,5340 , 7474 and 7166 are sited as solution to 
the problem.
I think this description would also cover the issue you have brought up. Let me 
know if you are OK with this.

Rgds
Shraddha


-----Original Message-----
From: Black, David [mailto:[email protected]] 
Sent: Saturday, October 10, 2015 2:14 AM
To: Shraddha Hegde <[email protected]>; [email protected]; [email protected]; 
[email protected]; [email protected]; General Area Review Team 
([email protected]) <[email protected]>; [email protected]
Cc: [email protected]; [email protected]; [email protected]; Black, David 
<[email protected]>
Subject: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-07

The -07 version of this draft addresses all of the issues raised in the Gen-ART 
and OPS-Dir review of the -06 version, with the Operational Considerations 
section being a particularly welcome addition.  Many thanks to the authors for 
the quick turnaround on everything that was done.

The following is a possible additional security consideration:

Injection of tag values from the outside (e.g., forge OSPF traffic that appears 
to be from a node in the domain and carries administrative tag values) is at 
least a possible denial-of-service attack vector, and could also be used for 
more nefarious purposes (e.g., reroute otherwise unobservable [to the attacker] 
VPN traffic via a route where the attacker can observe it).  Measures should be 
taken to prevent injection of outside OSPF traffic in general to protect not 
only tags, but all OSPF routing functionality.

Thanks,
--David


> -----Original Message-----
> From: Black, David
> Sent: Monday, October 05, 2015 7:35 PM
> To: [email protected]; [email protected]; [email protected]; 
> [email protected]; [email protected]; General Area Review 
> Team ([email protected]); ops- [email protected]
> Cc: [email protected]; [email protected]; Black, David; [email protected]
> Subject: Gen-ART and OPS-Dir review of 
> draft-ietf-ospf-node-admin-tag-06
> 
> This is a combined Gen-ART and OPS-Dir review.  Boilerplate for both 
> follows ...
> 
> I am the assigned Gen-ART reviewer for this draft. For background on 
> Gen-ART, please see the FAQ at:
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments 
> you may receive.
> 
> I have reviewed this document as part of the Operational directorate's 
> ongoing effort to review all IETF documents being processed by the 
> IESG.  These comments were written primarily for the benefit of the 
> operational area directors.
> Document editors and WG chairs should treat these comments just like 
> any other last call comments.
> 
> Document: draft-ietf-ospf-node-admin-tag-06
> Reviewer: David Black
> Review Date: October 5, 2015
> IETF LC End Date: October 8, 2015
> IESG Telechat date: October 15, 2015
> 
> Summary:  This draft is on the right track, but has open issues
>               described in the review.
> 
> This is a generally well-written draft about adding administrative 
> tags for operational use to OSPF.  The draft is clear, and the 
> material on how the tags could be used is helpful, although raises a 
> number of concerns about the consequences of the intended usage of these tags.
> 
> ---- Major issues: ----
> 
> [1] Operational considerations:  There appears to be more than enough 
> enabled by this draft to wreak serious operational havoc, but the 
> draft seems to sidestep all operational topics, primarily by treating 
> all usage of tags as vendor- or implementation- specific and trusting 
> the vendors and operators not to foul things up.  I'm not sure that's wise.
> 
> See end of OPS-Dir review below for more on this concern.
> 
> --- Minor issues: ----
> 
> -- 3.2 Elements of procedure:
> 
> [A] I see what look like some underspecified requirements:
> 
>    Each tag SHOULD be treated as an independent identifier that MAY be
>    used in policy to perform a policy action.
> 
>    The administrative tag list within the
>    TLV SHOULD be considered an unordered list.
> 
> Why are those two not "MUST" requirements?  What happens if either is 
> not done?
> 
> [B] Tag set completeness:
> 
>    Multiple node administrative tag TLVs MAY appear in an RI LSA or
>    multiple node administrative tag TLVs MAY be contained in different
>    instances of the RI LSA.  The node administrative tags associated
>    with a node for the purpose of any computation or processing SHOULD
>    be a superset of node administrative tags from all the TLVs in all
>    instances of the RI LSA originated by that node.
> 
> This paragraph is about processing at that node.  It's easy to 
> misread, as that implication is buried in the word "originated" in the last 
> line.
> Suggested change:
> 
>       "for the purpose of any computation or processing SHOULD" ->
>       "for the purpose of any computation or processing performed
>               at that node SHOULD"
> 
> Also, it looks like it's acceptable for other nodes to perform such 
> computation or processing based on a partial tag set for this node 
> (e.g., when some other node has not received all the RI LSAs with all 
> the tags).  That should be stated.
> 
> [C] Tag change/removal:
> 
>    When there is a change in the node administrative tag TLV or removal/
>    addition of a TLV in any instance of the RI-LSA, implementations MUST
>    take appropriate measures to update its state according to the
>    changed set of tags.  Exact actions depend on features working with
>    administrative tags and is outside of scope of this specification.
> 
> Inability to interoperably remove a tag value (e.g., distribute the 
> update that tag X no longer applies to node Q) seems like a 
> significant omission, but I'm not a routing expert, so I'll defer to 
> the WG's and ADs' judgment on the importance of this.  At a minimum, 
> the rationale for not specifying an interoperable tag value removal 
> mechanism ought to be added to this document.
> 
> [D] No management support
> 
> From OPS-Dir Q&A: At a minimum, reporting of tag values ought to be 
> defined via an OSPF MIB extension or analogous functionality.
> 
> --- Nits/editorial comments: ----
> 
> -- 1.  Introduction
> 
> The Abstract says that the tags are for "route and path selection"; 
> the Introduction should also say that.  Suggestion - at the end of 
> this sentence in the first paragraph:
> 
>    It is useful to assign a per-node administrative tag to a router in
>    the OSPF domain and use it as an attribute associated with the node.
> 
> add the text "for route and path selection".  This will help with the 
> second sentence in the second paragraph:
> 
>    Path selection is a functional set
>    which applies both to TE and non-TE applications and hence new TLV
>    for carrying per-node administrative tags is included in Router
>    Information LSA [RFC4970] .
> 
> If "path selection" and "functional set" are specific terms with 
> specialized meaning in OSPF context, that sentence is fine as-is, 
> otherwise it would read better if it began with:
> 
>    Route and path selection functionality applies to both ...
> 
> -- 3.1.  TLV format
> 
>    Type : TBA, Suggested value 10
> 
> Please add an RFC Editor Note asking the RFC Editor to replace this 
> with the actual IANA-assigned value.
> 
> -- 3.2.  Elements of procedure
> 
> While it's obvious that tag usage should be confined to the 
> administrative domain that understands the tag, it's worth stating.  
> At the end of this
> sentence:
> 
>    Interpretation of tag values is specific to the administrative domain
>    of a particular network operator.
> 
> I'd suggest adding:
> 
>    , and hence tag values SHOULD NOT be propagated outside the
>    administrative domain to which they apply.
> 
> -- 4.4.  Mobile back-haul network service deployment
> 
> Please expand "eNodeB" acronym on first use.
> 
> -- 4.5.  Explicit routing policy
> 
> In Figure 3:
> - The link from the leftmost pair of A nodes to the pair of T nodes
>    do not have link weights.
> - The link from the left R node to the left T node does not have a
>    link weight
> - The following example of an explicitly routed policy:
> 
>       - Traffic from A nodes to I nodes must not go through R and T
>               nodes
> 
>     prevents the leftmost pair of A nodes from sending traffic to the
>     I nodes.  Was this "black hole" intended as part of the example?
> 
> Also: "explicitly routed policies" -> "explicit routing policies"
> 
> - 5. Security considerations
> 
> I'd add discussion that advertisement of tag values for one 
> administrative domain into another risks misinterpretation of the tag 
> values (if the two domains have assigned different meanings to the 
> same values), which may have undesirable and unanticipated side effects.
> 
> In addition, injection of tag values from the outside (e.g., forge 
> OSPF traffic that appears to be from a node in the domain and carries 
> administrative tag values) is at least a possible denial-of-service 
> attack vector, and could also be used for more nefarious purposes 
> (e.g., reroute otherwise unobservable [to the attacker] VPN traffic 
> via a route where the attacker can observe it).
> 
> idnits 2.13.02 did not find any nits.
> 
> ---- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ----
> 
> A.1.2.  Has installation and initial setup been discussed?
> A.1.5.  Has the impact on network operation been discussed?
> A.1.6.  Have suggestions for verifying correct operation been discussed?
> 
>       No - given the impact that these tags could have on route and path
>               computation, likely implementations will be powerful "guns"
>               with which network operators can readily shoot themselves
>               in far more than just their "feet."  These
>               considerations would have to be documented based on the
>               specific uses made of these tags by specific implementations
>               and deployments.  All of that appears to be outside the scope
>               of this draft.
> 
> A.1.7.  Has management interoperability been discussed?
> 
>       No - at a minimum, reporting of tag values ought to be defined
>               via an OSPF MIB extension or analogous functionality.
>               This is minor issue [D].
> 
> A.1.8.  Are there fault or threshold conditions that should be reported?
> 
>       Yes, but they're implementation-specific - see response to
>               A.1.[2,5,6] above.
> 
> A.2.  Management Considerations
>    Do you anticipate any manageability issues with the specification?
> 
>       Yes, manageability has been largely ignored.
> 
> A.3.  Documentation
> 
>    Is an operational considerations and/or manageability section part of
>    the document?
> 
>       No.
> 
>    Does the proposed protocol have a significant operational impact on
>    the Internet?
> 
>       Yes, the anticipated uses will.
> 
>    Is there proof of implementation and/or operational experience?
> 
>       Nothing was stated in the draft or shepherd write-up.
> 
> As an OPS-Dir member, I'm concerned by the above RFC 5706 answers, and 
> in particular treating all operational issues as vendor- and/or 
> operator-specific.  One possible alternative would be to scope the 
> draft down to interoperably specify what's needed for LFA, as 
> indicated by this answer from the Shepherd write-up:
> 
> (9) 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?
> 
>       There is consensus from the WG and others outside the WG that
>       this document can progress. It complements work done on LFA
>       manageability in the RTG Working Group.
> 
> Another alternative could be Experimental RFC status for the full tag 
> mechanism (e.g., to figure out what it'll be used for in practice, how 
> and why) rather than Proposed Standard.
> 
> This is major issue [1].
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer EMC Corporation, 176 South St., 
> Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email protected]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
Title: Diff: draft-ietf-ospf-node-admin-tag-07.txt - draft-ietf-ospf-node-admin-tag-08.txt
Content-Type: text/html
< draft-ietf-ospf-node-admin-tag-07.txt   draft-ietf-ospf-node-admin-tag-08.txt >
Open Shortest Path First IGP S. Hegde Open Shortest Path First IGP S. Hegde
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Intended status: Standards Track R. Shakir Intended status: Standards Track R. Shakir
Expires: April 11, 2016 Individual Expires: April 13, 2016 Individual
A. Smirnov A. Smirnov
Cisco Systems, Inc. Cisco Systems, Inc.
Z. Li Z. Li
Huawei Technologies Huawei Technologies
B. Decraene B. Decraene
Orange Orange
October 9, 2015 October 11, 2015
Advertising per-node administrative tags in OSPF Advertising per-node administrative tags in OSPF
draft-ietf-ospf-node-admin-tag-07 draft-ietf-ospf-node-admin-tag-08
Abstract Abstract
This document describes an extension to OSPF protocol to add an This document describes an extension to OSPF protocol to add an
optional operational capability, that allows tagging and grouping of optional operational capability, that allows tagging and grouping of
the nodes in an OSPF domain. This allows simplification, ease of the nodes in an OSPF domain. This allows simplification, ease of
management and control over route and path selection based on management and control over route and path selection based on
configured policies. This document describes an extension to OSPF configured policies. This document describes an extension to OSPF
protocol to advertise per-node administrative tags. The node-tags protocol to advertise per-node administrative tags. The node-tags
can be used to express and apply locally-defined network policies can be used to express and apply locally-defined network policies
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 11, 2016. This Internet-Draft will expire on April 13, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 2, line 43
3.2. Elements of procedure . . . . . . . . . . . . . . . . . . 4 3.2. Elements of procedure . . . . . . . . . . . . . . . . . . 4
4. Applications . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Applications . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Service auto-discovery . . . . . . . . . . . . . . . . . 6 4.1. Service auto-discovery . . . . . . . . . . . . . . . . . 6
4.2. Fast-Re-routing policy . . . . . . . . . . . . . . . . . 6 4.2. Fast-Re-routing policy . . . . . . . . . . . . . . . . . 6
4.3. Controlling Remote LFA tunnel termination . . . . . . . . 7 4.3. Controlling Remote LFA tunnel termination . . . . . . . . 7
4.4. Mobile back-haul network service deployment . . . . . . . 8 4.4. Mobile back-haul network service deployment . . . . . . . 8
4.5. Explicit routing policy . . . . . . . . . . . . . . . . . 9 4.5. Explicit routing policy . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Operational Considerations . . . . . . . . . . . . . . . . . 11 6. Operational Considerations . . . . . . . . . . . . . . . . . 11
7. Manageability Considerations . . . . . . . . . . . . . . . . 11 7. Manageability Considerations . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
It is useful to assign a per-node administrative tag to a router in It is useful to assign a per-node administrative tag to a router in
the OSPF domain and use it as an attribute associated with the node. the OSPF domain and use it as an attribute associated with the node.
The per-node administrative tag can be used in variety of The per-node administrative tag can be used in variety of
applications, for ex: - Traffic-engineering applications to provide applications, for ex: - Traffic-engineering applications to provide
different path-selection criteria, - Prefer or prune certain paths in different path-selection criteria, - Prefer or prune certain paths in
Loop Free Alternate (LFA) backup selection via local policies. Loop Free Alternate (LFA) backup selection via local policies.
skipping to change at page 4, line 35 skipping to change at page 4, line 35
of tags advertised. of tags advertised.
Value: A sequence of multiple 4 octets defining the administrative Value: A sequence of multiple 4 octets defining the administrative
tags. At least one tag MUST be carried if this TLV is included in tags. At least one tag MUST be carried if this TLV is included in
the RI-LSA. the RI-LSA.
3.2. Elements of procedure 3.2. Elements of procedure
Meaning of the Node administrative tags is generally opaque to OSPF. Meaning of the Node administrative tags is generally opaque to OSPF.
Router advertising the per-node administrative tag (or tags) may be Router advertising the per-node administrative tag (or tags) may be
configured to do so without knowing (or even explicitly supporting) configured to do so without knowing (or even without supporting
functionality implied by the tag. processing of) functionality implied by the tag.
Interpretation of tag values is specific to the administrative domain Interpretation of tag values is specific to the administrative domain
of a particular network operator, and hence tag values SHOULD NOT be of a particular network operator, and hence tag values SHOULD NOT be
propagated outside the administrative domain to which they apply. propagated outside the administrative domain to which they apply.
The meaning of a per-node administrative tag is defined by the The meaning of a per-node administrative tag is defined by the
network local policy and is controlled via the configuration. If a network local policy and is controlled via the configuration. If a
receiving node does not understand the tag value or does not have a receiving node does not understand the tag value or does not have a
local policy corresponding to the tag, it ignores the specific tag local policy corresponding to the tag, it ignores the specific tag
and floods the RI LSA without any change as defined in [RFC4970]. and floods the RI LSA without any change as defined in [RFC4970].
skipping to change at page 5, line 21 skipping to change at page 5, line 21
AND tag B are present), they MUST NOT be reliant upon the order of AND tag B are present), they MUST NOT be reliant upon the order of
the tags (i.e., all policies should be considered commutative the tags (i.e., all policies should be considered commutative
operations, such that tag A preceding or following tag B does not operations, such that tag A preceding or following tag B does not
change their outcome). change their outcome).
To avoid incomplete or inconsistent interpretations of the per-node To avoid incomplete or inconsistent interpretations of the per-node
administrative tags the same tag value MUST NOT be advertised by a administrative tags the same tag value MUST NOT be advertised by a
router in RI LSAs of different scopes. The same tag MAY be router in RI LSAs of different scopes. The same tag MAY be
advertised in multiple RI LSAs of the same scope, for example, OSPF advertised in multiple RI LSAs of the same scope, for example, OSPF
Area Border Router (ABR) may advertise the same tag in area-scope RI Area Border Router (ABR) may advertise the same tag in area-scope RI
LSAs in multiple areas connected to the ABR. LSAs in multiple areas connected to the ABR. If a node
administrative tag is received in different scopes, the conflicting
tag SHOULD not be used and this situation SHOULD be logged as an
error including the tag with conflicting scopes and the
originator(s).
The per-node administrative tags are not meant to be extended by the The per-node administrative tags are not meant to be extended by the
future OSPF standards. The new OSPF extensions MUST NOT require use future OSPF standards. The new OSPF extensions MUST NOT require use
of per-node administrative tags or define well-known tag values. of per-node administrative tags or define well-known tag values.
Node administrative tags are for generic use and do not require IANA Node administrative tags are for generic use and do not require IANA
registry. The future OSPF extensions requiring well known values MAY registry. The future OSPF extensions requiring well known values MAY
define their own data signalling tailored to the needs of the feature define their own data signalling tailored to the needs of the feature
or MAY use capability TLV as defined in [RFC4970]. or MAY use capability TLV as defined in [RFC4970].
Being part of the RI LSA, the per-node administrative tag TLV must be Being part of the RI LSA, the per-node administrative tag TLV must be
skipping to change at page 11, line 20 skipping to change at page 11, line 20
geographical location or other sensitive information. As indicated geographical location or other sensitive information. As indicated
in [RFC2328] and [RFC5340] OSPF authentication mechanisms do not in [RFC2328] and [RFC5340] OSPF authentication mechanisms do not
provide confidentiality and the information carried in node provide confidentiality and the information carried in node
administrative tags could be leaked to an IGP snooper. administrative tags could be leaked to an IGP snooper.
Advertisement of tag values for one administrative domain into Advertisement of tag values for one administrative domain into
another risks misinterpretation of the tag values (if the two domains another risks misinterpretation of the tag values (if the two domains
have assigned different meanings to the same values), which may have have assigned different meanings to the same values), which may have
undesirable and unanticipated side effects. undesirable and unanticipated side effects.
[RFC4593] and [RFC6863] discuss the generic threats to routing
protocols and OSPF respectively. These security threats are also
applicable to the mechanisms described in this document.OSPF
authentication described in [RFC2328] and [RFC5340] or extended
authentication mechanisms described in [RFC7474] or [RFC7166] SHOULD
be used in deployments where attackers have access to the physical
networks and nodes included in the OSPF domain are vulnerable.
6. Operational Considerations 6. Operational Considerations
Operators can assign meaning to the node administrative tags which is Operators can assign meaning to the node administrative tags which is
local to the operator's administrative domain. The operational use local to the operator's administrative domain. The operational use
of node administrative tags is analogical to the IS-IS prefix tags of node administrative tags is analogical to the IS-IS prefix tags
[RFC5130] and BGP communities [RFC1997]. Operational discipline and [RFC5130] and BGP communities [RFC1997]. Operational discipline and
procedures followed in configuring and using BGP communities and ISIS procedures followed in configuring and using BGP communities and ISIS
Prefix tags is also applicable to the usage of node administrative Prefix tags is also applicable to the usage of node administrative
tags. tags.
skipping to change at page 13, line 33 skipping to change at page 13, line 42
[I-D.ietf-rtgwg-policy-model] [I-D.ietf-rtgwg-policy-model]
Shaikh, A., [email protected], r., D'Souza, K., and C. Chase, Shaikh, A., [email protected], r., D'Souza, K., and C. Chase,
"Routing Policy Configuration Model for Service Provider "Routing Policy Configuration Model for Service Provider
Networks", draft-ietf-rtgwg-policy-model-00 (work in Networks", draft-ietf-rtgwg-policy-model-00 (work in
progress), September 2015. progress), September 2015.
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<http://www.rfc-editor.org/info/rfc1997>. <http://www.rfc-editor.org/info/rfc1997>.
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 4593, DOI 10.17487/RFC4593,
October 2006, <http://www.rfc-editor.org/info/rfc4593>.
[RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy
Control Mechanism in IS-IS Using Administrative Tags", Control Mechanism in IS-IS Using Administrative Tags",
RFC 5130, DOI 10.17487/RFC5130, February 2008, RFC 5130, DOI 10.17487/RFC5130, February 2008,
<http://www.rfc-editor.org/info/rfc5130>. <http://www.rfc-editor.org/info/rfc5130>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286, IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008, DOI 10.17487/RFC5286, September 2008,
<http://www.rfc-editor.org/info/rfc5286>. <http://www.rfc-editor.org/info/rfc5286>.
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
According to the Keying and Authentication for Routing
Protocols (KARP) Design Guide", RFC 6863,
DOI 10.17487/RFC6863, March 2013,
<http://www.rfc-editor.org/info/rfc6863>.
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 7166,
DOI 10.17487/RFC7166, March 2014,
<http://www.rfc-editor.org/info/rfc7166>.
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
"Security Extension for OSPFv2 When Using Manual Key
Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
<http://www.rfc-editor.org/info/rfc7474>.
Authors' Addresses Authors' Addresses
Shraddha Hegde Shraddha Hegde
Juniper Networks, Inc. Juniper Networks, Inc.
Embassy Business Park Embassy Business Park
Bangalore, KA 560093 Bangalore, KA 560093
India India
Email: [email protected] Email: [email protected]
Rob Shakir Rob Shakir
Individual Individual
Email: [email protected] Email: [email protected]
Anton Smirnov Anton Smirnov
Cisco Systems, Inc. Cisco Systems, Inc.
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
 End of changes. 12 change blocks. 
9 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ 
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf

Reply via email to