Re: [secdir] secdir review of draft-ietf-ospf-node-admin-tag-05

[Shraddha Hegde <[e-mail]>]

Acee,

<---snipped to open points--->


--------------------------------------------------------------------------------------------------------------------------------------------------

>> <Shraddha> Could you pls elaborate the case. I don't quite understand 
>> why the ABR in a stub/NSSA area would generate or receive RI LSAs 
>> with different scopes.I think it's perfectly valid to flood the AS 
>> scoped RI LSAs into the stub / NSSA area.
>
>Acee, I think this is a question for you.

Yeah - I missed this without E-mail quoting…

Shraddha, 

AS-scoped LSAs are not flooded into stub or NSSA areas. So, if an ABR is going to advertise tags to its attached areas and the rest of the OSPF Routing domain, it will need to originate the LSA at different scopes.

<Shraddha> Acee,  I think restricting  AS scoped RI LSA into NSSA /stub areas will have many issues.
                                      If a non-ABR router from other area originates RI LSA with node tag and the specific application needs the 
                                      Tag to be available in the entire OPF domain, how will the stub/NSSA area routers receive it?
                                      I think this discussion is equally relevant to 4970bis.
                                       I don't see a reason why AS scoped RI LSA should be restricted in stub/NSSA.
                                        RI LSAs do not contain any route information so it's not going to be huge in number.
                                      
                                         





-----Original Message-----
From: Acee Lindem (acee) [mailto:[e-mail]] 
Sent: Wednesday, October 14, 2015 4:17 AM
To: Benjamin Kaduk <[e-mail]>; Shraddha Hegde <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: secdir review of draft-ietf-ospf-node-admin-tag-05

See inline. 

On 10/13/15, 6:27 PM, "Benjamin Kaduk" <[e-mail]> wrote:

>Thanks, Shraddha and Acee, for helping me find some of the context I 
>was missing.
>
>On Sun, 11 Oct 2015, Shraddha Hegde wrote:
>
>>
>> Thanks Ben for detailed review comments.Thanks Acee for chiming-in.
>> Few more explanations in-line.
>>
>> -----Original Message-----
>> From: Acee Lindem (acee) [mailto:[e-mail]]
>> Sent: Sunday, October 11, 2015 1:04 AM
>> To: Benjamin Kaduk <[e-mail]>; [e-mail]; [e-mail]; 
>>[e-mail]
>> Subject: Re: secdir review of draft-ietf-ospf-node-admin-tag-05
>>
>> Hi Ben,
>>
>> As the document shepherd and a long-time OSPF contributor, I’m going 
>> to try and sort out some of your comments. Note that route tagging 
>> has been in use for decades and this document is merely extending the 
>> administrative policies advertisement to the node level.
>
>Good to know; I didn't get to look at many updates past the core OSPFv2 
>spec.
>
>> On 10/9/15, 4:52 PM, "Benjamin Kaduk" <[e-mail]> wrote:
>>
>> >I have reviewed this document as part of the security directorate's 
>> >ongoing effort to review all IETF documents being processed by the 
>> >IESG.  These comments were written primarily for the benefit of the 
>> >security area directors.  Document editors and WG chairs should 
>> >treat these comments just like any other last call comments.
>> >
>> >I will preface these comments with a note that my routing background 
>> >is quite weak, and I needed to read RFC 2328 and RFC 4970 to have 
>> >enough context to be able to say much useful about what's going on 
>> >here; I may still be suffering from some misconceptions.
>> >
>> >On the whole, this document leaves me feeling unsatisfied; it spends 
>> >maybe three pages talking about the actual new protocol extension 
>> >and then gives four pages of example usage, all the while claiming 
>> >that the actual tag values are only meaningful within a single 
>> >administrative domain/network, are for generic use, and do not 
>> >require an IANA registry.  That is, it is trying to walk a middle 
>> >line between "this document allocates a value in the OSPF TLVs 
>> >registry for site-local use, use it as you will" and "this document 
>> >specifies a complete protocol extension for tagging OSPF nodes for 
>> >traffic engineering, LFA, and other purposes".  That is a hard 
>> >middle line to follow, and I am
>>not sure that this document does so successfully.
>> >I will not try to reopen the question of whether it would be better 
>> >to take one of the non-middle paths, and continue on the assumption 
>> >that this document will take the middle path.  I think there are a 
>> >few things that are missing before this document should be 
>> >published, and that it might be worth considering a more drastic 
>> >restructuring as
>>well.
>> >
>> >It would probably be good to include some text with the reasoning 
>> >behind the choice of the "middle line" -- the current text 
>> >attempting to enforce it, "new OSPF extensions MUST NOT require use 
>> >of per-node administrative tags or define well-known tag values", 
>> >seems unenforcable, as a future RFC updating this one could just 
>> >remove that
>>restriction.
>>
>> The intent here is that this TLV is to be solely for locally defined 
>> policies. If there were to be a TLV for well-known tags and policies, 
>> this could be accomplished with a separate OSPF RI TLV. I agree that 
>> the normative text should be softened from “MUST NOT” to “are not 
>> expected to”.
>>
>> <Shraddha> There was a long discussion on the mailing list on whether 
>> we should allow well defined values for the admin tags majority 
>> consensus was that we should not allow any standard values for node 
>> admin tags and in future if such a requirement arises it'll go as new 
>> feature in RI TLV as Acee already mentioned. I am trying to 
>> understand why the text need to be softened when any future 
>> standardization would need altogether a new document and will not require any changes to this document.
>
>I suggested that the text be softened because the current statement 
>does not have any practical effect.  It's trying to place restrictions 
>on what {the set of future RFCs that update this document} can do, but 
>any document in that set could remove such a restriction and override 
>it at the same time.
>
>I think it would be good to have a note in section 2 to the effect that 
>"these administrative tags are solely for use within an administrative 
>domain and are their interpretation is a matter of local policy.  It is 
>expected that values will not be portable across administrative domains".
>I know that this topic is covered later in the document, but having it 
>early would help set the stage for the rest of the document.
>
>> >It looks like there's now an -06, but the changes from the -05 are 
>> >not significant.  The security considerations in the -05 correctly 
>> >note what are essentially privacy considerations regarding the 
>> >contents of the admin tags.  However, it seems like there are also 
>> >potential security considerations on the actual operation of the 
>> >network that are not discussed here, nor in RFC 2328 (OSPFv2) or RFC 
>> >5340 (OSPFv3).  RFC 5340's security considerations explicitly 
>> >disclaims protections against compromised, malfunctioning, or 
>> >misconfigured routers, deferring to RFC 4593, "Generic Threats to 
>> >Routing Protocols".  I believe that the security considerations of 
>> >this document should address, either directly or indirectly, 
>> >protections against compromised, malfunctioning, or misconfigured 
>> >routers, and additionally protection against malicious actors with 
>> >access to the layer-3 network (and maybe lower layers as well).
>> >
>> >That probably means mentioning RFC 4593 directly, or maybe just 
>> >pointing out that RFC 5340 does so.  There are still additional 
>> >considerations introduced by this document, though; unfortunately, 
>> >because the bulk of the interpretation of the admin tags is left to 
>> >the site administrator, it is hard to give a comprehensive security 
>> >analysis, but the examples and the protocol description itself do 
>> >give
>>some areas for consideration.
>>
>> The document could reference RFC 4593/RFC 6863 and state that 
>> authentication as specified in RFC 7474 or RFC 7166 SHOULD be used in 
>> deployments where attackers have access to the physical networks 
>> included in the OSPF domain are vulnerable.
>> <Shraddha> ok. Updating the Security consideration section
>
>Thanks.
>
>>
>> >
>> >The RI LSAs carrying administrative tags can be at link-, area-, or 
>> >AS-level scope; an administrator assigning tag values and associated 
>> >policies should consider what would happen if a given tag was 
>> >advertised at a different scope than intended.  Compliant 
>> >implementations MUST NOT generate the same tag at different scopes, 
>> >but a receiver would need to take some action if it happened, 
>> >whether due to network glitch or malicious action -- what should they do?
>>
>> I’m not an author, but this is what I’d recommend:
>>
>>    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).
>> <Shraddha> Updated the document with above statement.
>>
>> There is a case that must be allowed - the same tag could be received 
>> by an ABR at both the AS scope and the area scope in a stub or NSSA area.
>> <Shraddha> Could you pls elaborate the case. I don't quite understand 
>> why the ABR in a stub/NSSA area would generate or receive RI LSAs 
>> with different scopes.I think it's perfectly valid to flood the AS 
>> scoped RI LSAs into the stub / NSSA area.
>
>Acee, I think this is a question for you.

Yeah - I missed this without E-mail quoting…

Shraddha, 

AS-scoped LSAs are not flooded into stub or NSSA areas. So, if an ABR is going to advertise tags to its attached areas and the rest of the OSPF Routing domain, it will need to originate the LSA at different scopes.



>
>> >Another potential issue lies in the "stickiness" of the admin tags 
>> >-- the text "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" seems to mean that once a tag is 
>> >set, it cannot
>> >(easily) be unset.  Would force-expiring an LSA be enough to reset 
>> >the tag, or something else?
>>
>> Yes - this is standard for any OSPF LSA. However, since the OSPF RI 
>> LSA may include other TLVs or even other tags, a tag could also be 
>> withdrawn by reoriginating the RI LSA without the TLV or with a TLV 
>> that doesn’t include the withdrawn tag.
>
>I may still be confused, but I did not interpret the text in that way.
>That is, the text about "all instances of the RI LSA originated by that 
>node".  (Which I changed to "instances of RI LSAs" in my grammar edits, 
>possibly incorrectly if I'm still confused.)  I was interpreting the 
>word "instances" to include historical ones over time, so that even if 
>an RI LSA carrying a particular admin tag was replaced by a different 
>RI LSA for the same advertising router, the old one would still be an 
>instance of that RI LSA.  Going back to RFC 2328, I'm not sure what 
>exactly I had in mind in terms of ages and scopes and sequence numbers 
>that would cause this situation, but I somehow had it in my mind that 
>there could be multiple RI LSAs active at the same time that apply to a 
>given node, such as if the admin just added a new RI LSA containing 
>only the admin tag to augment the existing RI LSAs being sent.  Is that 
>possible?

In OSPF, a more-recent version or instance of an LSA will always supersede all previous instances of the same LSA.

>
>If there can only be one RI LSA that is "current" for a given node (at 
>a given scope?), then it seems like it would be useful to change the 
>text to explicitly say "all current instances" -- that would have 
>helped me as I read it.

I see the confusion is between instances of the same LSA in the general sense and multiple instances of the OSPF RI LSA. Refer to RFC 2328 section 13.1.  


>
>> > How disruptive would that be?  It would be helpful to see some 
>> >discussion of how a tag would be removed.
>>
>> I may of worked on OSPF for too long but this should be obvious to 
>> anyone implementing the draft from the specification.
>
>If it's simply a matter of re-issuing the RI LSA (I was not sure when I 
>was writing my review), then I agree it should be obvious.
>
>> <Shraddha> The below paragraph (from -07 version) is clear on this I 
>>hope.
>>
>> "When there is a change or removal of an administrative affiliation 
>>of a node,
>>    the node MUST re-originate the RI LSA with the latest set of node 
>>administrative tags.
>>    On the receiver, 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."
>
>This is definitely improved, but it does not do much to address the 
>issue I had in mind when I was writing my review.  However, it seems 
>like that issue is not actually an issue, so no further changes to this 
>text would be needed.
>
>
>> >
>> >That is particularly easy for an attacker when the null OSPF 
>> >authentication mechanism is in use (how common is that?  I saw some 
>> >websites indicating it was the default behavior, at least sometimes).
>> >I do not see a need to turn this document into "security 
>> >considerations for OSPF authentication", but maybe it is worth mentioning some things:
>> >the
>> >md5 scheme seems pretty week at this point (though probably not 
>> >trivially broken), the hmac-sha scheme of RFC 5709 is only from 
>> >2009, and RFC 7474 (only six months old) points out cases where both 
>> >are susceptible to replay attacks.  Just looking at the security 
>> >considerations of this document and the core OSPF v2/v3 specs does 
>> >not convey this to the reader, so I would like to see at least a 
>> >pointer to such considerations.  (The stance of RFC 2328 that "all 
>> >OSPF protocol
>>exchanges are authenticated"
>> >seems particularly disingenous given the presence of the null 
>> >authentication scheme.)
>>
>> I think both RFC 7474 and RFC 7176 should be referenced. The OSPF 
>> vulnerability to replay attacks to OSPFv2/OSPFv3 routers implementing 
>> these specifications is extremely small and has been reduced as much 
>> as practical. If you are still concerned, I suggest you discuss with 
>> Sam Hartman (also once affiliated with MIT).
>
>I am not especially concerned about this attack, I just noticed that 
>there was an RFC about it.  Since RFC 7474 was so recent, it made me 
>wonder how widely deployed the security fixes are today.

Correct - it is not widely implemented or deployed.

Thanks,
Acee

>
>> <Shraddha> Security consideration section updated with the reference 
>> to RFC 7474 and 7176.
>
>Thanks.
>
>> >
>> >There is also the possibility that an attacker could block delivery 
>> >of an LSA, causing a tag that should be set to not be seen.  This 
>> >seems unlikely for wired point-to-point links, but is more plausible 
>> >in other environments, such as radio links.  I think I can imagine 
>> >scenarios where this would cause drastic damage to the routing topology.
>>
>> The description and mitigation of such a generic threat doesn’t 
>>belong in a minor (though important) OSPF specification. The effect of 
>>blocking control traffic is never positive ;^). At least OSPF uses 
>>reliable flooding so it will be retransmitted.
>> <Shraddha> Agree with Acee on this.
>
>I had forgotten that OSPF flooding was reliable; I agree this does not 
>need to be explicitly called out in this document, since it's a general 
>routing concern.
>
>> >The parenthetical in section 3.2 wherein routers might advertise a 
>> >per-node aministrative tag "without knowing (or even explicitly
>> >supporting) functionality implied by the tag" seems potentially 
>> >dangerous, since it sounds like the routers in question are lying 
>> >about their capabilities.  Would the document suffer harm if the 
>> >parenthetical was removed?
>>
>> In my opinion, no harm to remove - misconfiguration is almost always 
>>an issue.
>> <Shraddha> It's perfectly valid for a node originate a tag when the 
>>node  itself does not Process any tags. I think the sentence needs to 
>>be  rephrased. Changing it as below.
>>
>> <t>Meaning of the Node administrative tags is generally opaque to 
>> OSPF. Router advertising the per-node administrative tag (or tags) 
>> may be configured to do so without knowing (or even without 
>> supporting processing of) functionality implied by the tag.</t>
>
>I think there is a question about whether this means that the router 
>doesn't need to know what feature the tag number means, or whether it 
>means that the router doesn't need to implement the feature indicated 
>by that tag value.  I read this text as being in the second case, but I 
>am interpreting your discussion about this text to mean that you think 
>it is covering the first case.  (Yes, there can be tag values that just 
>indicate an administrative grouping and there is no corresponding 
>functionality needed on the router, but there can also be tag values 
>that indicate "the router originating this RI LSA supports accepting targeted LDP sessions"
>-- a router will cause breakage if it sends such a tag but does not 
>actually support accepting targeted LDP sessions.)
>
>Based on this discussion, I think that what the parenthetical is trying 
>to say is that "the router originating the tag may not use that tag in 
>any of its processing decisions" -- is that correct?
>
>Changing the word "functionality" to "attributes" would cause me to 
>read the text as being in the first case I described above.
>
>(By the way, this paragraph had a lot of changes in my patch for 
>grammar; it might have been easier to apply that patch before making 
>further edits, to reduce the number of merge conflicts.  The grammar in 
>the quoted new text has several errors.)
>
>> >One reason I am unsatisfied by making the interpretation of the tag 
>> >values specific to an administrative domain is that a misconfigured 
>> >border router might erroneously use tag values from one domain on 
>> >the other side of the border.
>> > Perhaps the other damage from a router misconfigured in such a 
>> >fashion would dwarf the additional damage from the misinterpreted 
>> >tags and so my concern is invalid; I really can't say.
>>
>> Again, I don’t think misconfiguration needs to be covered - "emptor 
>>cavete”.
>
>A misconfigured router is by definition broken.  Such misconfiguration 
>can happen either by accident due to operator error, or maliciously, if 
>an attacker has compromised the system.  While it may not be necessary 
>to say that a broken router will not pass traffic the way it's supposed 
>to, if a misconfigured router can emit routing protocol messages that 
>affect the state of the network as a whole, not just its local 
>surroundings, that seems like an analysis that is appropriate for the 
>security considerations of a routing protocol document.  Now, I don't 
>have a good picture of specific examples of network-wide issues due to 
>the admin tag, but I think there's a large enough probability that it's 
>possible for such a thing to happen that I wanted to mention it in my 
>review comments.  Maybe there is not anything worth mentioning about it 
>in the security considerations section, but I don't think that 
>"misconfiguration doesn't need to be covered" addresses the concern I was attempting to raise.
>
>> <Shraddha> -07 version addresses this issue.
>>
>> "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."
>
>Thank you, that helps.
>
>> Thanks for the editorial review as well. Speak as WG chair, I 
>>appreciate this.
>
>You're welcome!
>
>-Ben