Hi Adrian, I think [D] is the most important of these open issues:
> > The stated > > "SHOULD" requirement for privacy of geographic information is troubling, as > > the > > use of "SHOULD" instead of "MUST implement" allows systems to be deployed > > that cannot be configured to provide that privacy. It may be possible to > > work > > around this by stating that geographic information MUST NOT be used when > > confidentiality protection is not implemented. > > I'll leave the authors to comment on this. In general, I agree with "MUST > implement" and disagree with an unqualified "SHOULD use" (a qualification > would > be "operators wishing to protect geographic information SHOULD use..."). I do > not agree with the "MUST NOT" in your final sentence. Operators MUST be free > to > throw their money around in the street if they want to. As we apparently agree on "MUST implement", that would cause the "MUST NOT" workaround in the final sentence to become irrelevant. The resulting requirements language would be "MUST implement" confidentiality and "SHOULD use" confidentiality with geographic information. Beyond this, item [C] effectively asks that analogous clarification of implementation vs. use be carried out on the other requirements. On further thought, the other two items may be nits: [B] > > > In general, a > > > routing protocol should have a robust response to partial loss of > > > communication/connectivity, > I think that a robust response to partial loss of communication that impacts > the > routing protocol should not be part of the routing protocol since the protocol > is possibly unable to communicate effectively. > > Maybe the document should give an example of such a robust response. IMHO this > is about raising alarms to the operator. The behavior of a routing protocol in only constructing routes based on what it can actually reach (e.g., based on currently visible advertisements) may be an example. > > [A] I remain surprised that the forwarding table in each node is not > > considered to > > be an attack target (i.e., asset to be protected). > > What did you have in mind? > Do you believe someone with a wrench might break into the router and steal the > routing table? :-) If an attacker can get in and rewrite the forwarding table as she sees fit, the fact that the routing protocol is distributing correct routes becomes irrelevant ;-). I think the countermeasures to protect the forwarding table are covered under physical device access and remote device access, but something still feels wrong about Figure 1 placing the forwarding table out of scope. Thanks, --David > -----Original Message----- > From: Adrian Farrel [mailto:[email protected]] > Sent: Monday, January 17, 2011 3:28 PM > To: Black, David; [email protected]; > [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected] > Cc: [email protected]; [email protected] > Subject: RE: Gen-ART review of draft-ietf-roll-security-framework-04 > > Hi David, > > Thanks for continuing to discuss. > > > [A] I remain surprised that the forwarding table in each node is not > considered to > > be an attack target (i.e., asset to be protected). > > What did you have in mind? > Do you believe someone with a wrench might break into the router and steal the > routing table? :-) > > The only access to the routing table is through the routing protocol and > management mechanisms. Given the scope, this draft only discusses the routing > protocol. > > Maybe this is as simple as saying *why* the routing protocol would be > protected, > rather than assuming that the protocol has to be protected? > > > [B] I did not see any discussion of: > > > > > In general, a > > > routing protocol should have a robust response to partial loss of > > > communication/connectivity, but within defined limits (obviously > >> a routing protocol is helpless against an attacker who can disable > > > all inter-node communication). > > > > That sort of robust response is probably part of the routing protocol itself > rather > > as opposed to being added security functionality that secures the routing > > protocol, but this should be discussed, especially as all of the security > features > > that support availability have "MAY" requirements in Section 6.4. > > I think that a robust response to partial loss of communication that impacts > the > routing protocol should not be part of the routing protocol since the protocol > is possibly unable to communicate effectively. > > Maybe the document should give an example of such a robust response. IMHO this > is about raising alarms to the operator. > > > [C] The draft does not distinguish requirements for implementation from > > requirements for usage (e.g., "MUST implement" & "MAY use" is a reasonable > > combination). Distinguishing requirements for protocol design from those > > for > > protocol deployment/usage is a good idea in general. That's a contributing > factor > > to the next issue. > > Requirements for use (even for security) are surely vain! All we can do is > describe what constitutes a conformant implementation. We can supplement that > by > saying that to avoid a specific security threat, an operator may/should/must > use > a specific feature. > > > [D] The level of confidentiality requirements remains open: > > > > > - The confidentiality and privacy requirements are SHOULD. Unless there > > > is > a > > > good reason not to do so, they both should be "MUST implement" (use > > > can be configured and/or negotiated). > > > > As I understand the discussion in the draft, the appropriate requirements > > statements are "MUST implement" and "SHOULD use" under specific > > circumstances (e.g., when geographic information is in use). The stated > > "SHOULD" requirement for privacy of geographic information is troubling, as > the > > use of "SHOULD" instead of "MUST implement" allows systems to be deployed > > that cannot be configured to provide that privacy. It may be possible to > > work > > around this by stating that geographic information MUST NOT be used when > > confidentiality protection is not implemented. > > I'll leave the authors to comment on this. In general, I agree with "MUST > implement" and disagree with an unqualified "SHOULD use" (a qualification > would > be "operators wishing to protect geographic information SHOULD use..."). I do > not agree with the "MUST NOT" in your final sentence. Operators MUST be free > to > throw their money around in the street if they want to. > > > In addition, I just noticed that the word "privacy" in this draft is not > connected to > > the concept of confidentiality - that connection should be made. > > > > idnits 2.12.05 did not find any nits. > > Cheers, > Adrian > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
