Re: [Gen-art] Gen-Art Early Review of draft-ietf-radext-dtls-07
Thanks Ben for the review! - JOuni On Nov 19, 2013, at 1:38 AM, Ben Campbell b...@nostrum.com wrote: 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. This is an early review at WGLC last call. Document: draft-ietf-radext-dtls-07 Reviewer: Ben Campbell Review Date: 2013-11-18 Summary: This draft is on the right track, but there are significant open issues that should be resolved before it progresses. [Note: This review is different from the usual Gen-ART review due to the fact that it's an early (as in prior to pubreq) review, and that the draft is intended to become an experimental RFC. The gen-ART review process is tuned for drafts at IETF last call or later. It's a little hard to figure out what criteria should be used for drafts at an earlier point in the life-cycle. That being said, I reviewed this as if it were near-final, and apologize if that turns out to be too strict for an early review. I used similar review criteria as I would for a standards-track draft, since this draft still specifies protocol with the hope of interoperable implementations. The only difference comes from a few comments explicitly about the experimental status of the draft.] *** Major issues: -- General: The draft needs an overhaul of it's use of normative language. There appears to be redundant (and possibly contradictory) language for the same requirements sprinkled throughout. There are also cases of normative language being used for internal implementation guidance, which is not appropriate as described by RFC 2119. (See the minor issues section for details--most of the instances would not qualify as major issues by themselves, but I think they constitute a major issue in the aggregate.) -- section 3, 2nd paragraph: ... long-term use of RADIUS/UDP is NOT RECOMMENDED. While I agree with the sentiment, that's not an appropriate assertion for an experimental RFC. It would either need to go into an standards-track update to the RADIUS spec, or a BCP. (Also applies to the reiteration in 10.1) *** Minor issues: -- General: It might be worth some text on why this is experimental rather than informational. Is there any plan to evaluate the implementation results? Is there an expectation that a future RADIUS/DTLS spec could become standards-track? Is there any plan to evaluate the outcome of this document? -- Section 1, 2nd paragraph: Isn't this true for almost any use of IPSec? Is there some specific reason this is worse for RADIUS than for other protocols? -- Section 1, 4th paragraph: The second sentence mentions that firewall rules do not need to be changed. The following sentence recommends a change to firewall rules. The firewall rule recommendations in the 3rd sentence seems odd, since it seems like any protocol over DTLS would pass. Also, does this imply a recommendation that firewalls with DPI be used in the first place, since the absence of such a firewall has the same effect as having one that doesn't enforce the protocol? (Is there a reason a protocol spec should recommend firewall rules in the first place, other than to mention places where certain firewall rules might prevent interfere with operation?) -- section 2.1, 5th paragraph (3rd paragraph after bullet list) : Implementations MUST support encapsulated RADIUS packets of 4096 in length... Please be more precise than MUST support. Specifically, does MUST support indicate you must support both sending and receiving of that size? (since 4096 would generally exceed PMTU even for RADIUS/UDP) -- 2.2 and children: I find this section confusing as to where to find the authoritative text. Some, but not all, of the material from 6614 is repeated as normative text in later sections. The description of this draft as applying 'semantic patches' to 6614 seems to imply you mean the 6114 text, with these patches applied, to be normative, which creates some potential conflicts. If, on the other hand, 2.2 (.x) is intended more as a informative description of the differences, please say so. -- 3, 1st paragraph: Can you elaborate on the resulting timeouts, lost traffic, and network instabilities? -- 3.1: The section describes UDP/2083 as the default port. But later sections describe port related behavior in a way that makes it it look like the impementations must always use 2083, which makes it more than just a default. Is the administrator allowed to choose some other port for any reason? If so, it might make more sense to refer to the port by role rather than number when discussing port related behavior. (I note that 6614 only mentions the port number in the initial assignment, the IANA considerations, and the appendix.) -- 3.2, last paragraph: Can you elaborate on the bid
Re: [Gen-art] Gen-ART Telechat review of draft-sin-sdnrg-sdn-approach-05.txt
Hello Suresh, Thanks for your review. We will update the draft in light of your comments, but please see inline a few responses. [snip] * Section 2.1 - Not sure if the word encoded is appropriate here. s/hardware-encoded/usually implemented in hardware/ [CJ] OK. - These two sentences are hard to read and it is not clear what point they are trying to make. Please consider rewording. As such, the current state-of-the-art tends to confirm the said separation, which rather falls under a tautology. [CJ] What is meant by this sentence is that data and control planes have always been separated from an implementation standpoint, hence the tautology: commercial routers use a (S/W-based) routing engine for route computation purposes, while packet forwarding functions are usually H/W encoded. But a somewhat centralized, controller-embedded, control plane for the sake of optimized route computation before FIB population is certainly another story. [CJ] One of the main arguments of SDN proponents is that (1) the control plane is separated from the data plane but, more importantly, (2) this separation assumes a (logically) centralized control plane, which allows the use of commodity H/W. From an implementation standpoint, this is different from current router technologies, although there has been some vendors in the past who tried to promote this kind of design (I remember Newbridge's Vivid technology at the end of the '90s, for example). I'm not too sure about how we can possibly re-word this, admittedly. * Section 3.1 Not sure what this sentence is trying to convey. Can you clarify? Some of these features have also been standardized (e.g., DNS-based routing [RFC1383] that can be seen as an illustration of separated control and forwarding planes or ForCES ([RFC5810][RFC5812])). [CJ] What is meant here is that so-called SDN features have been there for quite some time and some of them have been standardized, hence the couple of examples above. * Section 3.4 This direct access to some engines using a vendor-specific could be beneficial to performance but may increase configuration complexity (in opposition to the final goal in Section 4.1 of accommodating heterogeneous network technologies). It may be worthwhile to add some text to the following paragraph in this regard. [CJ] Fine by me, we'll add an extra sentence. Maintaining hard-coded performance optimization techniques is encouraged. So is the use of interfaces that allow the direct control of some engines (e.g., routing, forwarding) without requiring any in-between adaptation layer (generic objects to vendor-specific CLI commands for instance). * Section 3.5 This sentence is ambiguous OpenFlow is clearly not the next big thing Does this mean a) OpenFlow is certainly not the next best thing (or) b) It is not clear if OpenFlow will be the next best thing Can you please clarify? [CJ] option a is the right one. We'll reword accordingly. * Section 3.6 This sentence about non-goals is unclear. What are the respective software limitations? o Fully flexible software implementations, because the claimed flexibility will be limited by respective software and hardware limitations, anyway. CJ: The sentence means that there are S/W and H/W limitations respectively that will always restrict the scope of claimed flexibility - another tautology, if you will. * Section 4.5 This sentence is long and complex, and the exact point it is trying to make is not clear. Can you simplify/reword? For example: while the deployment of a network solely composed of OpenFlow switches within a data center environment is unlikely to raise FIB scalability issues given the current state-of-the-art, data center networking that relies upon complex, possibly IP-based, QoS- inferred, interconnect design schemes meant to dynamically manage the mobility of Virtual Machines between sites is certainly of another scale. CJ: Fair enough. We'll simplify the wording, e.g., DC networks that may rely upon OpenFlow switches are unlikely to raise FIB scalability issues. Conversely, DC interconnect designs that aim at dynamically managing VM mobility possibly based upon the enforcement of specific QoS policies may raise scalability issues. * Section 4.6 Can you clarify what risk is being assessed here? o Assessing whether SDN-labeled solutions are likely to obsolete existing technologies because of hardware limitations. CJ: the risk is both technical and economical. From a technical standpoint, the ability to dynamically provision resources as a function of the services to be delivered may be incompatible with legacy routing systems because of H/W limitations. From an economical standpoint, this is about assessing the impact of deploying SND solutions for the sake of flexibility and automation on CapEx and OpEx budgets. Editorial = * Section 3.3
[Gen-art] Gen-ART review for draft-ietf-soc-load-control-event-package-10.txt
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. Document: draft-ietf-soc-load-control-event-package-10.txt Reviewer: Dan Romascanu Review Date: 11/19/13 IETF LC End Date: 11/19/13 IESG Telechat date: (if known) Summary: The document is ready, there are a few minor issues which are worth being clarified. Major issues: None. Minor issues: 1. I had some issues with the examples in the introduction. There are three common examples of legitimate short-term increases in call volumes. Viewer-voting TV shows or ticket giveaways may generate millions of calls within a few minutes. Call volume may also spike during special holidays such as New Year's Day and Mother's Day. Finally, callers may want to reach friends and family in natural disaster areas such as those affected by hurricanes. When possible, only calls traversing overloaded servers should be throttled under those conditions. I am not sure what the term 'legitimate' means here. I would rather say that the paragraph rather deals with increases in call volumes that happen at predictable moments in time (assuming here that the time a hurricane hits a certain geographic zone is predicted by weather forecasters). There would be one more example to add here - the end-of-season (of month, of year) peaks in phone orders. There is another category of unpredicted/unpredictable events which is mentioned a few paragraphs later, and which puts a slightly different set of requirements. The list already includes earthquakes or terrorist attacks, it may add the increase in traffic on call centers that provide troubleshooting services when a mass service fails. A slight re-organization of this text would improve clarity. 2. In Section 4 - Design Requirements: o The solution should draw upon experiences from related PSTN mechanisms where applicable. I have no clue what this section means in the absence of a reference and/or a list of what PSTN mechanisms are to be considered. Also, in the same list of requirements I miss an explicit requirement on persistency. 3. In Section 5.4 in the compliance list - I believe that compliance to the SIP Event Notification Framework [RFC 6665] should be added. Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] #520, was: Fwd: Gen-Art review of draft-ietf-httpbis-p2-semantics-24 with security considerations
Hi Mark Julian, I understand your concerns, but I think a *couple of sentences* could go a long way in terms of awareness of these issues for developers and implementers. This type of advice is on par with the current security sections added for privacy concerns where you get close to the topic already. If you read through Section 9.3 and consider predicable information (ID numbers or other distinguishing information whether or not it is PII), it is easy enough to plug in other values into a URI and possibly expose information that should not have been accessible (with a bad configuration - and they do exist). It would be good to make it clear that this is not a good thing and can be one type of injection attack. You are also already covering full path disclosure in 9.1, which is a type of injection attack. Julian had requested some text, here are a couple of proposed sentences. In the last sentence of the first paragraph, add in 'predicable' to the list of items at the end of the sentence. The I suggest adding text along the following lines: Injection attacks, such as SQL and full path disclosure should be prevented in URIs to avoid unintended access. The broader set of injection attacks is out-of-scope for this document, however awareness is important for web developers. OWASP lists injection attacks as the highest risk and defines the more broad set of injection attacks as follows: Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. (Link to OWASP top 10, it is also provided as a PDF if that reference is better: https://www.owasp.org/index.php/Top_10_2013-Top_10) This suggestion is meant to raises awareness and tie into the existing descriptions that get close to this topic. Thank you, Kathleen -Original Message- From: Mark Nottingham [mailto:m...@mnot.net] Sent: Monday, November 18, 2013 9:12 PM To: Julian Reschke Cc: HTTP Working Group; Moriarty, Kathleen Subject: Re: #520, was: Fwd: Gen-Art review of draft-ietf-httpbis-p2-semantics-24 with security considerations On 19/11/2013, at 4:46 AM, Julian Reschke julian.resc...@gmx.de wrote: Section 9.3: You may want to include information that informs developers and users of SQL injection attacks. Fields are still included in some URIs that link you to pages directly that contain personal information using consistent identifiers. It would be helpful as this is still one of the biggest attack vectors. A quick search on SQL injection URL will provide additional information for inclusion in the write up. You mention GET-based forms in section 9.3, but it doesn't mention SQL injection attacks and information in the URIs. Since this is so prevalent still, I think it is important to call out explicitly. Not convinced. From an HTTP point of view, URIs are just opaque identifiers. Also, there are many kinds of injection attacks. Should we list them all (XML, javascript...)? +1 - SQL doesn't have anything to do with HTTP, and even though it is used often in conjunction with the protocol, it's an implementation-specific choice. For example, I don't use any SQL on my Web site, and am very happy about that :) Cheers, -- Mark Nottingham http://www.mnot.net/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-art review of draft-ietf-httpbis-method-registrations-14
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) No, it doesn't (why does idnits think so?) Oh, geez, you really want to know? Look at the history of the document: - Up through version -02, it was marked as updates httpbis part 2. - httpbis part 2 version -00 was posted before RFC 5378. - The current version of httpbis part 2 does not include all the authors that were included in the -00 version. Through some combination of that history, it's possible that this document has text from httpbis part 2 version -00, and that not all the original authors have signed off on that. So idnits is just raising a flag. As it says, if this isn't a problem, then it isn't a problem. Kathleen was just pointing out that idnits raised the flag, and asked you to check. You checked. All is well. (We all have to remember that idnits is only a tool) ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) RFC 2068 currently is the only document that defines LINK/UNLINK. The only thing we can do here is to declare all references in the registrations to be informative, but I really really don't see why it would matter here. Again, only a tool. This is not an issue. We have references to obsolete documents periodically, and that's fine. This is fine. On the other hand, we have many occasions where documents become obsolete after they're put in as references, so it's good to check. Again, you checked, and all is well. No need to wrap ourselves around that further. Barry ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-6man-ug-05
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. Document: draft-ietf-6man-ug-05 Reviewer: Martin Thomson Review Date: 2013-11-19 IETF LC End Date: 2013-11-28 IESG Telechat date: Not yet available Summary: The document is ready for publication as Proposed Standard. This document describes the problems arising from the pseudo-semantics assigned to the 'u' and 'g' bits of EUI-64-derived interface identifiers and declares these semantics void. I found the thoroughness of the justification a little excessive, but I can appreciate why it needs to be that way :) ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Telechat Review of draft-ietf-karp-ops-model-09
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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-karp-ops-model-09 Reviewer: Ben Campbell Review Date: 2013-11-19 IESG Telechat date: 2013-11-21 Summary: This draft is ready for publication as an informational RFC. All the issues from my last call review, have been addressed, save 1 below. Major issues: None Minor issues: -- My last call review included a concern about a possible need for additional guidance around the idea of continuing to operate with an expired key. The author mentioned that the draft reflect working group consensus, and I'm okay with that. But I still think there might be value in documenting the tradeoffs that the working group considered reaching that consensus. I'm not sure that our correspondence on that matter reached a conclusion. I'm pasting the relevant discussion below: genart -- section 3.2, last paragraph: Implementations SHOULD genart permit a configuration i n which if no unexpired key is genart available, existing security associations continu e using genart the expired key with which they were established. genart This may need further guidance. For example, it seems risky genart to do this silently. I think this was explicitly discussed in the WG and is where we got in our discussions. There's discussion of alerts for security events elsewhere. However I think the current text represents a fairly informed WG consensus. You are correct that there is separate text on notification of security events (section 6.2), and that even mentions certificate expiration. But it doesn't explicitly mention continuing to use an expired key. I think that's important enough that it should be explicitly considered. If it was explicitly discussed in the working group, it would be helpful to document the trade-offs that were discussed. Nits/editorial comments: -- idnits reports some outdated references, please check. -- section 1, paragraph 4, 2nd sentence: s/routers/Routers ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Telechat Review of draft-ietf-ipfix-data-link-layer-monitoring-07
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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ipfix-data-link-layer-monitoring-07 Reviewer: Ben Campbell Review Date: 2013-11-19 IESG Telechat date: 2013-11-21 Summary: This draft is essentially ready for publication as a standards track RFC. However, there is one issue that I unfortunately missed in my last call review of version 06 that should be considered prior to publication. Major issues: None Minor issues: There's a normative downref to RFC 2804, which is informational. That seems a really odd draft for a normative reference. There may be precedent, as I note that RFC 5477, referenced here for security considerations, does the same thing. I apologize for bringing this up this late in the process--I missed it in my earlier review at last call. As I understand it the context is that certain data elements can include payload octets. This is subject to the security considerations in 5477, which basically say don't include too much, because of guidance from 2804. But my reading of 2804 does not give specific guidance things like how much payload one can capture before it becomes too much. I think the simplest solution would be to keep the reference to the 5477 security considerations, and reiterate that this model is not intended for gross capture of payloads, perhaps with an _informative_ reference to 2804. Nits/editorial comments: None ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-art telechat review of draft-ietf-mmusic-rfc2326bis-38.txt
I have been selected as an additional General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mmusic-rfc2326bis-38.txt Reviewer: Elwyn Davies Review Date: 2013/11/19 IESG Telechat date: 2013/11/21 Summary: This draft is ready for publication as a Standards Track RFC. My extensive last call comments on the main body of the draft have been thoroughly dealt with - thanks, Magnus and others. I didn't have time previously to review the appendices in detail. Below are quite a few nits relating to the appendices that can be dealt with during RFC Editor processing. (A couple of them are areas where a little extra clarification or explanation is needed rather than purely language issues). Major Issues: (none) Minor Issues: (none) Nits: General: agree on consistent use of either 'lower layer' or 'lower-layer'. s App A: s/how functions/how the functions/, s/syntex illegal line breaks/line breaks that are not allowed by the formal syntax but are needed/ ssA.1-A.4, paras just before message flow: In each case the example mentions 'movie' for the firsttime whereas the earlier txt just refers to 'media' It might be better just to stick to 'media'. sA.1: s/For purposes/For the purposes/, s/like the host/such as the host domain name/, s/equal value with date/to a value equal to the current date and time/ sA.3, para 1: s/crypto contexts to get a secured/cryptographic contexts to request and facilitate secured/, s/fetch this/fetch the media/, s/In the this session/In this session/, s/This is pipeline/These are pipelined/ sA.4, para 1: s/a bit more tweaks/a few more tweaks/ sA.7, para 1: s/clients request/client's request/ s App. B, para 1: s/response will returned/will be returned/ s App. B, para 2: s/If two or more is/If rwo or more streams are/ s App. B, para 3? s/The below state machine/The state machine below/ sB.4, para 1: s/one or more requisite/one or more prerequisites/ sB.4, para 2: s/requisite/prerequisite/ (2 places), s/restrictions to when/restrictions as to when/, s/As it in the general case can't be determined if it was an unrecoverable error or not/As it is not possible, in the general case, to determine whether an error was unrecoverable or not/ sB.4, para below Table 15: s/depending/dependent/ (2 places) sC.1.1, para 3: s/with use of/with the use of/ sC.1.2, para 1: s/over lower transport layer UDP/over a UDP lower transport layer/ sC.1.2, 3rd bullet: s/unless in case/except for the case when/ sC.1.2, 5th and 6th bullets are exact duplicates - remove one! sC.1.4, last para: s/as default/as the default/ sC.1.4.1: s/crypto/cryptographic/ sC.1.4.1, item 3: Does the cert validation process need a reference? sC.1.4.1, item 4: Does the encooding of the cert in the MIKEY message need a reference to say how it is done? sC.1.4.1, item 8 bullets: Expand 'spec' in various places. In last bullet s/to enable client/to enable the client/ sC.1.4.1, last para: s/where the client's identity is not necessary to authenticate/where it is not necessary to authenticate the client's identity/ sC.1.6.3, para 1: s/on short to medium/in the short to medium/, s/the used bit-rate/the bit-rate used/ ['used thingy' implies second-hand or recycled as opposed to 'thingy used' implies 'thingy (currently) in use']. sC.1.6.4, para 3 et seq (including sC.2.2, para 3): Consistent use of 'rtcp-mux' vs 'RTCP-mux'. sC.1.6.4, para 3: Is the first 'recommended' a 'RECOMMENDED'.. I am not sure. sC.1.6.4, para 4: Maybe be a pointer to IANA registration in s22.1.3 would be useful? sC.1.6.4, para 5: s/are here provided/are procided here/ [original form is right, but archaic] sC.2.1, para 2: s/go through/going through/ (probably) but I don't properly understand what the point of this 'note well' is supposed to be. What are the (evil/unexpected) consequences of the media streams going through the proxy - and why would they not do this otherwise? s2.2, para 1: s/over lower transport layer TCP/over a TCP lower transport layer/ sC.3, para 1: s/The below text/The text below/ sC.3, paea 2: I can't parse the first sentence. What is (not) affected by 'without being affected by jumps...'. sC.3, para 2 (and paras 3, 4 and 5): 'montotonically increasing' does not imply what I think is required, i.e., that the next sequence number is the one in the last packet of the previous range + 1 ['monotonically increasing' just means it isn't less than the one in the last packet and could be several more.] Maybe 'next in sequence'. sC.3, para 3: s/it arrives timely and still/it arrives in a timely fashion and still carries/, s/media has frame/media has a frame/, s/burden to render/burden of rendering/ sC.3, para 4: s/that anyway caches/that expect to cache/ sC.3, para 5: s/provided stream/generated stream/
Re: [Gen-art] #520, was: Fwd: Gen-Art review of draft-ietf-httpbis-p2-semantics-24 with security considerations
Hi Kathleen, Personally - I'm not convinced, because the people who would benefit from that warning are almost certainly not going to be reading this document. We're already getting a lot of pushback on the size of our document set; we've often resisted adding advice like this to keep it manageable for implementers N avoid it becoming a kitchen sink spec. With my chair hat on - what do others think? Sent from my iPhone On 20 Nov 2013, at 3:57 am, Moriarty, Kathleen kathleen.moria...@emc.com wrote: Hi Mark Julian, I understand your concerns, but I think a *couple of sentences* could go a long way in terms of awareness of these issues for developers and implementers. This type of advice is on par with the current security sections added for privacy concerns where you get close to the topic already. If you read through Section 9.3 and consider predicable information (ID numbers or other distinguishing information whether or not it is PII), it is easy enough to plug in other values into a URI and possibly expose information that should not have been accessible (with a bad configuration - and they do exist). It would be good to make it clear that this is not a good thing and can be one type of injection attack. You are also already covering full path disclosure in 9.1, which is a type of injection attack. Julian had requested some text, here are a couple of proposed sentences. In the last sentence of the first paragraph, add in 'predicable' to the list of items at the end of the sentence. The I suggest adding text along the following lines: Injection attacks, such as SQL and full path disclosure should be prevented in URIs to avoid unintended access. The broader set of injection attacks is out-of-scope for this document, however awareness is important for web developers. OWASP lists injection attacks as the highest risk and defines the more broad set of injection attacks as follows: Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. (Link to OWASP top 10, it is also provided as a PDF if that reference is better: https://www.owasp.org/index.php/Top_10_2013-Top_10) This suggestion is meant to raises awareness and tie into the existing descriptions that get close to this topic. Thank you, Kathleen -Original Message- From: Mark Nottingham [mailto:m...@mnot.net] Sent: Monday, November 18, 2013 9:12 PM To: Julian Reschke Cc: HTTP Working Group; Moriarty, Kathleen Subject: Re: #520, was: Fwd: Gen-Art review of draft-ietf-httpbis-p2-semantics-24 with security considerations On 19/11/2013, at 4:46 AM, Julian Reschke julian.resc...@gmx.de wrote: Section 9.3: You may want to include information that informs developers and users of SQL injection attacks. Fields are still included in some URIs that link you to pages directly that contain personal information using consistent identifiers. It would be helpful as this is still one of the biggest attack vectors. A quick search on SQL injection URL will provide additional information for inclusion in the write up. You mention GET-based forms in section 9.3, but it doesn't mention SQL injection attacks and information in the URIs. Since this is so prevalent still, I think it is important to call out explicitly. Not convinced. From an HTTP point of view, URIs are just opaque identifiers. Also, there are many kinds of injection attacks. Should we list them all (XML, javascript...)? +1 - SQL doesn't have anything to do with HTTP, and even though it is used often in conjunction with the protocol, it's an implementation-specific choice. For example, I don't use any SQL on my Web site, and am very happy about that :) Cheers, -- Mark Nottingham http://www.mnot.net/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-cdni-requirements-12
OK. Thanks for the clarification. Appreciate your feedback. :) Kent From: Christer Holmberg [mailto:christer.holmb...@ericsson.com] Sent: Monday, November 18, 2013 11:58 PM To: Kent Leung (kleung); gen-art@ietf.org Cc: draft-ietf-cdni-requirements@tools.ietf.org Subject: RE: Gen-ART review of draft-ietf-cdni-requirements-12 Hi Kent, Hi Christer. Thank you for the review. It's a good point that the language used to describe the requirement is consistent with the priority level so becomes a bit redundant. The marking of HIGH/MED/LOW makes the priority of the requirement explicitly clear. It's easier to identify and browse the requirements without having to get into the description of the requirement. Other authors can chime in. But I feel that there's value to maintaining the marking instead of using the text to specify the priority level. I agree, and that is what I tried to say - eventhough my comment may have been a little unclear :) Regards, Christer From: Christer Holmberg [mailto:christer.holmb...@ericsson.com] Sent: Monday, November 18, 2013 5:54 AM To: gen-art@ietf.orgmailto:gen-art@ietf.org Cc: draft-ietf-cdni-requirements@tools.ietf.orgmailto:draft-ietf-cdni-requirements@tools.ietf.org Subject: Gen-ART review of draft-ietf-cdni-requirements-12 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 Document: draft-ietf-cdni-requirements-12 Reviewer: Christer Holmberg Review Date: 18 November 2013 IETF LC End Date: 26 November 2013 IETF Telechat Date: 12 December 2013 Summary: The document is well written, with one minor issue that the authors might want to address. Major Issues: None Minor Issues: Q_GEN: The document defines priority of each requirement as either [HIGH], [MED] or [LOW], which is fine. But, in addition to that, depending on the priority, the requirement text uses either shall, should or may. Wouldn't it be more clean to use consistent terminology (e.g. shall) in the actual requirement text, as the priority is anyway indicated separately? Editorial nits: None ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
