IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2015-05-14. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
Telechat:
2.2 Individual submissions
2.2.1 New items
Telechat:
Telechat:
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
Telechat:
Telechat:
3.4.2 Returning items
(no break)
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
1108 EDT Adjourned
(at 2015-05-14 06:00:03 PDT)
draft-ietf-tram-stun-origin
"Analytics" here together with the MUST include statements could amount to a fancy way to describe monetizing people's WebRTC calls in ways that the end user will just not expect. I'd like to check that we're not doing that, as it'd arguably run counter to e.g. RFC7258 or to the general trend towards data minimisation. And making privacy worse, even by a little, seems worse than making it better. (Note: I am here asking about the STUN/TURN server being perhaps unnecessarily told the origin, not the risk that someone sees that in-transit, which is handled in the draft already.) I do agree that the TURN 401-like challenge use-case is perhaps needed, but I do not see that other use cases need to see the origin for them to work at all. And I'm not sure that such a spoofable origin is so useful for that TURN case, esp. when there's parallel work on an authenticated equivalent. (I mean the tram 3rd party thing.) I also don't see that that is needed for network management reasons - surely everything needed for network managment is no more nor less visible to the STUN or TURN servers when this is used vs. when this is not used. So why are we pushing for this? If it is really only for so-called "analytics" then is that ok? (And where can I find a definition of what that means?) Apologies if this discuss seems somewhat high level, but as well as the general concern, the last paragraph of the current tram charter seems to me to me to say that tram ought not make privacy worse. But maybe I'm missing the networking function that needs this - if so, I'm sure someone will point that out.
- intro, para 2: STUN only defines two auth modes that I can see, and you only mention two here - what's the 3rd one you mean? (Is it DTLS?) - What if >1 TURN session with different origins is being setup from same client/browser? Does that work? (Say two parallel calls, not the case where the same resource is being accessed at the same time loaded from different referring web pages.) - I'd suggest to not allow >1 ORIGIN in a STUN request? But that discussion seems to be in-hand. - section 2: suggest providng similar examples for all schemes, http(s),sip & xmpp. - 2.1 & 2.2: MUST include web origin - couldn't there be "private browsing" scenarios where that MUST would be a problem? I'm not suggesting that the origin exposes very much but I think a SHOULD would be more appropriate. - 2.1 last para: source here means the webrtc server right? That's a bit ambiguous and would be better clarified. - What is the benefit of sending an empty origin as opposed to no origin attribute? I don't see any and the former just advertises that the client is "privacy sensitive" which seems incongruous.
I agree with all 3 points of Barry's discuss. I think the normative language in section 2.1 is ambiguous about whether it applies to all stun implementations used by a browser, SIP, or XMPP, or just those that "implement this draft". A thoughtful reader can infer the answer from the fact that the draft does not update STUN, but it might be helpful to clarify. [Removed some comments that have been explained to my satisfaction] Nits: -- Section 1: I agree with Barry that the first reference to STUN should probably go in the previous sentence. Should reference to " Section 4.5 of [RFC7376]" really be 4.6"? 4.5 talks about a MiTM learning USERNAME. 4.6 talks about hosting multiple realms from the same IP address. (And as Barry mentioned, these are really "List entries 5 or 6 in Section 4")
Just to keep the IESG in the loop, without revising the document during balloting ... In discussion in Dallas, the editor agreed to remove this sentence from Section 2. of draft-ietf-stun-origin: "The size of ORIGINs included in a STUN message can have a major impact on the size of a STUN packet, and could potentially cause UDP fragmentation." This mention of fragmentation had raised the possibility of requiring support for SCTP in STUN and other things that there was no interest in doing, so the decision was to just remove this non-normative statement. Also, this statement is highly speculative as there are no known use cases where multiple ORIGINs will be included for WebRTC, SIP, or XMPP.
I assume that the changes agreed on a thread about David Black's Gen-ART review will be done in a subsequent revision of the draft. Thanks.
Here is Tim Chown's OPS DIR review, along the same lines as Stephen and Alissa's DISCUSSES. The feedback was sent to the authors on April 22nd, and I have not seen any reply so far. Hi, 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 with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I would summarise this document as being Not Ready. My concern with the draft lies with privacy aspects. While the area is not one that I am particularly familiar with, but there would seem to be additional potential exposure through this method, and the language of the draft seems at odds with the language in RFC6454 (Section 7.3). I would therefore urge the AD to review this aspect, and to determine whether the utility of the draft outweighs the privacy concerns, and if it does, that appropriate privacy ‘knobs’ are included for those who are ‘privacy-sensitive’ (in the language of RFC6454). I think the rationale and tradeoffs could be more clearly stated in the document. With recent passive pervasive monitoring threats, the IETF is now supposed to be considering whether given information *needs* to be transmitted in any given protocol. Would I as a user, for example, be able to toggle a setting that would mean my ORIGIN would always be “null”, as per RFC6454 section 7.3? Is the use of ORIGIN *required*, or is it just ‘desirable’? Would my application fail, or not? It appears from Section 1 that its inclusion is ‘useful’, but not required. Section 4 talks of TLS for avoiding eavesdropping of ORIGIN in STUN messages, but the privacy concern is not necessarily only with transmission of the information. I think here paragraph 3 of Section 4 is at odds with RFC6454 Section 7.3 - with this draft saying MAY wrt use of a “null” Origin, and RFC6454 saying MUST for use of “null”. The same applies to the end of the last paragraph in Section 4 as well. The draft should probably use the ‘privacy-senstive’ context terminology of RFC6454, as per Section 7.3, and describe how the user can influence the privacy settings where they which to maximise their privacy. Tim ===================================================== A point of detail, really, if you update the draft. For a web application provider STUN or TURN server, the server will have no idea which web pages or sites are sending binding requests to the service. In conventional applications, the SOFTWARE attribute would provide some identifying information to the service, but that no longer works when the browser is the application. SOFTWARE attribute: a reference to http://tools.ietf.org/html/rfc5389#section-15.10 would be beneficial
I support Stephen's Discuss.
I have three questions I'd like to discuss. The discussion might or might not
lead to any document changes, so let's please have the discussion first, and
see where it leads.
1. In Sections 2.1 and 2.2, I find this combination odd:
a. For non-web origins, you SHOULD (not MUST) send ORIGIN.
b. But for web origins, you MUST send ORIGIN.
c. But that ORIGIN can be empty.
If you're allowed to send an empty origin, and you can sometimes not send
ORIGIN at all, why is ORIGIN REQUIRED (but can be empty) in some cases? How
does that help interoperability or security or whatnot?
2. In Sections 2.2 and 2.6, about the SHOULD NOT ("NOT RECOMMENDED"): Why?
What happens if you use it? Under what conditions might you do so, even though
this says you SHOULD NOT? (Why is it not "MUST NOT"?)
3. In Section 2.7:
Therefore, if
a STUN request contains multiple origins, the first origin MUST be
used and the remaining origins ignored.
For all cases (that's what it says)? Or was this just meant to apply to SIP
and XMPP? Or SIP, XMPP, and WebRTC? But not to other HTTP uses? Or yes to
HTTP? If this really does apply to all cases, why are multiple origins allowed
in the first place?
-- Section 1 --
A minor thing: the citation for STUN in the first two sentences seems odd.
Instead of citing 5389 with the first use of "STUN" in the first sentence, you
cite it in the second sentence where it appears to be a reference for "a STUN
extension". I suggest moving the citation to the first sentence, so: "STUN, or
Session Traversal Utilities for NAT [RFC5389], is a protocol used...."
It wouldn't be a bad thing to add an informative reference to CORS and to cite
it when you mention it. <http://www.w3.org/TR/cors/>
There is no Section 4.5 in RFC 7376. Perhaps you mean Section 4, bullet 5?
-- Section 2.1 --
For STUN requests sent without authentication to a STUN server (i.e.
STUN binding requests sent to a STUN server), the STUN client MUST
include the ORIGIN attribute when the origin is a web origin. For
other origins, such as SIP or XMPP, the STUN client SHOULD include
the ORIGIN attribute.
Note that for privacy reasons, an empty ORIGIN attribute can be
sent, as described in the Security Considerations.
The "i.e." tells me that the two things are synonymous: that "STUN requests
sent without authentication" is the same as "STUN binding requests". Is that
really true? Is it true that all binding requests are sent without
authentication? Or am I quite misunderstanding what you're trying to say here?
What, exactly, do you mean by "when the origin is a web origin"? From the
previous section, that seems to refer to something sent by a web browser. But
a web browser is just a piece of software, and a web browser could happen to be
a SIP or XMPP client, as well. Do you really mean to refer to origins that use
the "http" scheme? You might clarify this, particularly because it's involved
in a "MUST".
A STUN server can derive additional information for logging and
analytics about the request through the ORIGIN attribute, such as the
source of the request. For example, an enterprise STUN server might
only reply to STUN binding requests from certain domains.
In the example case, does that mean that such a server would not reply to
binding requests that lacked ORIGIN (or had an empty one)? If so, that would
be a good bit of explanation to add. I don't think that what's in the Security
Considerations is enough to answer that question up here.
-- Section 2.2 --
When the origin is a web origin, TURN [RFC5766] Allocate requests
MUST include the ORIGIN attribute. For all other TURN requests,
including the Send method, the use of the ORIGIN attribute is NOT
RECOMMENDED. For other origins, such as SIP or XMPP, TURN Allocate
requests SHOULD include the ORIGIN attribute.
The order here is odd, and made me read it a few times to be sure that I
(thought I) understood it. I would switch the order of the second and third
sentences. Apart from that, I have the same comments here that I had about
Section 2.1.
-- Section 4 --
DTLS or TLS transport SHOULD be
used when integrity protection for the ORIGIN attribute is important.
Just curious here: When is integrity protection for it *not* important (and how
will the client know that), given that the server might use it to determine
whether it should respond, or to affect the authentication challenge? (And,
actually, the first sentence of the next paragraph repeats the SHOULD without
the qualifier. I suggest just removing the qualifier and merging the "TLS/DTLS
SHOULD be used" advice from the two paragraphs.
Also, given that Section 2.1 says that the server might use it for logging and
analytics, it might be good to add that the server SHOULD NOT rely on
information from the ORIGIN attribute in the absence of secure transport.
I suggest factoring out the ends of the last two paragraphs (the parts that
start with "In cases where") into a new last paragraph, rather than saying the
same thing twice saying the same thing twice.
This is a bit of a weird DISCUSS since I didn't manage to ballot when the document was first on the IESG's agenda, so I'm coming in mid-stream. I support Stephen's DISCUSS. If Alan's proposed changes make it into the document, they would resolve most of my concerns. However, I still see a problem with this proposed new text: "For STUN requests sent without authentication to a STUN server (i.e. STUN binding requests sent to a STUN server), the STUN client SHOULD include the ORIGIN attribute. The ORIGIN attribute MUST NOT be included if it is a "privacy-sensitive" context, as discussed in the Security Considerations section." For requests sent with authentication, I understand that the origin attribute needs to be accurate in order for the client to authenticate. In those cases, the STUN server can rely on the attribute it receives. But for requests without authentication, what prevents the client from lying? And if those requests are not (D)TLS-protected, what prevents them from being modified in transit? I understand Alan to be saying that the justification for the origin in this case is operational troubleshooting, but if the server can't rely on the origin it receives, doesn't that make it risky for the server to act on that information? My additional concern is about the use of "logging" as a justification for including and origin attribute. Logging in and of itself is not a reasonable justification. Alan's mail discussed the use of the origin for operational troubleshooting, which seems like what might actually be intended instead of "logging." In any event the purpose for the logging either needs to be explained or "logging" should not be listed as a justification.
draft-ietf-straw-b2bua-stun
No objection, but a couple of places where the text seemed rough:
In this text:
For these
and other reasons, B2BUAs were already being used by SIP domains for
other SIP and media-related purposes began to use proprietary
mechanisms to enable SIP devices behind NATs to communicate across
the NAT.
Does this sentence parse?
In this text:
The most commonly used approach to solve these issues is
"restricted-latching", whereby the B2BUA will not latch to any
packets from a source public IP address other than the one the SIP UA
uses for SIP signaling.
Is the phrase "will not latch to" clear to the intended reader? The sentence is
defining a type of latching, but there's not a description of what latching
means in the general sense. The following section says terms are defined in
https://tools.ietf.org/html/rfc7092, but I didn't see "latch" in a quick text
search over there. Is the reference to https://tools.ietf.org/html/rfc7362
earlier in the paragraph also to the description of "latching"?
In this text:
o A B2BUA that acts as a simple media relay effectively unaware of
anything that is transported and only modifies the transport
header (could be UDP/IP) of the media packets.
o A B2BUA that performs a media-aware role. It inspects and
potentially modifies RTP or RTP Control Protocol (RTCP) headers;
but it does not modify the payload of RTP/RTCP.
o A B2BUA that performs a media-termination role and operates at the
media payload layer, such as RTP/RTCP payload (e.g., a
transcoder).
When such a B2BUA operating on a media plane is involved in a session
between two endpoints performing ICE, then it MUST follow the
behavior described in Section 4.
I"m reading "such a B2BUA" as a reference to the third bullet, but it would be
clearer to me if both places used the same terms ("operates at the media
payload layer" vs. "operating on a media plane").
- 4.2, but maybe also elsewhere: should such a b2bua be REQUIRED to announce itself as a b2bua that forces itself into the media stream in some manner? Or more broadly, if we are now (for the 1st time?) standardising b2bua behaviours, then ought we mandate that such entities make their prescence or even some flavour of their functionality known in-band? Even if we do not mandate such behaviour, shouldn't we at least define how a b2bua that wants to be visible ought do that? (And if we have done the above already, or discussed and discarded the above already, then great, and that shows how much I know:-)
Thanks for addressing Nevil Brownlee's OPS-DIR feedback. Regards, Benoit
I just finished reading this draft and agree with the SecDir review assessment that this draft does not add additional security considerations. The SecDir reviewer had some good points on the abstract and introduction that I do think would be helpful to improve the readability of the draft and would like you to consider these updates. https://www.ietf.org/mail-archive/web/secdir/current/msg05687.html
-- Section 1 -- For these and other reasons, B2BUAs were already being used by SIP domains for other SIP and media-related purposes began to use proprietary mechanisms to enable SIP devices behind NATs to communicate across the NAT. I can't parse that sentence. The "began" doesn't seem to be the right part of speech, or maybr the second "for" is wrong. Something, anyway. Update: the author has provided good replacement text: NEW: For these reasons, B2BUAs were being used by SIP domains for SIP and media-related purposes. These B2BUAs use proprietary mechanisms to enable SIP devices behind NATs to communicate across the NAT. END
draft-ietf-scim-api
Feel free to ignore any of these that overlap with earlier comments, I've not been following all discussion on this one. - section 2 says that bearer tokens based on no authenticaton may be used (as the exception to the "SHOULD NOT be used"). Why is that ok? Maybe s/SHOULD NOT/MUST NOT/ here would be better and justified? - 3.1: seems odd to define schema but then say it's entirely fine to ignore all of that - or am I reading this wrong? - p9, figures and tables should have captions and be numbered and this looks like a table of HTTP methods (not "operations") that has neither. - general: I came across a bunch of places where some forward reference would help (e.g. 3.3 assumes I get what readOnly means; 3.4.2.1 does the same for a "json attribute"). An editing pass to try improve that before the RFC editor would be good I think. - 3.4.2 says: "This SHALL NOT be equal to the number of elements in the resources attribute of the list response if pagination (Section 3.4.2.4) is requested. " What if I ask for pagination with 10 per page and there are a total of 10 matching results? That SHALL NOT seems broken. - 3.4.2.2: Is "pr()" true when a client didn't send a value to the server at creation time but the server included the default value in the response to the PUT? (And what happens to pr() and eq() when the default value changes?) - 3.4.2.2, p21: eq() is case insensitive? I think you badly need a fwd ref to sections 3.8 and 5. - 7.4, para 2 looks truncated
Small nit in Section 1.2 s/Throughout this documents all figures MAY contain spaces/Throughout this document all figures may contain spaces
-- 3.4.2: "SHOULD ignore any query parameters they do not understand" I'm curious why this is not a MUST. What are the alternatives--that is, can you envision situations where it might be reasonable to _not_ ignore parameters you don't understand? -- 3.4.2.2, reference to [Order-Operations] As written, that needs to be a normative reference. That's problematic for a reference to wikipedia, since articles are extremely changeable. Furthermore, the referenced article doesn’t indicate one true operator precedence for programming languages. If the rest of the paragraph fully defines the precedence, I suggest saying “MUST… according to the following”, and making the reference truly informational (or even dropping it entirely.) -- 3.8: The first paragraph says servers MUST respond with JSON in UTF-8. But the following paragraphs talk about how the client may request different response formats. This seems contradictory. -- 3.13: It's optional (MAY) to include the API version. If the version is missing, the service provider SHOULD perform the operation using the most recent supported version. This seems to allow the client and service provider to disagree on the version being used. Does this cause an interop problem if the later version is not backwards compatible? (Are all new versions expected to be backwards compatible with old versions?)
-- General: There seems to be a pervasive use of 2119 keywords in ways that seem like statements of fact, rather than normative requirements. This is especially true with MAY, where it seems like people may have gotten into the habit of capitalizing every occurrence of the word. I've called out a number of instances below, but probably didn't catch them all. -- 1.3, 3rd paragraph: The paragraph is indented as if part of the definition of "Base URI". I suspect that is not the intent. "It is expected that SCIM servers MAY...": Is the normative MAY intentional? It's odd to see a 2119 keyword following a phrase like "It is expected..." -- 2, Basic Authentication: "Implementers SHOULD combine the use of basic authentication with other factors": Do you mean that they SHOULD NOT use basic _without_ combining it with other factors? If so, that is subtly different than the text as written. -- 2.1, last paragraph: Just SHOULD? Do you invision situations where it might be reasonable _not_ to take the threats into account? Also, the reference to oath-assertions needs to be normative -- 2.2, "... it MAY be acceptable" This seems more a statement of fact than a normative assertion. -- 3.1, 2nd paragraph "... a JSON object that MAY be created...", "in cases where SCIM MAY be used...", "reasonable to expect that some service providers MAY only support" s/MAY/may -- 3.1, 3rd paragraph: "... implementations MAY vary": Should not be normative. "... techniques such as document validation...are not recommended.": Maybe that one _should_ be normative. "... a SCIM client SHOULD NOT expect...": Probably should not be normative. (But if it really is intended as normative, when might a client reasonably choose to violate it?) -- 3.3, 3rd bullet: How does a service provider know which attributes a client understands? -- 3.4.2, totalResults: "... SHALL NOT be equal..." Never? Is it never possible that all results fit into one "page"? Perhaps this should have been a non-normative "might not be equal"? -- 3.4.1.2, paragraph starting with "A query against a server root..." What is the significance of "ALL" in caps? -- 3.4.2.2, "... the the resource MUST match if any of the instances of the given attribute match the specified criterion..." That seems like a statement of fact. (e.g. "the resource matches if..." -- 3.4.2.4, 1st paragraph: "clients SHOULD never assume repeatable results" That seems like a statement of fact, not a normative assertion. -- 3.5.1, 1st paragraph: "Clients that MAY have..." : s/MAY/may -- table 8, tooMany: "... MAY not be acceptable..." As worded, that sounds like a statement of fact. -- 7.3: That needs to be a normative reference. Also, why is this a SHOULD? Can you envision scenarios where it might be reasonable for implementors NOT to take the countermeasures into account? -- 7.4: Reference to oauth-assertions needs to be normative. -- 7.6, 2nd bullet s/MAY/may -- editorial -- 2, HOBA paragraph: Is this intended as part of the TLS Client Authentication entry? It doesn't seem so, but the paragraph lacks its own heading. 3.2, 1st paragraph, sentence starting with "Given there are cases..." Sentence fragment. -- 3.3, first two bullet list entries The "For" at the beginning of both entries does not fit the rest of the sentence structure.
Thank you for your work on this draft as I do think the work is important. Thank you also for working with me to resolve discusses on security and privacy concerns with the authentication and authorization protocols that may be used with SCIM. The added text on http authentication methods and security problems with OAuth bearer tokens will be very helpful to implementers and customers evaluating/negotiating security services of their service providers for provisioning.
" o Limit the number of requests any particular client MAY make in a period of time." Great so we going to limit the extent to which an attacker can spam the the thing. that sounds comforting. " These recommendations include but are not limited to: o Provide injection attack counter measures (e.g., by validating all inputs and parameters), o No cleartext storage of credentials, o Store credentials using an encrypted protection mechanism, and " I don’t really think of that as being a recommendation so much as a requirement . if you’re storing clear text passwords somebody needs to take away all your toys.
draft-ietf-scim-core-schema
- intro: I've no idea what "a general profile service for in-domain applications" might be. - intro: hmm, the pass-info-to-3rd-party is a bit unsettling all right. I think some earlier discussion resuled in a suggested addition that should help, so I'd just like to add more backing to the idea that such warnings can be useful. Maybe there ought also be a way to annotate elements to say that such "sharing" is not allowed? (As a future extension, if that can be done.) - 2.3.5: I didn't have time to chase the references here but is the TZ always clear in this encoding? And does 2015-01-01 mean all 24 hours of Jan 1 this year or just the first second of that day? - 3.1: lastModified - this is sometimes used as a secondary thing to authenticate the system to a user and so in some cases could be somewhat sensitive if it were world readable, or easily readable by someone who wanted to spoof as a server to a valid user. Not sure if that's worth a note here. Probably not. - 4.1.1: password, I agree with Ben's ex-DISCUSS. Section 8.7.1 also says that the password element contains the cleartext password which definitely needs fixing. - 4.1: why only x509Certificates? I think you should also allow PGP keys in some form or else generalise to "public key containers" that would allow both plus "bare" public keys maybe of varying forms. This is not a discuss because it could be fixed later, but the current design is IMO wrong in this respect and would be better fixed now. - 4.1: if you do keep an element named x509Certificates then it may be worth adding a negative bit of guideance such as 'Each value here contains exactly one (base64) encoding of a DER encoding of a Certificate data structure. A single value MUST NOT contain multiple certificates and so does not contain the encoding of a "SEQUENCE OF Certificate" in any guise.' It has been a while since it's been done afresh but I've seen that mistake in the past and it causes interop problems. - 8.x: Nice that Olson gets a hat-tip in the TZ definition! - 8.x: I hope someone has carefully read the schema stuff recently - it's long and detailed and I didn't have time. - Thanks for section 9.3!
Small nit in Section 1.1 s/Throughout this documents all figures MAY contain spaces/Throughout this document all figures may contain spaces
Thanks for addressing my discuss issue--I've cleared.
-- General:
As in the API draft, there's quite a bit of misuse of the 2119 "MAY" keyword
(details below.)
-- 1.1, 3rd paragraph: "... all figures MAY contain spaces."
s/MAY/may
-- 2.1, 2nd paragraph : "MAY be camel-case"
Seems like if they are case insensitive, they can be any case.
-- 2.1, last paragraph: "... MAY need to be escaped..."
s/MAY/may
-- 2.2, 2nd bullet:
I assume this refers to the value/content of the attribute, since the previous
section said the attribute name is always case insensitive.
-- 2.3.4:
integer is defined as a _decimal_ number that MUST NOT contain fractional or
exponent parts. But the definition of “Decimal” says it has to have at least
one digit to the right of the period. Do these conflict? Do Integers always
need a trailing zero after a period? (I suspect the answer is that you didn’t
mean to say Integer was derived from Decimal, but if so, the use of “decimal”
is confusing.)
-- 2.3.7, 2nd to last paragraph, first sentence:
To whom does this requirement apply? It sounds like an attempt to apply a MUST
to whatever service a reference happens to refer to. I gather that could be any
arbitrary service addressable with a URL.
-- 2.4, paragraph after bullet list : "The pre-defined set of sub-attributes
for a multi-valued attribute"
I’m not sure what that means. These are the only sub-attrs that can be used?
All multi-valued attributes have these sub-attributes?
-- 3, "Schema Attribute": "The "schemas" attribute is a REQUIRED attribute that
MUST be
present"
The REQUIRED and MUST are redundant.
-- 3.1, first paragraph, last sentence: "SHALL NOT be considered schema
extensions."
Should this really be normative? Does “considering them a schema extension”
involve observable implementation behavior differences?
-- 3.1, meta/resourceType: "The attribute is REQUIRED when provided by the
service
provider."
I’m not sure I understand—this seems to say the attribute is REQUIRED when it
is present. (Same wording occurs for multiple attributes)
-- 4.1.1, "name"
This is defined as components of the user's "real" name. That sounds like an
assertion of a real-name policy. Does the schema really require real names?
-- 4.1.2, "groups" : "... which MAY influence
indirect memberships.:
s/MAY/may
-- same section, "entitlements": "An entitlement MAY be an additional right"
s/MAY/may
-- 9.3. 2nd paragraph
s/MAY/may (both occurrences)
-- 10.3.1:
Is there a reason not to use one or more of the well known registration
policies from RFC 5226?
Editorial Comments
-- 4.1.1, "active"
s/infers/implies
Here is Qin's OPS DIR review:
I think this draft is ready for publication. Here are a few editorial comments:
1. Section 1.1 “Requirements Notation and Conventions”
I am wondering how RFC2119 languages are applied to this document,
In Section 4.1.1, “RECOMMENDED” is applied to the attribute “userName” by adding
“RECOMMENDED” at the end of attribute “userName” description.
In section 7, “DEFAULT”is applied to subattibute “readwrite” by adding “DEFAULT”
at the end of “readwrite” sub-attribute description. “DEFAULT” seems not
RFC2119 language.
Therefore RFC2119 language used to apply to some attribute seems not consistent
with other
language(e.g., DEFAULT) applied to some other attributes. Or the language used
at the end of
each attribute is not totally RFC2119 language.
Please distinct where RFC2119 language is used from where other
language(e.g.,”DEFAULT” ) is
used in the draft.
2. Section 2.2 said:
“
2.2. Attribute Data Types
Attribute data types are derived from JSON [RFC7159] and unless
otherwise specified have the following characteristics (see Section
7 for attribute characteristic definitions):
”
Who has the following characteristics, attribute data types or attributes?
If it is the former,I am not sure all the attribute data types listed here have
the following characteristics(e.g., mutability, and returnability, uniqueness),
For example. Boolean and Integer, Decimal are not of type string.
Attribute data type “Reference” is not case insensitive.
Can you give an example to explain the attribute data types are modifiable?
Or attributes corresponding to attribute data type listed here are modifiable?
How to understand attribute data type are returned in response to queries?
Are you saying attribute corresponding to attribute data types listed here are
usually returned in response to queries?
3. Section 3.1 said:
“
For backwards compatibility reasons, some existing schema MAY list
common attributes as part of the schema. The attribute
characteristics listed here SHALL take precedence.
”
Where the attribute characteristics are listed here? Section 7?
It looks what is listed here are a list of common attributes? What am I missing?
Also please clarify how to understand “take precedence of these attribute
characteristics ”?
4. Section 3.2 said
“
In order to offer new types of resources, a
service provider defines the new resource type as specified in
Section 6and defines a schema representation (see Section 8.7).
”
Miss a blank space between “section 6” and “and” in this sentence.
5. Section 6 said:
“
The following Singular Attributes are defined:
id
The resource type's server unique id. Often this is the same
value as the "name" attribute. OPTIONAL
name
The resource type name. When applicable service providers MUST
specify the name specified in the core schema specification; e.g.,
"User" or "Group". This name is referenced by the
"meta.resourceType" attribute in all resources.
”
It looks not all the attributes are suffixed with
“RECOMMEND”,”REQUIRED”,”OPTIONAL”,”DEFAULT”.
So what is the default characteristics pertaining to the attribute if it is not
suffixed with “RECOMMEND”,
”REQUIRED”,”OPTIONAL”,”DEFAULT”?
If there is no default characteristics associated with the attribute, For
consistency, I think each attribute
should add a suffix like “DEFAULT”,”RECOMMENDED”,”REQUIRED”.
6. Section 7 said:
“
"Schema" resources have mutability of "readOnly"
and are identified using the following schema URI:
”
Is SCIM Resources “shema”resource?
If they are the same thing, please use consistent terminology.
7. Section 7 also said:
“
id
The unique URI of the schema. When applicable service providers
MUST specify the URI specified in the core schema specification;
e.g., "urn:ietf:params:scim:schemas:core:2.0:User". Unlike most
other schemas, which use some sort of a GUID for the "id", the
schema "id" is a URI so that it can be registered and is portable
between different service providers and clients.
”
Does attribute “id” has the attribute characteristics described in section 2.2?
i.e.,
“
o are OPTIONAL (is not required).
o are case insensitive ("caseExact" is "false"),
o are modifiable ("mutability" is "readWrite"),
o are returned in response to queries (returned by default),
o have no canonical values (e.g. type is "home" or "work"),
o are not unique ("uniqueness" is "none"), and,
o of type string (Section 2.2.1).
”
8. Section 8.6 said:
“
The following is a non-normative example of the SCIM resource types
in JSON format.
”
Section 7 said, A SCIM resource type can be “user” or “group”. I am wondering
how represented
using JSON format in the example of section 8.6?
Using schema attribute
“
"schema": "urn:ietf:params:scim:schemas:core:2.0:User"
”
Or using combination of several attribute, e.g., “id”,”name”,etc.
Thanks for addressing the SecDir review adding text on clear text/hashed passwords and best practices (to avoid storing clear text, etc.). https://www.ietf.org/mail-archive/web/secdir/current/msg05678.html Thanks for the additional privacy considerations, pointing out that most of the data that could be sent using the SCIM schema could be sensitive in addition to the id and externalId. Thanks for the additional text to out-of-scope some of the security controls that are really in the hands of implementers and may be specified through security SLAs or contracts.
I agree with the mis-use of 2119 keywords raised by other ADs and I held my nose at the repeated use of the word "cloud".
my comments on api apply to the security considerations here also.
draft-ietf-manet-tlv-naming
- I wonder if this document should only update RFC5444, or all the RFCs that
are changed in IANA? Let's take an example:
The IANA Registry "Message TLV Types" is changed to Table 1.
+---------+-------------------------------+-----------+
| Type | Description | Reference |
+---------+-------------------------------+-----------+
| 0 | Defined by Type Extension | [RFC5497] |
| 1 | Defined by Type Extension | [RFC5497] |
| 2-4 | Unassigned | |
| 5 | ICV | [RFC7182] |
| 6 | TIMESTAMP | [RFC7182] |
| 7 | Defined by Type Extension | [RFC7181] |
| 8 | Defined by Type Extension | [RFC7181] |
| 9-223 | Unassigned | |
| 224-255 | Reserved for Experimental Use | [RFC5444] |
+---------+-------------------------------+-----------+
Table 1: Message TLV Types
The current IANA entries for that registry are:
Type Description Reference
0 INTERVAL_TIME [RFC5497]
1 VALIDITY_TIME [RFC5497]
2-4 Unassigned
5 ICV [RFC7182]
6 TIMESTAMP [RFC7182]
7 MPR_WILLING [RFC7181]
8 CONT_SEQ_NUM [RFC7181]
9-223 Unassigned
224-255 Reserved for Experimental Use [RFC5444]
I guess that, if I would read RFC 5497 and the new registry, the story would be
complete since RFC5444 is updated by draft-ietf-manet-tlv-naming-RFC-to-be.
Anyway, just asking the question so that we doubleckeck. Basically, if Michelle
Cotton is fine, I'm fine.
- I agree with Barry regarding the abstract length.
The Abstract isn't very abstract -- which is to say it's very long. Can you let the Introduction do the heavy lifting, and cut the Abstract back to, say, the last two paragraphs with a little editing (to expand "TLV" there and to replace "those registries" with something like "the MANET TLV registries defined in RFC 5444")? Other than that, I have no comment but that this is a fine thing to do, and it doesn't surprise me that Adrian brought it up.
draft-ietf-tls-session-hash
Thank you for your work on this and a well-written draft! The considerations are very thorough, every time I had a question, I was able to find an answer in the draft. I do think a couple more references could be helpful though. 1. I think it would be good for section 6.4 to note that SSL 3.0 has been deprecated in https://datatracker.ietf.org/doc/draft-ietf-tls-sslv3-diediedie/ It's ahead of this draft in the RFC editor queue. 2. It might be good to have a pointer to the UTA TLS Attack RFC7457 as this attack is described in section 2.11 and there is no reference to a fix. It would be nice to show that known attacks are being resolved. https://tools.ietf.org/html/rfc7457#section-2.11
This is a DISCUSS purely because I want to discuss it; whatever the result is, I will be clearing the DISCUSS, and not delaying the document on this point: The last paragraph of Section 4 makes me wonder whether this should "update" 5246. Basically, while this is an extension (which wouldn't normally use "updates"), it's one that you're proposing as standard behavior, and not really as an extension.
I agree with Barry's question.
draft-ietf-opsawg-hmac-sha-2-usm-snmp
Thanks for defining these. I do have a thing do briefly discuss before balloting yes. I'll be getting out of your way very shortly, but I want to check first to see if you agree with me that this could be simpler and more useful. I note the following: - You're defining a bunch of HMAC options. - Additional options for fun isn't a good idea with crypto. - There may be platforms that do not have good APIs for SHA224 or SHA384. - HMAC-SHA256 without any truncation is considered perfectly fine for this purpose and is widely used elsewhere. - You don't need truncation for protocol reasons. To me, that implies that this would be better if it *only* defined a non-truncated HMAC-SHA256 option and if all of the rest were removed. Do you agree that doing so would achieve just as much of a security improvement, but with less complexity for implementation, test and interop? If so, should we just do that?
Editorial: - OLD: ORGANIZATION "SNMPv3 Working Group" NEW: ORGANIZATION "OPSAWG Working Group" - The copyright within the MIB should be 2015
Thanks for your work on this draft! It's great to see the improvements in
security.
This is just a comment and not critical at all… I found this sentence at the
bottom of the second bullet of 4.1 a little odd:
as opposed to the truncation to 12 octets in HMAC-MD5-96 and HMAC-
SHA-96.
Since the guideline is to truncate the size in half and have 80 or more bits
for a HMAC, you are covered and already cite the appropriate RFCs. Is this
there just for history of previous solutions? Or would it be better to just
state the guidance so folks understand why you chose the truncation size? You
can do nothing with my comment, it's just a question as the text had me
curious. And I see that you have included the HMAC truncation guidance in the
security considerations section already.
draft-ietf-appsawg-rfc7001bis
Based on the diff [1] from 7001, I've no objection. Thanks for ensuring that that diff was useful for this review. (Or else I'm glad we were lucky - it really speeds things up for me:-) [1] https://www.ietf.org/rfcdiff?url1=rfc7001&url2=draft-ietf-appsawg-rfc7001bis-09
-- 2.6, 2nd paragraph: Why might one choose _not_ to include version tokens? -- 2.7.7, first paragraph, last sentence: I’m not sure how such a “preference” should be applied for IANA stuff -- 4, last sentence: Known not to authenticate, or not known to authenticate? -- 4.1, 2nd paragraph is it reasonable for users to be expected to know which services are used in their ADMDs? -- 5, last paragraph: How do you imply a version?
draft-ietf-opsec-dhcpv6-shield
There is one thing here I can't figure out, maybe you can enlighten me though... section 5, bullet 3: this seems like another "don't make it easier to use IPv6 rule" and as a default, which I can't figure. Why do you even need to block "an unrecognized Next Header value" to protect against a spoofed DHCPv6 response message? - intro: s/meant to/sent to/ ?
I'm not going to block on this, but it seems weird to me that this would be a BCP. (And I see I am not the first to ask about that.)
- We note that DHCPv6-Shield only mitigates only DHCPv6-based attacks
against hosts.
Remove one "only"
-
OLD:
DHCPv6-Shield MUST parse the entire IPv6 header chain present in
the packet, to identify whether it is a DHCPv6 packet meant for a
DHCPv6 client (i.e., a DHCPv6-server message).
NEW:
DHCPv6-Shield implementations MUST parse the entire IPv6 header chain
present in the packet, to identify whether it is a DHCPv6 packet meant
for a DHCPv6 client (i.e., a DHCPv6-server message).
- As mentioned by Jürgen in his OPS-DIR review:
Section 5 is titled "DHCPv6-Shield Implementation Advice". It uses
RFC2129 MUST language and talks about criteria for compliance. Is
"Advice" really the right word for this? Sounds a bit soft for what
are actually implementation requirements.
Fernando propoped: The title was borrowed from a similar I-D for RA-Guard
implementation. I guess we could simply say "DHCPv6-Shield Implementation"?
I thought it was a good idea.
I'd like to understand why this is a BC and if that's the right designation. Hannes brought this up in his SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg05273.html
Thank you for the effort invested in this document. From my reading it appears that -06 addresses the discuss raised by Ted.
I agree with Stephen's point and believe that Ted's suggested change of the default behavior is one way to address that issue.
I see that the normative recommendations about logging have been removed, so I am clearing my DISCUSS. However, I still think the document would be better if it explained the difference between a security fault and a security alert. I don't understand what the difference is supposed to be. Also, it seems the changes I had suggested in my COMMENT originally were not adopted -- not sure if that was on purpose or an oversight. = Section 1 = s/meant to DHCPv6 clients/intended for DHCPv6 clients/ s/a specific ports/specific ports/ s/DCHPv6-Shield/DHCPv6-Shield/ s/only mitigates only/only mitigates/ = Section 5 = I support all of the changes to Section 5 suggested by Pete. I don't think the spec should recommend logging packet drop events unless it explains what is meant to be done with the logs.
a dreft to be posted to address lc coments from ralph droms and Sheng Jiang
draft-jimenez-p2psip-coap-reload
- This is an AD sponsored document with an IPR declaration that says RAND+possible-fee. The write-up says that the core and p2psip WGs discussed the document and are ok with it being AD sponsored. Was the IPR declaration a part of that discussion? (The shepherd write up only says that nobody had a problem, it's not clear if the WGs were told about the IPR directly.) The IETF LC does however properly note the IPR, so this isn't a formal process-whine, I'm just asking:-) If the WGs were not in fact told about the IPR (via a mail or at the presentations mentioned) then it might be a good belt/braces type thing to do to just check that before proceeding since we know there are a bunch of people who aren't subscribed to IETF announce. - intro, "Regisgtration" para: I forget - do all CoAP nodes have a "CoAP URI" that they need to know? If so, a ref to that bit of the CoAP spec would be good. If not, I'm not sure how this works. - PEA on 1st use: "RN" is a what? - section 9: "which canonicalized form hashes (using the hash function for the overlay) to the Resource-ID" is not clear enough IMO and likely to create interop issues. I think you need some more detail and a combination of references and examples before this will be implemented well. Similarly "certificate has an associated URI" isn't precise enough is it? (It could be in a SAN or some otherName or even outside the cert with that wording.) - section 10: I think you're missing a security consideration: if a CoAP node (probably esp. a sleepy node) uses this to publish information about itself, then it is more likely to get attacked, e.g. a sleepy node may be more likely to get a barrage of messages as soon as it awakens as part of a battery depletion or other DoS attack. I'd note that and say that it's more important to be DoS resistent and get e.g. s/w updates when you tell the world about yourself, since not all bits of the world you're telling are nice. (PEA == Please Expand Acronyms:-)
For the new registry in Section 11.3, why is Standards Action necessary? That's the strictest policy we have. What harm is done if other policies are registered, such that a Standards Track RFC is necessary? Would "Standards Action or Specification Required" be good enough, allowing a designated expert to review requests that don't come from Standards Track? (I ask this because we have painted ourselves into corners many times, forcing things to be Standards Track unnecessarily, just because we made a too-strict registry policy earlier.)
The Introduction starts rather abruptly. I presume the intent is that the
Abstract is really the first paragraph of the Introduction. I know you're
trying to avoid duplicating the Abstract in the Introduction, but maybe that
really is the best thing to do here.
For example in cases multiple Wireless Sensor
Networks (WSN) that need to be federated over some wider-area
network.
There's something missing here, and the result doesn't make sense. Please fix.
-- Section 3 --
In our architecture we extend the different nodes present in RELOAD
(Peer, Client) and add support for sensor devices or other
constrained devices. Figure 2 illustrates our architecture.
And yet it's Figure 1 that's labelled "Architecture". Figure 2 says it's about
"Overlay Topology".
-- Section 7 subsections --
I find the use of "[length]" to describe arrays to be confusing, especially as
they're preceded by something also called "length" that actually is a length
value. For example:
struct {
Node-ID Node_ID;
uint32 length;
SensorEntry sensors[length];
} ProxyCache;
If the "sensors" item is an array, wouldn't it be better to sau
"sensors[count]", or some such?
-- Section 7.2 --
SensorInfo contains relevant sensor information that is dependent on
the use case. As an example we use the sensor manufacturer as
relevant information.
struct {
opaque manufacturer;
/* extensions */
} SensorInfo;
sensor_type
contains the type of a resource as defined in [RFC6690], for
example temperature, luminosity, etc.;
duration_of_inactivity
contains the sleep pattern (if any) that the sensor device
follows, specified in seconds;
last_awake
indicates the last time that the sensor was awake represented as
the number of milliseconds elapsed since midnight Jan 1, 1970 UTC
not counting leap seconds. This will have the same values for
seconds as standard UNIX time or POSIX time;
That doesn't make sense to me: the items sensor_type, duration_of_inactivity,
and last_awake don't appear in the structure. What's supposed to be described
here?
-- Section 9 --
In URI-NODE-MATCH policy, a given value MUST be written and
overwritten if and only if the signer's certificate has an associated
URI which canonicalized form hashes (using the hash function for the
overlay) to the Resource-ID for the resource. In addition, the
dictionary key MUST be equal to the Node-ID in the certificate and
that Node-ID MUST be the one indicated in the SignerIdentity value
cert_hash.
I have two problems with this. One is that it repeats the description of
URI-MATCH exactly, but doesn't say so, so the reader wonders if there's a
difference (I compared them carefully; why make the reader work that hard?).
The other is that you have that very clear "if and only if", which you then
appear to modify in the next sentence, so it isn't really if and only if, is it?
I suggest this, which I think is clearer:
NEW
In URI-NODE-MATCH policy, a given value MUST be written and
overwritten if and only if the condition for URI-MATCH is met
and, in addition, the dictionary key is equal to the Node-ID
in the certificate and that Node-ID is the one indicated in
the SignerIdentity value cert_hash.
END
You also refer to Section 9 twice, like this:
The "coap:" prefix needs to be removed from the COAP
URI before matching. See Section 9.
...but there is nothing in Section 9 about that at all. Oversight?
-- Section 11.3 --
Both SHALLs in this section are not appropriate use of 2119 key words --
especially the first one. Please replace the first with something like "IANA
is asked to...".
For the second, more of a fix is needed, because you have a dangling reference
to 5226, followed by a sentence fragment. So: "New entries in this registry
are registered using the Standards Action policy [RFC5226]."
I don't think this is a problem, but would you expect a COAP RELOAD usage to use self-signed certificates pretty much all the time? Otherwise, wouldn't you have to configure certificates on each node? The base RELOAD specification allows that, but if that's what's expected, it might be helpful to explain what's expected and why.
draft-hallambaker-tlsfeature
Expanding OCSP (and maybe pointing to RFC6960 for further reference) would be nice.
I shared Barry's confusion about the term "TLS Feature Extension" in the context of section 1.2. I had to spin on this a bit to realize we were talking about an X509 extension that advertised TLS features rather than an "extension" of TLS "features".
General comment: in a number of places you add an explanation of WHY. I appreciate that, and I think it helps a lot -- especially when you're explaining a SHOULD. Thanks. -- Section 1.2 -- In order to avoid the confusion that would occur in attempting to describe an X.509 extension describing the use of TLS extensions, in this document the term 'extension' is reserved to refer to X.509v3 extensions and the term 'feature' is used to refer to a TLS extension. I applaud the attempt to avoid confusion. Yet this sentence itself confuses me. What, then, is a "TLS feature extension"? From the above, because it's an "extension", it's an X.509v3 extension. But it sure sounds like it ought to be a TLS extension, and maybe it kinda is, because it has "feature" in it... but that's all very confusing and unclear, despite the attempt at clarity. -- Section 2 -- A Certification Authority SHOULD NOT issue certificates that specify a TLS feature extension advertising features that the server does not support. How does the CA avoid it? The next sentence basically says that the server self-declares what it supporte. How does the CA know for sure? Do you mean that the CA SHOULD NOT issue certs that specify features that the server does not CLAIM to support (you seem to say exactly that in 3.3.1)? Or is there a way the CA can check, and it should do that? -- Section 3.1 -- If these features are requested by the client in its ClientHello message, then they MUST be present in the server's ServerHello. I don't understand the MUST there. Isn't the ClientHello making requests and the ServerHello responding with those the server agrees to offer? Can you explain what you're trying to say with that MUST? -- Section 3.2.2 -- Specifically, a certificate that is signed by a Certificate Signing Certificate that contains a TLS feature extension MUST contain a TLS feature extension which MUST offer the same set or a superset of the features advertised in the signing certificate. A small point, but the double MUST is unnecessary and awkward. I would change "which MUST offer" to "that offers" -- the first MUST has the requirement covered. -- Section 5.2 -- I agree that this is probably not a big deal, but I posit that issuing a cert that clients will reject is likely a much more disruptive attack than refusing to issue the cert in the first place. With a refusal to issue, the server admins know up front that there's an issue and can deal with it directly. With the other, it may take some time to find out that something is amiss, and many customers might be angered in the process (because they couldn't get access to their accounts, or some such). Sure, servers should test their new certs with strict clients before they roll them out... but I'm sure many don't.
draft-ietf-mmusic-rtsp-nat-evaluation
I have two comments: 1. The introduction states that multiple levels of NATs (including CGNs) were not considered. While I understand the history behind this draft and the time frame when it was written, I would really like to see something mentioned about the potential impact on the different techniques. (I could only find a brief discussion in section 4.4 (Latching) to the potential effect of multiple NATs/CGN. Something similar to the text there would be ideal.) 2. Section 8 (Security Considerations) mentions the fact that "three way latching as well as ICE mitigates these security issues and performs the important return-routability check". Please add a reference to this important check. I looked at RFC5245 (ICE), but could not find that check described (just connectivity checks); is that what you're referring to with a different name?
Editorial remarks by David Black, posted here for the record as I understand
that they are already taken into account in Magnus' temp version.
-- Editorial Comments:
Section 4.6.5
OLD
The three way latching is significantly securer than
NEW
Three way latching is significantly more secure than
I saw a number of other editorial items in the newly added text that
I'll leave to the RFC Editor.
idnits 2.13.02 found an obsolete reference:
-- Obsolete informational reference (is this intentional?): RFC 3489
(Obsoleted by RFC 5389)
This is intentional, as the draft refers to an obsolete STUN feature
in that obsolete RFC, so this idnits complaint can be ignored.
I support Alvaro's second comment and think the reference would be helpful to add.
draft-ietf-rtgwg-mofrr
What Ben said:-)
The following is a rant, and I do not expect any changes based on it (edit: or even a response): The security considerations are of the form of "No new considerations beyond XXX". I have no opinion about the truth of that, but I wish draft authors would, in general, include some supporting discussion when making that sort of assertion.
Russ Housley made some comments in his Gen-ART review, but I do not see a response to him, nor do I see any related changes in -07. Can you check if you need to do anything based on his review comments? Thanks.
options 2-4 in section 5 assume a certain amount of flow or application awareness that option 1 does not, option 1 is about control-plne awarness of topology and it seems reasonable to make that distinction.
draft-ietf-intarea-gre-mtu
I agree that adding a para in response to Kathleen's discuss is a good plan.
Thanks for your work on this draft, I have a question I'd like to discuss to see if another security consideration needs to be added. This should be very quick to resolve. Do we need to worry about fragmentation overlap attacks when packets are reassembled? I see that you would not have to worry about it in cases where fragmentation is handled at a different layer as is the case with some of the methods as it might be addressed at that layer. Or does it not matter as the reassembled packets would be forwarded and the device reassembling wouldn't be processing the payload where an exploit could avoid detection?
from Tom Taylor's opsdir review (looks like it's being addressed already)
My apologies -- I let this slip way past due date. This is a review of
operational aspects of this document, primarily for use by the OPS area ADs in
their evaluation of the document.
Summary: this document describes a commonly encountered set of implemented
procedures for handling fragmentation of GRE packets. The described procedures
include configuration options. The document is well-written and ready to go
subject to the following observations, all of which are trivial except for the
second minor issue noted below.
Tom Taylor
1) Very minor issue: there is no advice to the operator on coordinating the
configuration of the ingress and egress nodes. Section 3.3.2 assumes that
configuration is coordinated (i.e., fragmented GRE delivery packets are
reassembled at egress). Section 3.4 simply presents the option. This could be
fixed by changing the relevant sentence of 3.3.2.1 and 3.3.2.2 as follows:
OLD
If the delivery packet is fragmented, it is reassembled by the GRE
egress.
NEW
If the delivery packet is fragmented, it is reassembled by the GRE
egress if the latter is configured to do so.
2) Minor issue: 3.3.1.1, 3.3.1.2, 3.3.1.3 final paragraph:
s/delivery header/delivery packet/
Typos:
Last paragraph before Sec. 3, second line: s/lager/larger/
3.3.1.1 second paragraph, last line on page 5:
s/an Next-hop MTU/a Next-Hop MTU value/
3.3.1.2 first line: s/send/sends/
Sec. 5 last paragraph, fourth last line: s/includes/include/
_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
conflict-review-boucadair-intarea-host-identifier-scenarios
The authors were "kind" enough to ack my comments sent whilst they were proposing that this be an IETF stream document. To be clear: those comments were entirely negative and very strongly against adoption for a variety of reasons. (My input to the thread starts at [1].) [1] https://www.ietf.org/mail-archive/web/int-area/current/msg03883.html From a quick look at the current table of contents and references for this version, I would guess that none of what I see as the numerous fatal flaws in this text have been addressed. (But I've not yet re-read this fully.) I think the IESG should discuss whether or not asking the ISE to add an IESG note would be appropriate in this case. If we decide not to do that, I'll pass my own comments to the ISE in any case, but I think given the previous forum-shopping and what seems like a lack of responsiveness to comment on IETF lists, an IESG note may be right in this case.
conflict-review-sridharan-virtualization-nvgre