IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2011-09-08. These are not an official record of the meeting.
Narrative scribe: Barry Leiba and John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from:
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
Telechat:
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
Telechat:
Telechat:
1255 EDT break
1300 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
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
Telechat:
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
7. Agenda Working Group News
1336 EDT Adjourned
(at 2011-09-08 07:28:13 PDT)
draft-ietf-netext-redirect
I've cleared my DISCUSS. Thanks for addressing my DISCUSS and COMMENT issues in my previous review.
Some pretty substantive changes have been made since revision -07 that came out
of the WG, went to IETF last call, and was reviewed by the IESG. For example,
sections 4.3 and 4.4 introduce new protocol elements.
Surely these changes should at least get sign-off by the WG, and probably should
be subject to renewed WG and IETF last calls.
Thank you for fixing my earlier Comment
There has been quite a bit of discussion about the Gen-ART Review by
Pete McCann on 14-Apr-2011, yet the biggest issues have not yet been
resolved. I do not understand why this document needs to state any
requirements for connections on different access technologies back to
the "home" LMA. Why not allow handoffs with a client-based solution
without this requirement? Doesn't this approach prevent the MN from
subscribing to different operators for each access technology.
Please consider the minor and editorial comments from the Gen-ART Review by Pete McCann on 14-Apr-2011.
Section 7. Configuration variables starts by mentioning that three configuration variables are defined in the document, and then defines ... two. Also - why are these called 'configuration variables' and not 'configuration objects'?
draft-ietf-hybi-thewebsocketprotocol
A couple of reference issues: ** Downref: Normative reference to an Informational RFC: RFC 2818 ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891)
(1) It seems like there should be more of an explicit statement about what's
advisable for an application to do if setting up and using a WebSocket
connection fails. For instance, is it then acceptable for them to fall back to
RFC 6202 techniques, if those might work for them?
(2) Was there an intention to "Update" RFC 2616? Based on the document and the
IETF list discussion, I got the impression that the answer is definitely "no",
but it doesn't seem like there's much (or any) discussion in the document about
the relation between this and 2616. Since this is using some of the 2616
behavior to get rolling, but makes some additions to it, and then has a totally
different flavor afterwards, it seems like a fair question, and it wasn't clear
if the working group thought about it.
In section 4.2.2, is the "might" really a MAY or is it a SHOULD?
First one's a "discuss discuss", the others should I hope be fairly
easily handled.
(0) p23: There is no version negotiation here, right? What happens
if the masking algorithm turns out to be problematic or some other
protocol bug needs fixing and a new version of this protocol is
needed - how will clients and servers get updated to a new version
without a flag-day? (Given that not all clients will be downloaded
scripts.)
(1) p20: Are the new header field names case sensitive? That is,
would "sec-wEBSocket-kEY" be ok? I guess so, but saying that (maybe
by saying that the rules from 2616, section 4.2 apply?) would be
good. Not sure where best to put that text.
(2) p21: I guess if the request includes other things like cookies
or Authorization header fields, then those MUST be processed the
same way that a HTTP server handles them. I think you should say
that if it's true, and even if it's only definitely true if no
websockets extensions are used.
(3) p21: Do you also need to say which optional HTTP header fields
MUST be supported by a websockets server? (Or, is there a general
get-out-of-jail sentence somewhere that says that a server MUST do
all the things a web server can do?) I'm not trying to insist on an
exhaustive list which I guess might be controversial, but the more
you can say here, presumably the more that interop will be improved?
(4) p23: this says the version MUST be 8, earlier it said the client
MUST send 13 - is that a (discuss-grade:-) typo or am I confused?
(5) p24, "If the server supports encryption..." Why is TLS not a
MUST-implement here? I think TLS should be mandatory to implement
for both clients and servers, which needs to be stated, and then the
text here might say "If the server has TLS turned on..." or
something like that. I could live with a SHOULD implement, if
there's a good reason for that, but I'd expect that MUST implement
would be ok for this. Note that I'm not asking for "MUST use" and,
given your definition of client and server is fairly loose, I'd
imagine this ought be painless. And a related point on p55 - WSC
actually only says what are *not* considered strong algorithms. Why
not reference the MTI ciphersuite from TLS 1.2 here and be done with
it?
(6) p30/31: Is it required to use the minimum number of bytes to
encode the payload length? E.g. could I use the 127-case for a
payload of of 8 or 8000 bytes? (Also, you only specify that the MSB
of the length field MUST be 0 for the 127-case. Is that correct? Put
another way, if the payload length is 65535 exactly, can I use the
126-case with 0xffff as the value? I guess yes, but just checking.)
(7) p34: how does fragmentation support multiplexing? I don't see
how that works (without extensions). You should say that extensions
are needed for multiplexing if that's the case.
(8) p37: you don't say that a ping frame can have a payload nor
whether that is masked (and similarly for the pong frame application
data).
(9) p53: The attack model in 10.3 is not clearly described, and
while the claim of "provable" security is made, that is not
substantiated, either here or via references. Since this is the
justification for the masking scheme, I think this needs to be
fixed. I suggest removing the "provable" wording, adding an
informative reference to [1] with a strong recommendation to go read
that, and maybe reducing the amount of text in 10.3 since the paper
does a much better job.
[1] http://www.adambarth.com/papers/2011/huang-chen-barth-rescorla-
jackson.pdf
(10) I think the last call comments about the traffic profile [2]
for websockets being different from HTTP sounds like its worth
including something. While there seems to be controversy about what
to say, I'd hope that some agreed text could be figured out.
[2] http://www.ietf.org/mail-archive/web/ietf/current/msg69148.html
- p20: code "running on www.example.com" is an odd phrase, I think you mean code "running that was downloaded from www.example.com" - p27: referring to "Paragraph 4 of Section 4.2.2" from within 4.2.2 is odd and probably wrong depending on how you count paragraphs. Suggest rewording. - p29: If the ABNF and the introductory text in 5.2 were to be in conflict, which takes prededence? I'm not saying there is a conflict, but that kind of thing happens, so picking one as normative might be useful just in case. - p30: the "%x" notation is odd - why not just specify the values in decimal? If you prefer hex, I'd find 0x8 clearer than %x8. - p30: you don't say until 5.5 that opcodes 8-10 are control frames, but you depend on that in 5.4 where you say "control frames MAY be injected...". Better to move the text at the start of 5.5 earlier. - p33: why does "to be defined later" appear here? (twice) That chunk of ABNF seems a bit flakey since all four frame-*-*-data are just the same binary stuff. - p33: I guess masking is pretty useless if TLS is in use end-to-end, but is still done even with TLS in case the TLS endpoints aren't the websocket endpoints. Is that right? If so, it might be worth pointing out. - p36: why no ABNF for control frames? - p38: "A response to an unsolicited pong is not expected." seems vague. Can't you not say what MUST or MUST NOT happen? - p44: Providing some reference for the "Certain algorithms and specifications..." mentioned in 7.1.7 would be good. (Same comment for 7.2.1 & 7.2.2) typos: - p21: s/doesn't contains/doesn't contain/ - p23: s/a "Origin"/an "Origin"/ - p27: s/other section of/other sections of/ - p36: s/if streaming API/if a streaming API/ - p39: s/base protocols/base protocol/ - p50: s/other section of/other sections of/ - p52: s/in a case of/in the case of/ - p54: s/,TLS authentication./ or TLS authentication./ in 10.5 - p69: s/didn't necessarily endorsed/don't necessarily endorse/
The Gen-ART Review by Richard Barnes was updated to cover the -13
version of this document. The updated review can be found at:
http://www.ietf.org/mail-archive/web/hybi/current/msg08683.html.
The -13 version of the document seems to be better than the earlier
version, but there are two concerns that need further discussion:
1. The browser must be prepared to buffer effectively infinite data,
either from a single frame of 2**64 octets or from a single frame of
unlimited fragments.
2. The masking technique is trivially circumvented and firewalls must
undergo significant update to inspect essentially plaintext content
that will now be carried on ports 80 and 443.
Section 1 has lots of "_This section is non-normative._" That convention isn't defined until section 2, so it's pretty silly to see them in section 1. But even so, I don't think it clears up anything. I would prefer to remove them. 4.1 - "Additionally, if the client is a web browser, an /origin/ MUST be supplied." Also see sub-bullet 8 of the handshake: "The request MUST include a header field with the name "Origin" [I-D.ietf-websec-origin] if the request is coming from a browser client." What happens if a web browser doesn't supply an origin? And how would you know if a web browser didn't do this? (That is, how can you distinguish it from a non-web browser?) I don't see how this can be a MUST. 4.1 - "In a Web browser context, the client SHOULD consider the number of tabs the user has open in setting a limit to the number of simultaneous pending connections." That's going to end up being anachronistic. Let's not put SHOULDs on this kind of user interface stuff. How about instead, "For example, in a web browser context, the number of open windows or tabs are a good indication of the number of simultaneous connections." 4.2 - "_This section only applies to servers._" Seems unnecessary. 4.3 - Do you really intend base64-value (and therefore Sec-WebSocket-Key and Sec-WebSocket-Accept) to be able to be empty in the ABNF? 5.5 - "A response to an unsolicited pong is not expected." SHOULD/MUST NOT be sent? 5.7 - I don't think "_This section is non-normative._" is necessary. Further, this section seems oddly out of place. Perhaps in an appendix?
1) At the next to last bullet in the list of fragmentation rules in section 5.4, can you make it clearer that an intermediary that might fragment a frame will always be able to tell that whether or not extensions have been negotiated? In particular, consider calling out that an intermediary that isn't able to see the server's handshake message (due to it being inside a TLS tunnel for example) also would not "see" individual frames, so it wouldn't be possible for it to try to fragment them. If the assumption in my first question isn't true, then a more aggressive adjustment to the text is probably needed. 2) The text in section 5.5.2 (Ping) could be misinterpreted to require sending a Pong even after receiving a Close (otherwise it violates that MUST). 3) There are currently three ways to say this frame has 5 octets of data. Please consider adding a requirement to use the shortest of those three possible ways. (This is related to one of Stephen's discuss points).
<for the Apps ADs>
This draft contains a normative reference to IDNA2003. While progressing other
drafts through the IESG gauntlet something along the lines of the following was
said "referring to IDNA2003 normatively is going to be a show stopper" and
"IDNA2008 is the go-forward technology". Has the thinking changed? And, can I
use the same magic pixie dust you're using to refer to IDNA2003 when I progress
other non-Apps drafts in the future?
<process weenie>
Shouldn't the RFC 3490 DOWNREF have been called out in the IETF LC? The WGLC on
April 24, referred to fixing all IDNITS, but not the downref to RFC 3490.
</process weenie>
</for the Apps ADs>
#1) I'm sure you the WG addressed this, but it would be great if the hash could
support something other than SHA-1 for the Sec-WebSocket-Key. I assume you've
linked this in some way to the protocol's version # so that websocket++ can
support SHA-256, etc.
#2) Sec 4.2: Should the ABNF for the frame-rsv* be something like:
frame-rsv* = %x0
/ %x1
to allow for the possibility of a "1" value? Doesn't the current ABNF only
allow "0"?
Sec 1.6, p11, last para: Maybe add a reference to http://www.w3.org/TR/XMLHttpRequest/ so people can find where Sec- headers aren't supposed to be set. Sec 5.2: FIN: whether 0 or 1 indicates the final fragment is in ABNF, but it would help to have it in the prose when the field is first introduced. Sec 14.1: Any reason to not point to FIPS 180-3?
draft-ietf-idr-deprecate-as-sets
While I agree with Adrian's procedural comments, I believe that the basic idea is sound.
This is a relatively small Discuss. I have already discussed it with Stewart and
we think we undertand the intention, but I am entering the whole Discuss point
so that the authors can respond...
Danny McPherson wrote the following notes in his Routing Directorate
review.
> I'm still unclear about the proposed publication track for this
> document, and the precise objective. If the aim is to deprecate a
> feature in TWO Standards Track RFCs (4271 & 5065) shouldn't it be
> Standards Track as well and recommend which documents be modified
> in what manner? The current recommendation is that operators stop
> using a Standards Track feature, and this seems a bit backwards to
> me.
All this seems to predecated on the statement that this document
deprecates AS_SET and AS_CONFED_SET. If that was the case then...
Certainly, the document must be updating RFC 4271 and RFC 5065.
So I would expect that in the header and the Abstract, and I would
expect specific discussion in the body with reference to the sections
of those RFCs that are being updated.
As to what track this document should be on...
I can't get excited, but Danny does seem to be right that Standards
Track seems more appropriate.
But I think the point is that you are not deprecating anything in the
protocol. You are recommending against the use of AS_SET and
AS_CONFED_SET. If that is the case:
Change "Deprecate"
- Document title "Recommendation on non-use of..."
- Abstract "This document recommends against the use of..."
- Introduction - delete
Since this practice is thought to no longer be widely
used, it is thought to be safe to deprecate the use of AS_SET.
> Regarding the Introduction and "very seldom used" discussed, I've
> seen this discussion evolve and because "very seldom used" != 0 it
> may be worthwhile to ask either the respective operations communities
> and/or upstream network operators, or perhaps the RIRs involved with
> the number resources in question, to contact and expressly notify the
> current operators that use this feature in order to avoid breaking
> operational infrastructure and encouraging them to change their
> routing design to remove AS_SETs - or to make a real solid case for
> why they cannot.
Again, this is a question of whether support is deprecated, or use is
NOT RECOMMENDED. If you mean to deprecate from the protocol, then I
agree with Danny. If you mean to recommenda against use, then no change
is needed.
I would like to see proper use of RFC 2119 language in Section 3 strongly advised == RECOMMENDED should withdraw == SHOULD withdraw operators may begin filtering == MAY --- Section 3 It is worth noting that new technologies (such as those that take advantage of the "X.509 Extensions for IP Addresses and AS Identifiers" ([RFC3779]) may not support routes with AS_SETs / I prefer s/may not/might not/
should this UPDATE something? e.g. RFCs 4271/5065 maybe
I support Adrian's Discuss, and pete's comments. Either this is an update to the existing standards, and thus should be standards-track itself, OR it is a usage recommendation. Either way, the document, especially, the RFC2119 language, should be modified to reflect the purpose.
Paragraph 1 of section 3 has a couple of places that look appropriate for 2119 language: "are strongly advised to not" could easily be "SHOULD NOT" and "should withdraw" could be "SHOULD withdraw". Indeed, the last sentence of section 3 mirrors the language of 2119 where it says "the operator should understand the full implications of the change." So if you really want to use 2119, it seems like these are good places to use it. However, the one (and only one) place you *do* use 2119 language, it is used incorrectly: It is worth noting that new technologies (such as those that take advantage of the "X.509 Extensions for IP Addresses and AS Identifiers" ([RFC3779]) may not support routes with AS_SETs / AS_CONFED_SETs in them, and MAY treat as infeasible routes containing them. Future BGP implementations may also do the same. This is not defining the optional behavior of treating routes as infeasible. This is saying that it should be noted that new technologies might treat routes as infeasible. I suggest changing "MAY" to "may" or "might". If you put SHOULDs into paragraph 1, include the 2119 reference. If you don't, remove the 2119 reference entirely. Either way, fix the MAY.
The DISCUSS and COMMENT is partly based on the OPS-DIR review performed by
Benson Schliesser.
1. The claim in the Abstract is confusing. The draft proposes deprecation of
usage of AS_SET and AS_CONFED_SET, which seems like a desirable goal. However,
the Abstract claims “[t]his is done to simplify the design and implementation of
the BGP protocol” but the document offers no specific updates to the BGP
protocol. If updates to the BGP protocol are to be done elsewhere, a reference
and/or pointer would be welcome. If no specific protocol updates are envisioned
at this time, and the document is merely suggesting that operators should cease
using these attributes, then this should be made explicit, and maybe a section
that recommends further work on the protocol should be added.
2. Being the most significant element of this draft, section 3 needs to include
more specific details. Operators that already announce routes with AS_SET or
AS_CONFED_SET are advised to re-announce those prefixes without the deprecated
attributes, perhaps undoing aggregation and announcing more-specific routes.
But it should be made clear under what circumstances the original prefix may
continue to be advertised (re-announced), and that in other cases the more-
specific routes are advertised instead (not in addition), etc. This draft
doesn’t need to provide a primer on Internet routing with BGP, of course, but it
should at least give more details and/or pointers on how to implement the
recommendation.
3. Further, the draft should explicitly discuss recommendations to operators
that receive routes with AS_SET or AS_CONFED_SET. The simplest case is to
recommend that these operators continue with status quo. However, the draft
mentions “new technologies” that “may not support” these routes, and that
“operators may begin filtering routes that contain AS_SETs or AS_CONFED_SETs”.
If operators should behave differently as a result of this deprecation, then the
recommended behavior should be described. Likewise, if existing technologies
and/or implementations should be updated as a result of this deprecation, those
updates should be described. The draft doesn’t appear to provide or recommend
any specific updates to BGP; that should be explicitly stated.
1. I support comments made by the other ADs about improper use (or lack of use) of 2119 keywords. 2. In the Introduction section, the second paragraph contains a statement that route aggregation “can cause operational issues that include reachability problems and traffic engineering issues”. From an editorial perspective, this statement might be easier to read if broken into two or three sentences. In any case, it would be valuable for this statement to be expanded and/or include a reference to background information. 3. The third paragraph in the Introduction contains a statement that aggregation benefits are “outweighed” by complexity and confusion. The judgment made by this statement feels correct, but likewise an explanation and/or reference would be useful. Additionally, while the [analysis] reference to “Measurement Data...” provides useful details on the number of routes with AS_SET / AS_CONFED_SET attributes, some analysis of the impact on table size would be useful. Specifically, what is the compression ratio achieved by extant AS_SET routes and thusly how might those routes multiply if replaced by more-specific routes? I doubt that it will have a material impact on default-free routing, but it’s worth discussing if any data is available.
draft-ietf-intarea-ipv6-required
I am not sure what this document adds to the RFC series. Before this document
was written, if an implementation didn't support IPv6, it wasn't compliant with
RFC 2460. Now, if an implementation doesn't support IPv6, it isn't compliant
with RFC 2460 or this document.
--------------------------------------------------------
The meat of this document is in the bullet list at the bottom of Section 2. The
following are comments regarding that bullet list:
1) It is meaningless to levy a new requirement against a "current
implementation". The current implementation has already been implemented. It
can't change.
2) It is meaningless to say that an implementations IPv6 quality must be better
or equal to its IPv4 quality. Since vendors don't produce buggy code
intentionally, it would be impossible to control the distribution of bugs among
features.
----------------------------------------------------------------
The discussion of how this document updates RFC 1812 is distracting. It should
be condensed as follows:
RFC 1812 defines requirements for IP Version 4 Routers, but uses the generic
terms IP and ICMP. In RFC 1812, the generic terms IP and ICMP should be replaced
with the specific terms IPv4 and ICMPv4.
I support the document and it's intent, but would ask the authors to think about
the following:
These two statements seem contradictory:
IPv6 support MUST be equivalent or better in quality and
functionality when compared to IPv4 support in an IP
implementation.
It is expected that many existing devices and implementations will
not be able to support IPv6 for one or more valid technical
reasons, but for maximum flexibility and compatibility, a best
effort SHOULD be made to update existing hardware and software to
enable IPv6 support.
Do the authors mean in the first para : IPv6 support in NEW equipment and
software .......
Also is there any danger that the demand for immediate equivalence
will introduce unintended delays in the deployment of more IPv6?
Section 2 says "IP is redefined to mean IPv4 + IPv6", but I think to be consistent with the rest of the document it should say "IP is redefined to mean IPv6 or IPv4+IPv6"?
I think I am missing the point of this document. It is not that I
disagree with it, but I don't see what it hopes to achieve. Is it the
intention that any node that claims to be "IP-capable" must support
IPv6? Will this document achieve that?
The statement that a user wants an "Internet caable" device and will
not select specifically for IPv6 is fair. But redefining a term that
is current usage will not fix this.
---
There is a slight contradiction between the language in the abstract
where "IP-capable" is redefined to make IPv6 mandatory, and that in
Section 2 where you have "SHOULD not support IPv4 only".
---
Section 2
It is expected that many existing devices and implementations will
not be able to support IPv6 for one or more valid technical
reasons, but for maximum flexibility and compatibility, a best
effort SHOULD be made to update existing hardware and software to
enable IPv6 support.
I think "will not be able to" might better read "cannot be updated to"
because "will not" conveys a confusing future tense regarding existing
implementations.
Does the update intend to be made in the field, or for future shipments?
Is there a statement here about not continuing to ship existing products?
I think this would make a wonderful "letter to the editor" opinion piece. I
would love to ballot "Yes" on this document,m because I share the authors'
opinions. But I don't feel I can do that. I have two major issues with the
document - one is an editorial concern that can be addressed by the authors; the
second is a discuss-discuss.
1) This document uses RFC2119 keywords in a way that I think violates the
spirit, if not the requirements, of RFC2119. I think RFC2119 keywords are not
really meant to be used for what we wish the industry would do, expressed as
MUSTs and SHOULDs. As Ron points out in his reviews, you cannot apply new
requirements to existing implementations - they cannot be changed except by
developing a new implementation (which might be a modified current
implementation).
I think my concerns about the RFC2119 usage could be addressed by modifying the
text.
2) My real concern is that publishing this document a Proposed Standard RFC
might actually be damaging.
IPv4 is being exhausted, and will no longer be suitable as *the* IP protocol
underlying the Internet. The IETF mission is to make the Internet run better. We
have in some ways been amiss in adding on lots of hacks to IPv4, such as NATs,
and we are in the process of adding more.
I believe that we have now reached a point where we are applying life-sustaining
efforts to IPv4 that have exceeded the benefits/cost tradeoff threshold. Many of
these hacks make the Internet run worse, not better. I think it may be time to
declare IPv4 Historic, and stop trying to save it by piling on more detrimental
hacks.
We should **rewrite** documents like RFC1122 to reflect IPv6-only or dual stack
options, to make it clear that an implementation that only supports IPv4 does
not make the Internet run better; By supporting IPv4-only and the needed hacks,
these implementations make the Internet run worse.
This document is a just a band-aid that might make the authors feel good, like
an opinion piece does, but it gives the impression that it might actually
accomplish something. I fear the only thing it will accomplish is to delay the
work of actually rewriting RFC1122 and other documents to recognize that
IPv4-only is no longer adequate for use in the Internet.
I see nothing harmful about this document, but I also don't see that it will have any real-world impact.
1. I support Ron's DISCUSS. 2. I do not understand why this document aims to be a Proposed Standard. There are no testable requirements to allow this document to progress on the standards track. 3. Jouni Korhonen made the following comment in the OPS-DIR review: The I-D is standards track and updates 1812, 1122 & 4084. However, the I-D states: "...Therefore, the above-listed standards are not being updated to include the complete technical details of IPv6, but to identify that a distinction must be made between IPv4 and IPv6 in some places where IP is used generically." I am pointing at this because the current I-D text regarding updates to these specifications is not detailed enough. Just giving few "for example"s is not enough. What I think is needed is a clear (bullet) list of affected sections for each document separately also detailing what is the exact text that gets affected/updated and how. Now too much is left for the reader.. I suggest that this comment is addressed before the document is published.
draft-ietf-pkix-rfc5272-bis
I don't have any problem with this if the WG and people implementing from it are happy with it, but it does seem that the format as just a collection of the changes rather than a stand-alone document to be possibly confusing and error- prone to work from. However, if the real stakeholders are happy with it, then that's all that matters, I guess.
I have not done a detailed review of this document and will trust that the
Security ADs have done.
I am somewhat puzzled by...
This document contains a new IANA considerations section to be added
to [RFC5273] as part of this update.
Section 3.2 says...
Reference: [ RFC-to-be ]
Doesn't the new change subject name thing require a new security consideration? E.g. if an RA says it'd like a new cert renaming stephen.farrell to *.google.com? I think just a sentence saying that the RA and CA need to ensure that both the new and old names adhere to any relevant policies/practices would do fine. There may be a case for also making the general point as well that CAs MUST check names are according to policy/practice as well, but even if so, the new name change thing should also get a mention I reckon. But that can all be done in one sentence so it should be easy.
Please consider the editorial comments from the Gen-ART Review by Elwyn Davies on 5 September 2011.
Lionel Morand raised a few issues related to backwords compatibility of some of
the changes specified in this document. I would like to hear the answers of the
document authors and make sure that these aspects were taking into
consideration.
1. Update to RFC 5272:
- In the section 2.3. (Replace Section 6.3. Linking
Identity and POP Information):
Three mechanisms are defined for linking identity and POP information: witness
value, certificate linking and shared-secret/name matching. In this document,
the first two mechanisms MUST be supported by clients and Servers whereas only
the Witness value based mechanism was mandatory to support and the certificate
based linking was not defined in RFC 5272. This might cause backward
compatibility issues with legacy implementation and some text may be required to
indicate how to deal with legacy clients/servers.
2. Closed
3. Updates to RFC 5273
- In section 3.1. Update to Section 5 TCP-Based Protocol:
A new IANA-registered Port Number is required whereas it was previously possible
to use any port number in RFC 5273. Does it mean that any legacy implementation
will have to be upgraded to support this new registered Port Number?
1. I believe that this format of defining in one RFC updates for other 3 RFCs is quite difficult to read and follow. 2. - In section 2.5. New Section 6.20 RA Identity Proof Witness control: "Identity Proof Version 2" should be "Identity Proof Version 2 control" if I'm correct.
I concur with Wesley Eddy's comment, especially given the scope of changes to RFC 5272.
draft-ietf-p2psip-base
I would like to talk about the topic of vulnerabilities of RELOAD's source
routing capability. As you know, source routing mechanisms have had serious
security problems, for instance problems with the IPv6 routing header type 0
lead to its deprecation in RFC 5095.
Section 12.6 of the RELOAD document says:
Because the storage security system guarantees (within limits) the
integrity of the stored data, routing security focuses on stopping
the attacker from performing a DOS attack that misroutes requests in
the overlay. There are a few obvious observations to make about
this. First, it is easy to ensure that an attacker is at least a
valid peer in the Overlay Instance. Second, this is a DOS attack
only. Third, if a large percentage of the peers on the Overlay
Instance are controlled by the attacker, it is probably impossible to
perfectly secure against this.
And I agree with these statements. However, I would like to see at least some
analysis of the vulnerabilities of your source routing mechanism. You should
assume that there can be malicious insiders in an instance. After all, you are
talking about P2P networks. How serious are attacks from these devices? What
kind of amplification factors might be achieved through an attack?
I have needed to read draft-ietf-p2psip-base at least three times and
talked with one of the RAI ADs and a couple of the authors before
being is a position to be moderately confident with the intent
of this document and the operation of the protocols.
I think that the intent is correct and the IETF needs a protocol
that does application layer routing. However I am not yet convinced
that the design chosen is one that is in the best interests of the
Internet, or that the quality of the document is adequate.
The RELOAD protocol is a monolithic re-creation of all seven layers of
the Internet written using application layer terminology and
techniques. It is thus difficult for those familiar with the
classic method of describing such protocols to be confident
that the text provided is complete, consistent and correct,
particularly in the operational corner and pathological cases.
RELOAD is a what is known in the lower layers as a layer network.
It is regrettable that it does not describe the reason to
recursively reuse each of the "classic" Internet protocols
without explaining why each was unsuitable. This is doubly so
because it is possible that where a "classic" protocol
was unsuitable for RELOAD, the corresponding RELOAD component
may have been a valuable addition in the "classic" network
protocol set. It is somewhat ironic that a protocol designed
using applications techniques does not seem to have been
designed to be recursive since the sub-IP, IP and Routing
layers are commonly used recursively.
It is also regrettable that the document is a monolith rather
than using the large set of small documents approach that
has served us so well in the past in the lower layers. I am
concerned that in the long terms this will cause problems with
maintaining and extending the protocol.
To take routing in particular, this scatted over the document
such that the RTG-dir reviewer and myself were concerned that
much of the protocol description was missing. I am concerned
that structure will make it difficult for implementers to understand
all the corner case conditions during coding and test, and
harder for the operator community to specify and manage their
networks.
I am concerned that the document is really not understandable
without first understanding the CHORD paper, and further
concerned that parts of the CHORD paper are implicitly
normative text in the specification. The technique of
explaining RELOAD-CHORD as a delta on the CHORD paper makes
this particularly problematic. In addition the IETF is not
able to make this essential paper directly available to
readers, nor to issue and manage errata on it.
I am concerned that the only OAM is PING when we have
known for years that to manage a router network you
need at least traceroute and current interest is in
a significantly increased OAM tool set.
If the proposal were to publish RELOAD as experimental I
would leave the draft to it's fate. However it is a Standards
Track Document which means that it has to be sufficiently
free standing and with sufficiently normative text that an
engineer can implement an interworkable version of the
protocol without additional information. Furthermore I
am uncomfortable as to whether the document provides sufficient
detail that two non-interworking implementations can resolve
which is the correct implementation from this specification
alone.
I would prefer that the document be split into a number
of smaller documents: architecture, link connection,
routing, transport, OAM etc in the way that is the
tradition of lower layers. I suspect that this is not
a direction that the authors would wish to take.
I realize that the above is not crafted as an actionable Discuss.
I propose to discuss this on the call with the IESG, and
if no actionable discusses result, or if it is clear that
I am alone in this view, I will move the text above to a
comment and consider abstaining.
I have a number of detailed comments/nits below. == Bootstrap Node: A network node used by Joining Peers to help Nlocate the Admitting Peer. "Locate," rather than, "Nlocate?" == Routing Table: The set of peers which a node can use to route overlay messages. In general, these peers will all be on the connection table but not vice versa, because some peers will have Attached but not sent updates. I had to read this sentence several times to undersand it --maybe just be more explicit in terms of what could in which table while not being in the other table. ICE is used but not defined Finger table is used before it is described rather than defined, and the description really only becomes meaningful with knowledge of the CHORD paper. Skiplist could do with a reference other than requiring the reader to Google for the definition.
Multi-part DISCUSS, which I think requires a document update (and possibly more
discussion, though the email thread between Michael Scharf and Bruce is a great
start):
(1) Section 5.6.3.1 has a handwave about TFRC and TFRC-SP, however those both
require description of how both sender and receiver-side information can be used
to compute loss intervals and measure losses, which isn't here, and may not
even
be necessary here. The section is "retransmission and flow control" but
those
are both distinct (though coupled) with congestion control, and TFRC
answers
neither. I don't think the mention of TFRC is even proper and not related
to
the rest of the section since it's more for applications that are streaming out
data at some controlled rate, rather than sending messages and waiting for
acknowledgements on them or retransmission events. What's here doesn't seem
to
relate.
(2) As noted by Michael Scharf, the RTO computation text in section 5.6.3.1.1
has a confused (or confusing) citation of RFC 6298 and may lead to instability
in
presence of RTT variations.
(3) During discussion of the tsv-dir review from Michael Scharf, it became
evident
that some issues are confusing in the split between the functionality
for end-to-end
message transport across the overlay versus similar functions
that exist
hop-by-hop in the overlay (e.g. by using TCP). Some cases where this
was apparent:
- in the section 1.2.5 mention of "reliability, congestion
control, flow control, etc"
- in the timer discussion around section 5.2.1
- in
the discussion of head-of-line blocking around section 5.5.1.6
- in section
5.6.3, throughout the section
It would be good for clarity to have some text in the architecture section to
describe
the envisioned division of labor between the overlay protocol and the
underlying
(layer-4) transports that are used in the "link" layer and how those
relate to the
message transport sub-layer of RELOAD, especially since those
transports offer
different services to the application. Otherwise, problems
with nested control
loops that exist between layer-4 protocols and various
layer-2 technologies can
similarly arise in RELOAD use.
- It may be a good idea near the beginning of section 1 to be clear as to whether RELOAD is intended to setup P2P overlays per-application using RELOAD, or to setup a single Internet-wide RELOAD overlay that many applications would commonly utilize. Some of the phrasing later in the section can be interpretted either way, e.g. "The RELOAD network" in 1.1 and "RELOAD is fundamentally an overlay network" implies that there is only one and that it can be what the name RELOAD refers to rather than just the protocol. But, of course, this is inconsistent with what other parts of the same sections imply. I could see some people being confused. The terminology actually clarifies it by defining "overlay instance", but that isn't until section 2. It's worth clarifying early on since there have historically been P2P protocols that were single-network in their operation, and so this vision exists in some heads. - In the figure on page 13, "TLS" and "DTLS" might more appropriately be "TLS/TCP" and "DTLS/UDP" in order to include the actual transport layer protocols themselves. - In section 3.1, there may be some confusion between certificates being given to "nodes" versus "users". The text is clear that there can be multiple nodes serving a single user. It might need to explicitly state whether or not a single node can serve multiple users. For potential integration into systems like ISP caches this distinction may be important to clarify. - Section 3.3 mentions NAT traversal as a routing requirement, but it was previously described in section 1 as being a part of the forwarding sub-layer and not the routing sub-layer. I think that the "routing" in 3.3 encompasses both sub-layers (and maybe more) the way that it's being described there.
So I have a humongous set of discusses and comments on this
humongous document. (Probably some of the comments at
least are because this is the first time I've read any of this.)
But, don't get the wrong idea - I quite like this and hope it becomes
an RFC as soon as its ready. Right now though, its not quite ready.
(1) section 3.1: Is collision resistance needed for the case where the
Node-ID is a digest of the node's public key? How is node key
rollover done? Do I loose all stored data? I think you need to
make all those clear.
(2) section 5.1: Does "correctly formatted" include checking signatures
etc? I think you probably mean that it does include signature checking,
but you need to say that.
(3) section 5.1.1: I assume the list entries here are meant to be
mutually exclusive and I'm not meant to do all that apply? Or am I
meant to do the first case that applies. Saying that would be good.
Does the last bullet need to say "not equal to this node and not the
wildcard ID"?
(4) cleared
(5) section 5.3.4: You say that signatures MUST be checked but don't
say how to handle bad signatures. I assume you drop the message?
(Since there are no bad-signature error codes defined.)
(6) section 5.4.2.1: This doesn't say that the JoinAns MUST come from
the peer to which the Join was sent. I think that's needed.
(7) section 5.4.2.1: What prevents/detects replay of JoinReq messages?
If replay worked, then I could cause lots of havoc since the
responding peer will do a bunch of Stores and Updates.
(8) section 5.4.2.2: What prevents/detects replay of LeaveReq
messages? Seems like an obvious DoS if possible.
(9) section 6: is there supposed to be a relationship between the
notAfter value from certificates and the sum of storage_time and
lifetime? I think you need to say something here as otherwise data
could be stored beyond the time at which its signatures are
verifiable. I don't mind if you say that cert.notAfter is the max or
if you say to ignore cert.notAfter but if you say nothing different
implementers are likely to do different things.
(10) section 6.4.2.2: I think you need to say whether or not the
signatures in the StoredData MUST be checked here. I assume you do
want them checked but you don't say.
(11) section 6.4.2.2: If the signer's cert has expired, is a
signature on a stored value still considered valid or not? One issue
is that if any revocation/status checking is supported then there may
not be any such information available for expired certs. Another issue
is that if you do consider signatures only verifiable with non-expired
certs, then a lot can go wrong when a cert expires and its hard to fix
that up. I don't have a good solution to offer, but maybe you have an
answer?
(12) section 7: I don't see how to send a reference to a certificate -
5.3.4 doesn't seem to allow for that now - wouldn't you need a new
CertificateType for that?
(13) section 10.1: I don't get <shared-secret> - is that mode really
well-specified? Seems like you're publishing a shared-secret which
isn't really secret then is it? Or did I miss something? Maybe you
want to say that configurations that use this MUST NOT be publically
available and MUST be locally installed in a trusted way or something
like that?
(14) section 10.1: You don't say here that the signature(s) MUST
verify for the configuration to be used. Neither do you say that the
signers MUST chain up to the one of the root-cert values included in
the configuration. I think you could justify not requiring that, but
then you should say so, so that coder's don't do the wrong thing.
(15) section 10.3: Putting the password (or even username) in the
query string is not good practice - those can get logged by servers
accidentally far too easily. Why don't you define a HTML form that you
then POST?
(16) section 10.3: might need to warn against dodgy username values,
e.g. containing a null character or whatever. I think you need some
more rules there to end up with a safe rfc822name in the cert. (Or
else have an argument that that's not a problem for RELOAD - it has
been a problem elsewhere.) Also, does the enrollment server choose the
domain component of the rfc822 name or may that be supplied by the
client?
(17) section 10.3: What character set is allowed for passwords? What
if something is URL escaped - what's going to match? I'm sure you can
copy from somewhere else, not quite sure what's best though.
(18) section 10.3: You say the signer for this exchange MUST be one of
the root-certs from the configuration. I think that that ought say
that it MUST be a CA and it MUST chain up to one of the root-certs.
Why force the root to be online like that? Or, you could add a new
configuration setting for a user-signing-ca-cert and then it'd be ok
to say that one of those MUST be used for enrollment.
= You could probably say that if this is not a new configuration and
has a root-cert that is common with a previous configuration then the
outet signature MUST verify and MUST chain up to the previous
root-cert.
= I think you can say that the kind-signatures MUST verify and MUST
chain up to a root-cert from the current configuration.
= I think you can say that implementations SHOULD provide a way to
allow completely new configurations, or configuration updates with
only-new root-certs to be accepted but that that's out of scope.
(19) section 13.15: is reg-name sufficiently clear for the overlay
name? For example, that allows percent encoding - are those variant
names all the same overlay? I guess so, but it'd be good to confirm
and maybe say that in the document.
overall:
- I've got to say that this reads a lot like an experimental
specification. Its so complex and has so many moving parts and ways to
plug stuff in, I wonder if its really at the right stage for the
standards track. While I'm willing to believe the WG/AD that it is
(almost;-) ready, I'm still worried a bit that a whole bunch of things could
turn up when its deployed.
- The IPR declaration appears to be for something that has (as far as
I can see) nothing whatsoever to do with the protocol. Who knows, but
the filing seems to be about MIMO, which is a fairly low in the stack
thing to be related to an overlay on top of (D)TLS. Wouldn't it be
nice if that hadn't happened?
- This reminds me of DTNs [rfc4838,rfc5050] but witout the disruption
tolerance. Interestingly, if the timer defaults were made to be part
of the overlay then it could actually be used for a DTN. I can also
imagine that other overlays might benefit from being able to modify
the timer defaults either up or down - so would it be worthwhile
allowing the overlay config to override or specify those default
values?
- There's a lot of lowercase occurrences of "must." It'd be great if
you could clean that up, e.g. saying if they're meant as RFC 2119
terms or not, e.g. 3.3's 1st few uses of "must" seem like they are
2119 terms, but not all others are, e.g. the last one in 3.2.
- A number of the detailed comments below were written as I was
reading the document, and relate to stuff that became clear as
I read further. If the comments says "but what about <foo>?"
and <foo> is explained later on, that means that I didn't get
<foo> on first reading to that point. You might want to consider
adding some text or a forward reference in some of those cases.
I've marked those with (*) in case you want to do that.
section 1:
- It'd be good to restate the peer/client distinction here (from e.g.
the charter) at the very top, e.g. moving the 2nd last para of 1.1
earlier
- Can "high performance" be quantified? If not, then is it really a
"feature"?
- Maybe add a reference to [Chord] in the intro?
section 1.1:
- "connected graph" assumes always-on? needs to be clear, maybe not a
great term
(*) I was wondering what the lifecycle of a Node-ID might be. It became
clear, but only *much* later.
- "also a storage network" - can I store my 24GB of photos using this?
if not (as I expect) then that'd be better stated here.
section 1.2.2:
- maybe clarify that you don't mean cryptographic keys
- add a reference for KBR
section 2:
(*) what's the lifecycle of a Kind-ID? are these also fixed length?
(*) what's the "fixed length" of a Node-ID?
(*) can a single peer/client instance be part of >1 overlay instance at
once? I guess that's just an implementation issue for the peer/client,
but wondered if there's anything that'd prevent that or make it hard.
- typo: "Nlocate" ?
- "Joining Peer" and "Admitting Peer" are those only for peers or
clients too? If the latter, then Node would be right I guess? Section
3 seems to imply that node would be more correct here.
- Connection Table definition refers to Attach handshakes and Updates
but those haven't been introduced yet. Might be better to use natural
language rather than those terms at this point if there's an easy way
to do that.
- Routing Table - the sentence "In general,..." is confusing. You also
use "Attached" but haven't yet said what that means. Maybe just say
that the routing table is a subset of the connection table if that's
the case.
(*) Destination List - isn't that a source route? If not, what's
different? If so, why not say so? Does it include the IDs through
which the message has already been routed or not? Later, (in 5.1.1) I
find out that the earlier IDs are dropped, saying that here would be
good. And also say that its not just Node-IDs, but also Resource-IDs,
that wasn't clear 1st time.
- The last paragraph here seems oddly detailed compared to the others
- would it be better elsewhere? As-is, there's not enough in this
paragraph for the reader to understand this having read to this point
so I think moving would be better. (Not sure where yet.)
section 3.1:
(*) how is the Node-ID included in the cert?
(*) what is "the user name found in the certificate"? that wasn't a
defined term - shouldn't it be? Where is it in the cert? is there just
one user name per cert/user/device?
- 3.1.1 is very short and needs references and maybe more.
section 3.2:
(*) this is the first time that the peer/client distinction and storage
have been mentioned together. Are clients allowed to/required to be
able to store stuff?
- If peers "typically" have "storage responsibilities" does that mean
some peers may never store stuff? How can the overlay tell if that's
the case and not try store stuff at that peer?
- 2nd para here is mostly a repeat. Better to not do that.
section 3.2.1:
- 2nd para/bullet needs some work. "The client can initiate..."
sentence has a few unclear instances of "it" and the following
sentence has one too ("to reach it").
- "learnable via other mechanisms" are those specifed? if not, then
how will it work interoperably?
(*) the text about Node-IDs in certs and Attach/Ping can't be
understood at this stage in reading.
section 3.2.2:
- the list of things a client must (not MUST?) do could really do with
cross references to the relevant sections where a coder can find the
stuff they need.
(*) this says all client (and I guess peer) implementations are
overlay-specific, is that right? if so, that seems to break the
architecture or does it?
section 3.3:
- what is "significant state"?
- Saying "In all cases, the response...needs to (be) delivered..."
seems to be a very hard requirement. Does this protocol really meet
that requirement?
- Saying "...and not to some other node." is odd. I'm not clear what
you really mean.
- I guess inverting the via list can fail if the topology has changed.
Is this handled? What happens?
- This is the 1st occurrence of the term "transaction id." That should
be in the terminolgy section really. Who creates these and with what
scope (e.g. do they need to be globally unique?)
- The figures in 3.3 could do with captions so they can be referenced.
(Same is true generally.)
- The text says that using a transaction id means not having to change
the message, but seems to involve changing the response message. If
so, that should be stated. If not, then briefly saying how that works
would be good.
section 3.4:
- This says that 3.2.1 describes a case of a direct connection to an
arbitrary IP address, but I didn't see mention of that there.
- "need to periodically verify" connections - I assume that's defined
later on in detailmentions
section 3.5:
- typo: using CHORD or Chord consistently would be better
section 3.5.2:
(*) I assume the cache TTL is specified later
- Does caching the set of nodes "it has connected to with public IP
addresses" mean a node has to know all the bogons and not cache those
or is the mention of "public" here just a reference to the bootstrap
phase? (the grammar's not great there either, "nodes to which it has
connected" would be better:-)
- How is the first-ever-node case handled if the network is
temporarily entirely disconnected? Is there a need for a MUST NOT for
implementers that are developing "ordinary" nodes or something?
Without that, how can the node tell if its really the first one or
not?
section 3.6:
- the term "user" wasn't defined - I think it'd be worth doing that to
distinguish it from client/node.
section 3.6.1:
- What trust anchor is to be used for this HTTPS connection? (And add
a reference to 2818 I guess.)
- Does the HTTPS connection here need a reference to 6125? If not,
then is the overlay name supposed to be in the server cert? If not,
then how do I know I've been sent to the right place?
- section 3.6.2:
- If the config document says who's the trust anchor for the overlay
then it probably MUST be gotten securely. But that's not stated. If
this is done in the open, then being clear about the leap-of-faith
step would be good. I mean saying what's important there, exactly when
it happens, what might go wrong etc. That may be later but putting it
here (or a forward reference) seems like its needed.
section 4.1
(*) Signatures imply some c14n rule, esp if supporting
array/dictionary. Is this covered?
section 4.2:
- the list could do with forward references to places where these
items are detailed.
- Didn't it say earlier that Resource-ID=hash(name) was just an
example?
- "...after a network partition." Do you mean "...after a network
partition is healed"? In any case that paragraph confuses me. This is
also the first mention of time sync, so a bit more introductory text
seems needed.
section 5.1:
- This is the 1st mention of the wildcard Node-ID, that should go in
section 2 as well and needs definition. I guess its like an anycast
and not a multicast, unless the overlay does some kind of message
replication.
section 5.1.1:
- This is the 1st time that I figured out that a Resource-ID could be
on a destination list. That should be stated in section 2 which
doesn't make that clear.
- The 2nd bullet says forward the thing but makes no mention of the
Via field. Isn't that needed? (5.1.2 does mention it.)
section 5.1.2:
- It seems odd to have the middle case in presentation order say "if
neither of the other ... apply" since I've not yet read 5.1.3. Maybe
re-order the sections?
- Should that say "neither of the other *two* cases"? 5.1 only has 3
bullets and "neither...three..." would be odd. Or am I missing even
more than usual;-)
- "likely to be responsible" is very wooly, as is "consults" the
routing table.
- Why is it a SHOULD for the case where the 1st entry is on the
connection table? Didn't you define the routing table just to make
this distinction? If the SHOULD is right, then what's the exception?
- "This may be arranged in one of two ways..." and then you have two
MAY statements. There's a MUST missing here.
- The transaction ID example seems to have node C (or A or B) create
the transaction ID and not node D. That should be stated. (I assume
its really the initiator who creates it.)
- Saying "It MAY either be a compressed..." is a bit confusing. I
guess those aren't the only options? (I could encrypt the list to make
a private ID if I wanted, right?)
- What is "FORWARD_CRITICAL"? This seems like an odd place to
introduce the 3 second timer.
section 5.2:
- If alternative routing can be selected on a per-message basis and a
node doesn't support that routing scheme, then what does it do? Drop
the message or use the MTI scheme? Or is this embedded in the overlay
name/ID?
section 5.3.2:
- Is the overlay name that is hashed into the overlay 32 bit value
case (in)sensitive or just treated as octets? If SRV records are used
bootstrapping for this I guess something may need to be said about
this.
- "MUST be randomly generated" - it'd be good to give guidance here
about PRNGs, e.g. maybe cite 4086?
- You don't say where to put a new entry in the via_list. I assume
its at the end furthest from the start of the message.
section 5.3.2.2
- compressed_id was earlier called private ID - why change?
section 5.3.2.3
- the struct has flags before length but the descriptions are length
and then flags. But the length desription says "...rest of the
structure" which could be interpreted to include the flags field. I
guess it oughtn't and just moving the length description should fix
this. Also saying the option value is "length" bytes would be good and
giving an exanple of how to handle length==0 would help too.
section 5.3.3:
- The criticial field in extensions has proved to be slightly
problematic in X.509 over the years. The debate arises now and then as
to what "understand the message" means, with some saying just knowing
the type means you understand it, others saying you need to be able to
do all processing defined for the extension type and some in between.
It would be good to be more specific here about what "understand the
message" means, for example saying that any relevant MUSTs and SHOULDs
are supported or something like that. I'm happy to remove this discuss
point as soon as I'm told the WG thought about this and its ok as-is,
but wanted to check.
section 5.3.3.1
- error_info is a UTF-8 string unless otherwise stated. Is this
intended for human consumption or not? If so, then how are language
issues to be handled?
- I'm not clear as to whether the error_info for the various
error_code values is expected to be as described here. For example, if
the error is Error_Forbidden, does the description of that imply
something about what goes into error_info or not?
- typo: Error_Data_Too_old is repeated.
section 5.3.4:
- might be no harm to also say that the NodeID in H(NodeID ||
certificate) MUST be in network byte order? Saying "simple raw bytes"
could cause endian-issues there.
- This says that "receiving nodes" MUST verify the signature. Earlier
it said that nodes just need to check formatting (in 5.1). That seems
to be a conflict. See also discuss point (2).
- I don't get how the first additional check works if the response has
a via - I thought that that meant that the nodes on the path for the
response didn't need state? If so, then how does the verifier here
know who originated the request to which this is a response?
- The 2nd additional check is a bit unclear for me. It says that
response-sender-node-ID MUST be as close or closer to the resource-id
in the *requesting node's* neighbour table. How does a verifier in the
middle of the path get to see the requesting node's neighbour table?
section 5.4.1:
- Has anyone specified a topology plugin other than the MTI one from
here? I'm wondering if the list here is really complete and doable.
(It'd be easy to get this wrong.)
section 5.4.2.1:
- Which error SHOULD nodes sent if they cannot form connections?
section 5.6.3.1:
- Is the "no more aggressive than TFRC" sentence here clear?
section 6.1:
- given that the StoredDataValue can be up to 4GB would it be better
to put the SignerIdentity before that in the signature input? That
might help the verifier go quicker in the case of LARGE data values I
guess.
section 6.2:
- Is 2^32-1 octets really expected to be supported here? Might there
be a case for distinguishing small (say up to N KB) from larger data
values? (Just checking)
section 6.2.3:
- it'd be no harm to say what you get when a non-existent dictionary
key is used in a query, as you did in 6.2.2 for arrays.
section 6.4.1.1:
- this introduces the "anonymous" and "none" values for
SignatureAndHashAlgorithm on page 88. That really needs to be
introduced where signing is first discussed and you need to say when
its allowed to be used and for what. (In this part you just say it
cannot be used.)
section 6.4.1.3:
- "(unlike previous versions)" - if there's nothing you can reference
then I'd suggest taking this out - it might have been useful for the
WG but might just confuse the RFC reader.
section 6.4.2.1:
- I don't get the last sentence - how does the requester ask for the
user's cert? And should that say owner's cert? (That may be just due
to how long it's taken me to read this, at multiple sittings;-)
section 8:
- You should probably add a reference for the "private address range"
and think about whether or not the putative new private allocation
counts there too. (It may be that getting this document finished takes
long enough that that process is done.)
section 9.7:
- You RECOMMEND that a peer maintain O(log(N)) things in the neighbour
set. I'm not clear how the peer knows the value of N there?
section 10.1
- This is not right! Why not use a real <signature> in the example?
If the example could be verified that'd help coders.
- You might say is ascii-hex values can be mixed case or not. Be a
shame to fall over because of that and coders might make different
assumptions.
- Why are we not using XMLDSIG for the signatures here? (Only
kidding:-)
section 10.2
- s/by determines/by determining/
- Isn't RFC6125 a better reference here than 2818?
- Does this practically mean that overlays should be named using DNS
names? If so, saying that early would be good rather than on p124.
- s/such an/such as an/
section 10.3:
- Does the enrollment server web server cert have to have any
relationship with the configuration? I don't think that's needed, but
am not sure. It'd be good to say either way though.
- Using HTTP errors is fairly coarse grained. In particular don't you
want to have a way to say "everything's fine but you asked for too
many nodeids"? If there's a good HTTP error for that then calling it
out would be good. Just a bare 4xx for username/password errors is
fine though.
section 12:
- Do you need to reference the TLS re-negotiation bug RFC? Would it
have a bad impact here? (Not sure.)
section 13.5
- I don't get why you have two SIP entries there. It'd be nice to
know.
The Gen-ART Review by Mary Barnes on 9-August-2011 points out
significant inconsistencies in the document. Please resolve these
inconsistencies. Please consider the other comments as well; Mary
offers very helpful suggestions. The review can be found at:
http://www.ietf.org/mail-archive/web/gen-art/current/msg06582.html.
3.1 - The concept of "user" appears in this section along with "username", but it never really gets defined, or for that matter is understandable at all, until 6.3. Some introduction to "user" might be nice somewhere at or before 3.1. 5.1.1 - If a wildcard Node_ID is used, does the does the message get sent to the Message Transport for forwarding? Not spelled out in this section. 5.3.3.1 - Editing error: Error_Data_Too_Old is followed by Error_Data_Too_Old 5.3.4 - No discussion of wildcard in this section. Does there need to be? 5.5 - Not clear to me why this document settles on ICE (or anything lower layer). Seems like it could have been abstracted out and left to a different layer. I'm kind of disappointed that all of section 5.5 (and maybe sections 5.6 and 8) is not a separate document.
This document being the principal specification that defines a new protocol I
was expecting to find information concerning operational and manageability
considerations. A separate document (draft-ietf-p2psip-diagnostics) defines
extensions to the base protocol for diagnostic purposes, and this is fine.
However that document is not referred here and there is zero information about
how the protocol will be deployed in existing networks, what is the impact on
traffic and requirements from hosts, routers, midcom devices (if any), what is
the operational model and how is the RELOAD protocol managed in deployments, any
hooks for manageability in the software, any defaults for initial configuration,
alarm conditions, monitoring of performance.
I'd like to talk about several points that I haven't seen mentioned in
other reviews.
1. Section 1.3 appears to couple issuance of certificates and assignment
of Node-IDs (in most cases):
RELOAD's security model is based on each node having one or more
public key certificates. In general, these certificates will be
assigned by a central server which also assigns Node-IDs, although
self-signed certificates can be used in closed networks.
What is the reason for this coupling? Does it have security
implications? At the least, a forward reference to later sections
(e.g., 3.1) might help.
2. Does the use of list compression (Section 5.1.2) and private IDs
(Section 5.1.3) prevent an intermediate node from routing return messages
if its neighbor goes offline? In your example, if E has a destination
list of (D, I) but D goes offline, then E won't be able to unpack the
private ID "I" to recover the via list "(A, B, C)".
3. In Section 10.1, the format of the 'expiration' attribute is not
fully specified (e.g., are timezone offsets allowed or must the datetime
be UTC?).
4. Section 10.1 states that "The configuration file is a binary file
and cannot be changed - including whitespace changes - or the signature
will break." The XML file doesn't look very binary to me! But if you
require special formatting then please specify it, for example by saying
that "the configuration file MUST NOT include any whitespace as
separators between XML elements" or somesuch.
5. In Section 10.3, placing the username and password in the clear as
URL parameters seems a bit dodgy even if SSL/TLS is used, since URLs can
be copied or can otherwise leak out.
1. Regarding communication security, Section 1.3 states: Message Level: Each RELOAD message must be signed. Object Level: Stored objects must be signed by the creating peer. Did you mean "MUST" instead of "must"? 2. In Section 3.1.1, please provide references for TLS-PSK and TLS-SRP. 3. In Section 3.2.1, please provide a reference for TURN. 4. In Section 3.2.1, forward references would help for Attach (Section 5.1.1), Ping (5.5.3), Destination List (5.3.2.2), etc. 5. Section 3.2.2 mentions "the topology plugin required to act as a peer in the overlay"; does this assume a plugin architecture for Node implementations? Perhaps not, because in Section 5.4 the spec talks about a "Topology Plugin" in a more generic sense. It might be good to clarify. 6. The description of symmetric recursive routing in Section 3.3 makes me wonder whether messages themselves are stored at the nodes in the Via list; if so, does that introduce possible concerns related to privacy, security, and auditing? 7. Please expand "ICE" on first use (Section 1) and in Section 3.4. 8. Section 3.6.1 states that "the node does a DNS SRV lookup on the overlay name to get the address of a configuration server"; a forward reference to Section 10.2 would be appropriate here. Also, a reference to RFC 2782 seems in order here. 9. Section 3.6.2 states that "the enrollment server's ability to restrict attackers' access to certificates in the overlay is one of the cornerstones of RELOAD's security"; by "access" seems to be meant "privilege to be granted its own certificate", not "capacity to know the certificates of other nodes". 10. Section 4.1.1 states that "only a user with a certificate for 'alice@example.org' could write to that location in the overlay". At least a forward reference to Section 10.3 would help, which is the only place where the user name is a define as an rfc822Name (at least in the certificate). Furthermore, it would help to more clearly specify how a user name prepared and compared for authorization purposes. 11. In Section 5.1, what exactly does it mean for a peer to "pass a message up to the upper layers"? 12. Is there a reason why the end-to-end reliability mechanism in Section 5.2.1 doesn't recommend exponential backoff on retries? 13. Section 5.3.2 states that "transaction IDs ... MUST be randomly generated"; perhaps a reference to RFC 4086 is in order? 14. In Section 5.3.3.1, it would be good to state whether the "error_info" text is intended to be presented to users (if so, we might need language tagging). 15. In Section 5.3.4, what exactly is "the identity used to form the signature"? It appears to be a Node-ID (or a hash thereof), but it would be good to make that clear in the definition (e.g., could it also be a Resource-ID)? 16. In Section 5.5.1.1, are "srflx", "prflx", and "relay" as defined for Candidate Types in ICE? The "type" is said to "correspond to the cand-type production" but it might help to point a bit more directly to RFC 5245. 17. Section 6.4.1.3 mentions previous versions of RELOAD. Given that no references are provided, is that mention helpful? 18. The <self-signed-permitted/> element is of type xsd:boolean; please note that this datatype has two lexical representations, "1" or "true" for the concept true and "0" or "false" for the concept false. You might want to point this out to implementers. The same applies to the other elements with a datatype of xsd:boolean (no-ice, clients-permitted, etc.). 19. Section 10.1 does not clearly specify which elements and attributes are required and which are optional. Is it assumed that the reader needs to refer to the schema for this information? 20. In Section 12.3, it might be worthwhile to mention the possibility of attacks against the central enrollment authority. 21. In Section 13.6, it's still not clear what it means for an XML format to be binary-encoded. I think this needs to be more clearly specified, then the registration can reference the appropriate section of the spec.
(updated to capture config-chord and to make the comments easier to read.)
The document does not appear to register the namespaces
urn:ietf:params:xml:ns:p2p:config-base and urn:ietf:params:xml:ns:p2p:config-
chord?
The definition of the fragment field in 5.3.2 (page 43) should be updated
to reflect the design choices that resulted in the high bit always being set
(as called out at the end of section 5.7). The definition here implies that
the high-bit might not be 1 in a valid message.
I'm not finding specific normative text that describes how an implementation is
handles a message that has an incorrect version number. The first part of 5.1
talks about "can process" and an "appropriate error", but leaves a lot of room
for interpretation on what those mean. Can this be made more explicit?
Section 3.2.1 has a 2119 MUST, but this section is intentionally non-normative.
Page 38 - Section 5.2.1 - might be worth calling out that the sending node will be doing both e2e and hopbyhop retransmissions Page 48 - Section 5.3.3 - should note 0x8000-0xfffe are reserved Page 82 - Section 6 - Can you find a different word than "unpartitioning" (or define it)? - it only occurs once in the document. Page 107 - the formula at the end of 9.5 has unbalanced parentheses Page 112 - In the implementer note in 9.7.4.3, can you point to references to get the implementer started?
draft-housley-two-maturity-levels
nit - Introduction "This document proposes several changes " should presumably be "This document makes several changes " I am concerned about the following: "Note that the distinct requirement from RFC 2026 [1] for reports of interoperability testing among two or more independent implementations is intentionally subsumed by the requirement for actual deployment and use of independent and interoperable implementations." We really need to consider defining "independent". NTP is a good illustration of the problem - there are lots of boxes out here that run NTP which some may perceive as independent implementations. However they all seem to run the code written by Dave Mills' project arguably making them a single implementation. Since we touching on the subject we should clarify what we mean by "independent" give the existence of open source.
Thank you for addressing my earlier DISCUSS and COMMENT issues. It looks to me as though there is still a bit of redundancy in section 2.2. Do these two paragraphs refer to the same IETF-wide Last Call? The criteria for advancing from Proposed Standard to Internet Standard are confirmed by the IESG in an IETF-wide Last Call of at least four weeks. The request for reclassification is sent to the IESG along with an explanation of how the criteria have been met. The criteria are: [...] After review and consideration of significant errata, the IESG will perform an IETF-wide Last Call of at least four weeks on the requested reclassification. If there is consensus for reclassification, the RFC will be reclassified without publication of a new RFC.
I'm changing to Yes on this based on the recent mails to
ietf-discuss. I continue to think there is rough consensus for
2 levels but am motivated to move to a Yes by the arguments
of those against moving to 2 levels which appear to me
indistinguishable from obfuscation. (Which could be
deliberate or a side-effect of some honestly held opinion,
its not really possible to say.)
This is such a boring topic that a funny quote seems
worthwhile:
“A Frenchman once tried to obfuscate me from behind.
Although I protested out of sheer principle, I must
confess that I thoroughly enjoyed it.”
~ Oscar Wilde on Obfuscation
I think the always-reliable Oscar's quote is as relevant as
the objections to 2 levels that I've seen so far.
My original comment was:
I still don't know from reading this if STD numbers will be
allocated for "Internet Standard" RFCs. I don't mind if
they are or not, but confusion about it doesn't seem good.
For example, what'll happen to [1]?
[1] http://www.rfc-editor.org/rfcxx00.html#STDbySTD
I agree fully with Peter's DISCUSS. He summarized much better than I could have.
I do believe that there probably *is* agreement on the requirement changes to
move from Proposed to whatever is the next level and that these changes do
address a problem by lowering the burden of moving out of Proposed. I would like
to see those adopted, independent of agreement on the other two portions (i.e.,
returning to a lower bar for Proposed, or removing one level of the standards
track).
Section 2 contains the following: Experience with a Proposed Standard often leads to revisions that clarify, modify, enhance, or remove features. Review of revisions to a Proposed Standard that is submitted for publication at the same maturity level is generally limited to the changes. Perhaps r/the changes/these types of changes ? RFC 5967 already updates RFC 2026, but a reference to RFC 2026 in Section 2.2 would be helpful to those writing implementation reports.
draft-ietf-v6ops-3gpp-eps
This is a great document, thank you for writing it. I will vote Yes as soon as
the following issues are clarified:
The document says:
However, there
are network drivers that fail to pass the Interface Identifier to the
stack and instead synthesize their own Interface Identifier (usually
a MAC address equivalent). If the UE skips the Duplicate Address
Detection (DAD) or has other issues with the Neighbor Discovery
Protocol (see Section 5.4), then there is a small theoretical chance
that the UE configures exactly the same link-local address as the
GGSN/PDN-GW. The address collision may then cause issues in the IP
connectivity.
This is true, except that I am not sure about the part that issues in IP
connectivity may arise. The global prefix is not used by the GGSN at all (this
is guaranteed in the specs), so the only issue could be in the use of link local
addresses.
What kind of problems have you seen with this? Since there are no services with
a GGSN, its hard to see what actual traffic might be impacted. Local use of link
locals with other devices on the same connection could be impacted, of course,
you would think that the terminal would use a different address if it was unable
to allocate a link local address. Or if it did not get a problem in allocating
such an address, the communication would be local and the collision would be
undetected. Please expand on what the failure mode is here.
Currently several operating systems and their network drivers can
make the 3GPP PDP Context to appear as an IEEE802 interface/link to
the IP stack. This has few known issues, especially when the IP
stack is made to believe the underlying link has link-layer
addresses. First, the Neighbor Advertisement sent by a GGSN as a
response to an address resolution triggered Neighbor Solicitation may
not contain a Target Link-Layer address option (as suggested in
[RFC4861] Section 4.4). Then it is possible that the address
resolution never completes when the UE tries to resolve the link-
layer address of the GGSN, thus stalling all IPv6 traffic.
Second, the GGSN may simply discard all address resolution triggered
Neighbor Solicitation messages (as hinted in [RFC3316] Section 2.4.1
that address resolution and next-hop determination are not needed).
As a result the address resolution never completes when the UE tries
to resolve the link-layer address of the GGSN, thus stalling all IPv6
traffic.
I don't think there is anything that we can really do on the GGSN side about
this. Since there are no link layer addresses, it would be bad to insert them in
the messages. It seems that the reasonable implementation approach would be to
have the layer that simulates a 802 network fake the necessary addresses and
address resolution messages. If you agree, can you say so? Currently it seems
that you may be saying RFC 3316 should be changed. If you mean that instead,
please say so clearly.
I have no objection to the publication of this document. --- I find myself in agreement with Stephen. the document reads well, but having gone to the trouble to write this guide, I think you could have taken it one step further and described the security issues as well (not that I have a clue what they are, but that is why I would find the description helpful). --- Section 1 OLD There are many factors that can be attributed to the lack of IPv6 deployment in 3GPP networks. NEW The lack of IPv6 deployment in 3GPP networks can be attributed to many factors.
- While I agree that this document doesn't *introduce* any security related concerns, neither does it tell the reader about any, which is a real pity. Are the authors saying that there are no security (or privacy) concerns about 3GPP's use of IPv6, nor any new issues that need(ed) addressing? That seems unlikely. Or, are the authors saying that no-one deploys any security for IPv6 in 3GPP - which would be perhaps more believable but even more unfortunate. In either case, I'd have expected more than one sentence. Other than the above, I quite liked this, (at least... more than any 3GPP thing I've read before:-) and think it could be very useful. - SGSN and GGSN are used in the intro before the terminology section, an English phrase for what they do might be better there, e.g. "various gateways" might do it. - 2.2: many APNs have various IPv4 addresses and username/pwd pairs that are publicly known. I don't know if there's any IPv6 information associated with publicly known APNs (or that ought to be) but if there were that might be of interest. I thought I might see something about that in 8.4 as well but didn't, or at least I didn't get it, if its there. typo spotting: - HSS definition: s/got introduced/was introduced/ - 8.3: s/in order the roaming/in order for the roaming/
I had the exact same thought about the security considerations that Stephen had.
draft-ietf-lisp-lig
1) References to draft-ietf-lisp and draft-ietf-lisp-ms should be normative, not
informative. If the referenbced drafts change radically, the sense of draft-
ietf-lisp-lig may change.
2) It is not clear what needs to be standardized. All of the bits requiring
interoperability are defined in the referenced drafts.
3 )There are 3 instances of lines with non-RFC2606-compliant FQDNs in the
document.
4) There are 24 instances of lines with private range IPv4 addresses in the
document. If these are generic example addresses, they should be changed to use
any of the ranges defined in RFC 5735 (or successor): 192.0.2.x, 198.51.100.x
or 203.0.113.x.
1) The reference to LISP-LIG seems to be self-referential. 2) The reference to draft-ietfr-lisp-alt-06 does not resolve
Responding to Joel Halpern's question about Informational vs. Experimental: I prefer Informational and would not object to Experimental.
Updated Discuss after exchanges with the document shepherd. Most material moved
into the Comment (hoping that the authors will still address it).
I expect the remaining Discuss issue to be resolved by the IESG on the telechat.
---
I am having trouble with this document. I can't work out what there
is to implement for interoperability. I suppose a stretch would be to
say that user-level interop would be achieved by all implementations
of a tool for inspecting the mapping database having the same command
structure. That would reduce the document to some of the text in 4.2.
It is not that I think the document is harmful, it is just that I
don't understand why it is WG Experimental output. Maybe if I had seen
it as Informational I would have been more inclined to accept it. Maybe
if it had come as independent.
Anyway, this is not a big, blocking Discuss. I would just genuinely
like to discuss it to hear what the thinking was in the WG so we can
make sure we do the right thing.
Section 1 s/IDS/IDs/ --- Section 2 s/an destination/a destination/ --- Section 3 Verifying registration is called "ligging yourself". Surely this is "groping yourself"? --- Please add a note somewhere to explain to the reader of this document that the DB is public. I.e. be precise on the fact that the DB is the set of publicly available LISP resolvers. --- Section 8 Please add a sentence stating that LIG can be misused hence the importance to protect LISP-MS and support security features.
- I guess the definitions here aren't meant to be authoritative if they conflicted with e.g. another of the WG's documents. It might be no harm to just say that and point at the document that will have the authoritative definitions just in case. (The UDP port number included here is what triggered this, I guess there's an outside chance that might change for some reason as some other document progresses.) - Some ascii-art would be helpful if the authors had the time and energy, but that might be better in some other draft (or maybe exists elsewhere). - PTR is used but not defined. - Is it right to say "EID address"? There're a couple of those. typos: s/an destination/a destination/ s/an a address block/address blocks/ s/usage cases/use cases/ s/each which/each of which/
Please consider the comments from the Gen-ART Review by Mary Barnes on 10-August-2011. The review can be found at: http://www.ietf.org/mail-archive/web/gen-art/current/msg06586.html.
I agree with Adrian's DISCUSS. I don't see how this is an Experimental document. Looks Informational to me.
I actually liked the way this document is written, the fact that it describes an
operational tool, that it is based on implementation experience and deals how
the tool is deployed and used. Very little documents nowadays include this type
of information.
I somehow must agree with other ADs that the document looks more like
Informational than Experimental. True that (all?) other LISP documents are
Experimental, but this is not an automatic license to make Experimental a
document that would never make it on the standards track and does not describe
any new interoperability element. If the document is to stay Experimental I
suggest that information is added about what are the goals and expected results
of the experiment.
I support Ron's DISCUSS item about the need for Normative References. The document cannot be read and understood without reading those.
s 10.2: r/draft-ietfr-lisp-alt/draft-ietf-lisp-alt
draft-dijkstra-urn-ogf
Please consider the suggestion from the Gen-ART Review by Brian Carpenter on 2-Sept-2011: One tiny piece of future-proofing would be to state that in this context, 'ogf' stands for 'open grid format'. Thus, if the OGF ever changes its name (as it has in the past) or even, unthinkably, vanishes, the namespace would still make sense.
draft-gundavelli-v6ops-pmipv6-address-reservations
There seem to be a couple of syntax issues in this text: OLD: The base Proxy Mobile IPv6 [RFC5213] all though required the use of a fixed link-local and a fixed layer-layer address, NEW: Although the base Proxy Mobile IPv6 [RFC5213] requires the use of a fixed link-local and a fixed link-layer address,
I think this is a useful document. It seems like it should have "Updates: RFC 5213" though?
Section 1 To address this problem, this specification makes the following two reservations. The mobility elements in the Proxy Mobile IPv6 domain MAY choose to use these fixed addresses. Stumbled over this because it looks like the second sentnece is a reservation (i.e. a modification to the base spec), but there is only one reservation listed.
Strike section 2.1. 2119 is not used in this document.
draft-tripathi-roll-rpl-simulation
In general, it is extremely good that we have documents like this. Thank you for doing this work! I have not dug in deep enough to understand the details and whether all the measurements make sense, but I think we should encourage both this document and other similar ones to be published. Thomas Clausen has been showing some measurement results (incidentally with somewhat different conclusions) and I think we should ask him to publish his results also as a similar RFC. As well as others who have data. I also believe that the RFC Editor stream is a good place to put this type of publications. The one high-level comment that I have is that we should be very careful about conclusions from these types of measurements in the resulting RFCs. Its a natural tendency for people to make generic conclusions when most of the results apply to a specific scenario that they measured, not everything. You also have to be very careful in making system-level applicability statements based on single-packet level performance (e.g., 99% packet reliability => system reliability is good -- I don't know if that's the case or not. We'd have to do the math to really understand if 99% is good or bad). I think the authors, the RFC Editor, and the IESG should all check to make sure there are no too wide ranging conclusions in documents like this. Finally, I did have some reactions to this specific document. Please consider them as improvement suggestions. It is of particular importance that we pay attention to various conclusions about the good or bad operation of a given IETF technology, as noted above. ---- Section 3 seems to say that nodes send 80% of their traffic to root, but I can't find a statement that says something about the root sending traffic back to the nodes. I think in most realistic cases there will also be acknowledgments. Am I just missing the text that explains the return traffic, or did you not simulate the return traffic at all? Section 4.3 states that as 90% of nodes are capable of operating under 10 routing table entries, then the protocol is capable of working in constrained nodes. I do not think this can be inferred. If 10% of my nodes have to store significantly larger routing tables (and those nodes are not the root or some other conveniently a priori known device), its not going to help. I still have to deploy more memory to every node. Section 4.4 should make a similar conclusion about the satisfaction of the latency requirements. Again, if 99% of communications are timely, it may not help satisfy requirements of industrial installations, for instance. The requirements are usually stated as, say, no communication failures within a period of time (say, a month or even a year) that could not be handled with the used reliability mechanisms. These mechanisms could include, for instance, repeated transmissions, acknowledgments, or transmissions to duplicate destinations. If a single packet reliability is 99%, what's the likelihood of the a communications problem in an N device system with communication event frequency F and, say, triple transmissions to ensure reliability? You need to do the math to provide an evaluation of whether 99% is good or bad.
Picking up from Peter's point I also started to review text version and realized that there must be a pdf version. Many readers will not know this and will not know how to get the pdf version. They would be better served if a note directing them to read the pdf version was provided at the beginning of the document. Indeed the RFC editor may be spared considerable work by making the text version of the document simply the abstract and a pointer to the pdf. I note that there is no security section to the document. Is this not also mandatory in the independent stream?
I have reviewed this document in accordance with RFC 5742 and am making the
following recommendation to the IESG as a response to be sent to the ISE. The
IESG will formally decide on their response on 8th September 2011.
The IESG has concluded that this work is related to IETF work done in the
ROLL WG, but this relationship does not prevent publishing
=========
Editorial Comments.
These comments are provided for the information of the authors and ISE.
---
It would be considerably helpful if the document included text
explaining the absence of the figures, giving a URL for the PDF,
and resolving any issues of discrepency between the text and PDF files.
---
Section 1 is not clear on the difference between a hop metric and a
transmission metric. Naifly, one might assume that a pcacket is
transmitted exactly once per hop on the path.
---
The reference to RFC 2119 seems inappropriate in this document.
---
You will want to note that draft-ietf-roll-trickle has been published
as RFC 6206
- Luckily, I read the PDF. I agree with the comments that noting its existence in the ascii would be good. - Documents such as this are always much more valuable (IMO) if the underlying simulation code and data can be made available for others. I don't know if that's possible here or has been done, but if so, a link from which those could be downloaded would be a great addition. - Figure 1 has two colours for links but doesn't say why. - I didn't get the spike to the right in figure 9 - it'd be no harm to say why that's there for (I guess) node 38. The scaling on that figure could also be better, the control traffic is hardly visible - a logarithmic scale would be clearer. - 1st para of 5.2 is repeated. - 1st para of 5.2 is repeated.
As this document defines metrics and used them for performance evaluation of
ROLL, should not IPPM and BMWG also b ementioned in the IESG note?
The PDF version makes for interesting reading. Unfortunately, the ASCII version is considerably less valuable because so much of the text makes reference to graphical aspects that are available only in the PDF version.
draft-zhang-ipsecme-anti-replay
We should let this document be published. That being said, I do have a number of
comments that are perhaps best directed to the RFC Editor and the authors.
>and it reduces the number anti-replay window is adjusted.
This text does not parse.
> For high-end multi-core network
> processor with multiple crypto cores, a window size bigger than 64 or
> 128 is need due to the varied IPsec processing latency caused by
> different cores.
I think it is a very bad idea to use implementation strategies that cause
significant
packet reordering. In particular, the interoperability implications
towards implementations
(many) that happen to employ 32 or 64 bit windows... not
to mention impacts to higher layer
protocols.
In my opinion, the document needs to describe its interoperability implications.
I'm not sure if the
IESG needs to require that or if that's just something that
the RFC Editor should ask the authors
to do, but this obviously has an affect to
the ability of an implementation to work with another one.
> In such a case, the window sliding is tremendous
> costly even with hardware acceleration to do the bit shifting.
Really? In an implementation that has to run complex cryptographic operations on
each word in the packet? I can imagine hardware solutions where bit shifting is
really easy :-)
In any case, isn't this just an example of the use of good old circular buffers
(http://en.wikipedia.org/wiki/Circular_buffer)? Elements in the buffer are bits
indicating whether or not the sequence number has been seen, and in addition to
the circular buffer pointers you have to keep a value that indicates what the
first (or last) sequence number in the window is. Then you check for a packet
that has been seen with
seqno >= windowstart &&
seqno <= windowstart + WINDOW_SIZE - 1 &&
circbuffer->table[circbuffer->first + (seqno - windowstart) % WINDOW_SIZE]
Or something along those lines. Is this all you are doing, or am I missing
something? If so, I found the description in the body of the document
unnecessarily complicated.
- Should this have the vendor name in the title? That'd be the "Futurewei IPsec anti-replay..." - last sentence of abstract is unclear - I'm not sure what's being reduced. - intro, 2nd sentence: s/The mechanisms/The mechanism/ - introp, last para: s/For high-end/For a high-end/ s/is need/is needed/ - I don't get this: "We hide one block from the window." Probably just needs re-phrasing.