IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2010-06-17. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Dan, Gonzalo, Adrian
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 Independent Submissions Via RFC Editor
3.3.1 New Items
3.3.2 Returning Items
1253 EDT break
1258 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
7. Agenda Working Group News
1335 EDT Adjourned
(at 2010-06-17 08:30:00 PDT)
Please consider the issues brought up by Ari Keränen in his review: 1. Introduction Abbreviations not opened (NAPTR, NS, SOA). 3.2. 1. Remove all characters with the exception of the digits. For example, given the E.164 number "+44-20-7946-0148", this step would simply remove the leading '+', producing "442079460148". Should say "[...] simply remove the leading '+' and all '-'"? 2. Reverse the order of the digits. Example: "841064970244" 3. Put dots ('.') between each digit. Example: "18.104.22.168.22.214.171.124.0.1.4.8" The digits in step 3 should also be in the reversed order? 3.4.3. Services Parameters service-field = "E2U" 1*(servicespec) servicespec = "+" enumservice enumservice = type 0*(subtypespec) subtypespec = ":" subtype type = 1*32(ALPHA / DIGIT / "-") subtype = 1*32(ALPHA / DIGIT / "-") Missing ABNF reference. Is the lack of upper limit for number of servicespecs and substypespecs intentional?
This is a Discuss-Discuss The telephone number +44-3069-990038 seems to be a currently unallocated, but potentially valid, number in the UK dialing plan. It is a different number than that used in RFC3761. The question arises as to whether this is a well known example telephone number, and if not, whether its use conforms to the IETF policy on examples.
minor comments... I suggest adding a few words explaining how this doc updates RFC3761, similar to the explanation in the IESG Writeup; e.g., "This document updates RFC3762 to reflect major operational issues discovered during deployment." (mostly a curiosity question) The IESG Writeup notes that "RFC 3761 is in wide global deployment". Have the updates in this document been widely deployed? Have they caused any interoperability issues with deployments that have not been updated? In section 3.2: In order to convert the AUS to a unique key in this database the string is converted into a domain name according to this algorithm: 1. Remove all characters with the exception of the digits. For example, given the E.164 number "+44-20-7946-0148", this step would simply remove the leading '+', producing "442079460148". Aren't the "-" characters also removed in this example? I.e., "this step would simply remove the leading '+' and internal '-' characters" ?
[Added another item (# 5), other points are unchanged and I am happy so far with the resolution proposed by authors.] I have a small set of blocking issues which should be straightforward to fix: 1) 3.3. Expected Output The output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the <absoluteURI> production in the Collected ABNF found in [RFC3986]. The <absoluteURI> production was obsolete in RFC 3986, it should be replaced with <absolute-URI>. 2) 3.4. Valid Databases The charset used for the substitution expression is UTF-8. This is lacking a normative reference to RFC 3629 (UTF-8). 3) 3.4.3. Services Parameters Service Parameters for this Application take the following form and are found in the Services field of the NAPTR record that holds a terminal rule. Where the NAPTR holds a non-terminal Rule, the Services field SHOULD be empty, and clients SHOULD ignore its content. This requires a Normative reference to RFC 5234 (ABNF). 4) 3.6. Case Sensitivity in ENUM The only place where NAPTR field content is case sensitive is in any static text in the Repl sub-field of the Regexp field (see Section 3.2 of [RFC3402] for Regexp field definitions). Everywhere else, case-insensitive processing SHOULD be used. Why is the last requirement a SHOULD and not a MUST? Do you know of any reason why an implementation might violate it? 5) In Section 3.4: The charset used for the substitution expression is UTF-8. It seems (and also based on a message from Patrik Falstrom) that the output of ENUM resolution can be an IRI, which means that it might contain non US-ASCII characters encoded in UTF-8. Please clarify if this is the case. Also please clarify whether the hostname part of such IRIs comply with IDNA2003 or IDNA2008 The allowed input characters are all those characters that are allowed anywhere in an E.164 number. The characters allowed to be in a Key are those that are currently defined for DNS domain names.
The document is complete and clear, but there are a number of issues in the Security Considerations section that need attention before I can enter an approval ballot: 1. in section 7.1 I find the following paragraph: > Even if DNSSEC is deployed, a service that uses ENUM for address translation should not blindly trust that the peer is the intended party as DNSSEC deployment cannot protect against every kind of attack on DNS. A service should always authenticate the peers as part of the setup process for the service itself and never blindly trust any kind of addressing mechanism. The other paragraphs in this section use capitalized 2119 keywords - why are they not used here? 'should always' sounds bad in IETF-speak - we use 'must' and probably MUST in this context. 2. Section 7.2: > The caching in DNS can make the propagation time for a change take the same amount of time as the time to live for the NAPTR records in the zone that is changed. The use of this in an environment where IP-addresses are dynamically assigned (for example, when using DHCP [RFC2131]) must therefore be done very carefully. I do not understand what 'must ... be done very carefully' means - I believe that there is a need for different text here.
A number of acronyms are not expanded at their first occurance. For example: NS, NAPTR, SOA, FQDN (expanded in 3.1, but that is not the first occurance), ABNF, ITU-T TSB.
Section 5.2.4: s/more that/more than/ Review by Ari Keränen raised one question: 5.2.3. Enumservice Subtype (<subtype>) Should the Enumservice not require a Subtype, then the <subtype> element MUST be omitted in the registration XML chunk. If a given Enumservice Type has multiple Subtypes, then there MUST be a separate "IANA Registration" XML chunk for each Subtype. Please find further instructions in Section 4. "IANA Registration XML chunk" is a bit ambiguous; especially since Section 4 (where reader is referred to for more information) does not mention "XML" or "chunks". Perhaps using something like "separate record element for each Subtype" would be better, if that's what you mean, or you could add a reference to section 11.2 describing the chunk template.
See <xref type="rfc" data="rfc9999"/>, Section 7. RFC9999 will become a live RFC. Should we not be using an example RFC number in templates such as this? Perhaps RFC2606 would be a suitable RFC?
This is a discuss-discuss, and does not require quthors to make changes to their document (although a few points could be addressed fairly easily). 1) I think it would be a bad idea to publish this document as a standard. Much of what is in this document regarding the process to be followed is already stated elsewhere, in IETF process documents. This is a guidelines document, and as such I would find it much more suitable to be published as an Informational document. Parts of this document standardize a template. If the template portion was published in a standards document separate from the description of IANA process and expert review process and document publication process, then it would make sense to me to publish part of this as standard and part of it as informational guidelines. 2) in 11.5, OLD: It is up to the experts to resolve possible clashes. NEW: The experts are authorized to resolves clashes as they see fit. The requesters may need to update their registration request before getting expert approval. OLD: "Once the experts have approved ..." NEW: "Once the experts have conditionally approved ..." 3) 11.5 sounds like we are creating new process, or committing to a "casting in stone" of our existing processes. 4) in 11.6, there are RFC2119 keywords describing the process, and constraining the possile actions taken by IANA and the experts. 5) in 11.7, "Updates of EnumService Specifications MUST comply with the guidelines described in this document." What happens if the IETF modifies its processes regarding IANA action (e.g., RFC5226) or modifies its process for document publication or its ability to allow IESG override of RFC5226 rules, and so on. Is the IETF still bound by THIS DOCUMENT, rather than by our own updated processes? 6) 7.1 discusses expert review, extending the IETF process to REQUIRE experts to perform additional review" "The experts MUST evaluate the criterion as set out in [RFC5226], as well as consider the following: (and then there is a list of additional steps reviewers MUST perform. While it is good to have criteria defined, the wording REQUIRES the reviewer to perform each of these detailed steps. This feels at odds with RFC5226, "The review may be wide or narrow, depending on the situation and the judgment of the designated expert." I would not want to see appeals filed because somebody felt the expert reviewer didn't follow these rules to the letter.
in 3.2, s/specified in small letters/specified in lowercase letters/ in 11.6, I don't understand "foresees" here.
The Gen-ART Review by Miguel Garcia on 16-Jun-2010 includes some comments that deserve consideration: - Section 6.5: The text reads: IANA will conduct an "Expert Review" ... I guess a designated expert will conduct the review. At most (specially for non-RFC Specifications), IANA will make sure that an Expert Review has been done by and IESG-approved expert. - Section 11.6.1 discusses the process of registering Enumservices through the publication of an RFC. I don't understand the purpose of the second paragraph, which changes the process to IANA. The text reads: IANA MUST only add Enumservices to the Registry, if the experts have approved the corresponding Enumservice Specification as to be published. IANA SHOULD attempt to resolve possible conflicts arising from this together with the experts. In case changes between the approved and the to be published version are substantial, IANA MAY reject the request after consulting the experts. My problem is related to the process. If a document has gone through the RFC publication process, I expect that experts have inspected the document and approved the Specification prior to publication as an RFC, as part of a regular RFC process. This process may differ between standard track RFCs and individual submissions, but in any case, experts are involved in the RFC publication process, and the RFC will not be published if experts speak against the document. Or when do the authors expect that an Internet-Draft could be published without expert review? So, I think that for RFCs, IANA does not need to do anything different from what they are doing today.
I have a small list of issues which I would like to discuss before recommending approval of this document: 1) 126.96.36.199. Protocol-Based Enumservice "Type" Strings A protocol-based Enumservice SHOULD use the lowercase name (Comment) Why use of lowercase is only a SHOULD? What are the reasons to violate it? of the protocol as its Type string. This is missing a reference to the registry that describes valid entries. There are multiple IANA registries related to service (protocol) names, so the exact reference is needed here. 2) 188.8.131.52. Application-Based Enumservice "Type" Strings It is RECOMMENDED that Application-class Enumservices use the lowercase well known name of the abstract application as Type string. Which registry (or document) defines recommended names? Without a proper reference it is not possible to satisfy this requirement. 3) 4.2.4. Data Type-Based Enumservice Class "Data Type" Enumservices typically refer to a specific data type or format, which may be addressed using one or more URI Schemes and protocols. It is RECOMMENDED to use a well known name of the data type or format as the Enumservice Type string. Is there a registry that defines recommended names? If there is none, there is no way to satisfy this requirement. Examples of such Enumservices include "vpim" [RFC4238] and "vcard" [RFC4969]. 184.108.40.206. Data Type-Based Enumservice "Type" Strings It is RECOMMENDED to use the lowercase well known name of the data type or format as the Type string. As above. 4) 11.1. Registry Update IANA will update the Registry "Enumservice Registrations" as defined in (this) Section 11, which will replace the old mechanism as defined in RFC 3761 [RFC3761]. It is noted that the process described herein applies only to ordinary Enumservice registrations (i.e. the registration process of "X-" Enumservices is beyond the scope of this document). What about "P-"? 5) [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. I think this reference is Normative. E.g. it is used normatively in Section 5.2.4. 6) DISCUSS DISCUSS: draft-ietf-enum-enumservices-transition-05.txt requires review by the Designated Expert. Who is the Designated Expert for this document?
6.5. Step 5: Expert Review IANA will conduct an "Expert Review" according to [RFC5226]. IANA doesn't "conduct" Expert Reviews (or hardly ever), it initiates them. 7.3. Appeals Appeals of Expert Review decisions follow the process described in section 7 of [RFC5226] and section 6.5 of [RFC2026]. What is the first line of appeal? Is it IESG or RAI ADs? 11.7. Change Control Enumservice registrations MUST NOT be deleted. An Enumservice that is believed no longer appropriate for use can be declared obsolete by publication of a new Enumservice Specification changing its <usage> element (Intended Usage) to "OBSOLETE"; such Enumservices will be clearly marked in the lists published by IANA. As obsoletions are updates, they are also handled the same way as initial Enumservice Registrations. I am wondering if this is too heavy weight. Have you thought about allowing "IESG action" as an alternative here?
Based on the explanation provided by one of the authors (Bernie Hoeneisen), I'm escalating this from a COMMENT to a DISCUSS. Section 11.6.1 states: IANA MUST ensure that any further changes the Enumservice Specification might undergo before final RFC publication are approved by the experts. Bernie Hoeneisen explained that this text is attempting to address perceived shortcomings of RFC 5226. However, if there are problems with RFC 5226 then we need to fix that spec, not update it only for ENUM service registrations via this I-D. Furthermore, this proposal appears to be involving the IANA in processes that are currently under the purview of the RFC Editor. Therefore I am blocking this document pending input from the IANA and the RFC Editor.
Consider deleting Appendix A and pointing to enumservices-transition instead.
Based on Ari's review, Section 4.17 XML fragment: <urischeme>sip, sips</urischeme> breaks a requirement in -guide Section 5.2.4: If there is more that one URI Scheme, then one <urischeme> element per URI scheme must be used in the XML chunk. (By the way, why aren't the "must"s in -guide "MUST"s?)
Ari Keränen's review said this: None of the references with numbers (e.g.,  and ) are defined. The requesters are not defined anywhere, just their IDs are (i.e., no "people" and "person" tags). Some records with subtypes provide identical functional specifications for all subtypes while there is difference (albeit often small one) on what is defined. For example, "http" and "https" subtypes with "ical-access" and "sip", "sips" and "tel" subtypes with "voicemsg". A word or two about the difference would be helpful (e.g., "https" subtype type could use words "over HTTPS" or "using TLS or SSL"). 4.14. pres <functionalspec> See <xref type="rfc" data="rfc3953"/>, Section 4. </functionalspec> This is a quite minimalistic functional specification. Adding even just a single sentence mentioning "presence" would be helpful. Something like "This Enumservice enables presence information to be provided for an E.164 number." Same issue e.g., with 4.17, 4.35, 4.36, etc. 4.17. sip <urischeme>sip, sips</urischeme> I guess this should be two separate urischeme elements. 4.24. vcard Same problem with multiple urischeme elements.
I found multiple undefined references in the document (the list might be incomplete): RFC3861  iMIP  CalDAV  RFC4694  'http:'   and  Short Message Service (SMS)  EMS content is sent over SMTP using the format specified by TS 23.140  Section 8.4.4 and TS 26.140  Section 4, as an MMS message. The header fields used in such MMSE are described in detail in .
#1) draft-ietf-enum-3761bis-08.txt also obsoletes RFC 3761.
Contains several unused references.
I think [4741bis] is used normatively. Please makeit a normative reference. --- Aren't the RFCs cited from Reference clauses really normative references? (As Dave says, to avoid citation issues, you should include some text such as... "This module makes use of references to , , ..." )
Section 3.1 Are there no other negative responses to get-schema? What about policy failures? --- Please think about whether the Reference clauses that cite RFC4741 should actually point to 4741bis.
Hmmm, my DISCUSS comments were not included in the datatracker. Saving and emailing again. Good job. I am glad to see this work and the YANG work progressing. I have a few thinsg i think should be addressed before this is approved as a standard. 1) username - in ISMS we had a lot of trouble determining when and if the user- name from SSH was actually available, and the SSH username can be blank (IIRC). In other transport authentication schemes, a username may not be available. But this information might be critical for use in access control decisions, which currently are implementation-specific. Security considerations does not discuss this potential problem. In ISMS, SSHTM permitted transformations from the "username" used by the transport to a management-system specific identifier. In USM, this is also done via a user table assignment. You should be careful about locking yourself in. 2) existing security infrastructures, such as SSH, may offer features that would make doing a direct mapping between user-name and the nsm username. Because naming policies might differ between administrative domains, many SSH client software packages support a user@hostname:port addressing syntax that operators can use to align non-equivalent account names. The SnmpSSHAddress Textual Convention echos this common SSH notation. Again, you might want to avoid a direct mapping requirement. I recommend removing the statement about how username is set from SSH, and simply state that the identity is established by the Netconf transport protocol. Let the Netconf-ssh decide how to establish a username. 3) the algorithm to derive the username is implementation-specific. The security considerations should discuss that different implementations might derive the same username for different users, so the value might not be comparable across implementatons. In ISMS, we addressed the issue that an SSH transport model might come up wth a name, and then a TLS transport model come up with the same name, even within the same management system. Given that the username might be used to identify who made an undesirable change, and to discipline that person, this is a pretty big "well, maybe this means this user, and maybe it means that user." 4) Your use of "RFC XXXX" is ambiguous. "identity YANG" and "identity yin" call for a reference to RFC XXXX (the YANG RFC), as does the "module" and "revision" statements (the monitoring RFC). These are different XXXX's. 5) container sessions has an exclusion statement that can be interpreted different ways: "Any session not managed by the NETCONF server ... MUST be excluded" versus "(Any session ... with session identifier 0) MUST be excluded" versus "(Any session not managed ... with session identifier 0) MUST be excluded" (which would exclude all non-zero sessions) Can you tighten this? 6) To avoid unused reference warnings from idnits, in MIB modules we specify outside the module itself what normative references exist in the module and provide citations.
1) section provides an overview of data "which MUST be present". "MUST" is usually used to specify normative behavior. I suggest you specifically say that section 2 is a "non-normative overview", so that if there are errata that lead to conflicts between 2 and 5, there is no question that section 2 is non- normative, and section 5 is normative. 2) login-time. since clocks on the server and client can differ, this should say the "Time at the server at which the session was established." 3) source-host: this is the netconf client? (which could be different than, say, the SSH client or the TLS client, etc.) 4) leaf source-host s/is likely to be implementation-specific /is implementation-specific
2.1.3. The /netconf-state/schemas Subtree version (string) Version of the schema supported. Multiple versions MAY be supported simultaneously by a NETCONF server. Is this related to YANG revision? 2.1.4. The /netconf-state/sessions Subtree transport (identityref, transport) Identifies transport for each session, e.g. "netconf-ssh", "netconf-soap", etc. Are you planning to have a registry for these? 3.1. The <get-schema> Operation format (identityref, schema-format): The data modeling language of the schema. Default value is 'yang' when not specified. Optional parameter. Are you planning to have a registry for these? 4.1. Retrieving Schema List via <get> Operation The response data can be used to determine the available schema and their versions. The schema itself (i.e., schema content) is not returned in the response. The optional <location> element contains a URI, which can be used to retrieve the schema by another protocol such as ftp or http(s), or the special value 'NETCONF', which means Informative references to documents defining HTTP and FTP are needed here. that the schema can be retrieved from the device via the <get-schema> operation.
This discuss is a placeholder for already agreed updates to the security considerations section. I will clear when the new draft appears or for an RFC Editor note inserting the following at the beginning of the security considerations: The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC4741]. The lowest NETCONF layer is the secure transport layer and the mandatory to implement secure transport is SSH [RFC4742].
I support Tim's DISCUSS position.
I share Tim's concern that we need to explore the extent of IETF consensus on this proposal. In particular there are not many m/c /8 left so we need to make sure the allocation is well used. One limitation of the proposed method is that a small organization has an extremely limited number of m/c addresses that that can create by this mechanism. Did the WG consider, for example, the creation of a registry of organizations that wanted m/c addresses but which did not have a 16bit AS number, since this would have allowed greater flexibility in the number of m/c addresses an organization could own? Also I had to stare at this figure Bits: | 8 | Unicast Prefix Length | 24 - Unicast Prefix Length | +-----+-----------------------+----------------------------+ Value: | TBD | Unicast Prefix | Group ID | +-----+-----------------------+----------------------------+ for a while before I understood it and wonder if there is a better way to show this.
Please consider the Gen-ART Review by Francis Dupont on 2010-05-12: - 1 page 3: assignment ... need -> assignments? (please reread the statement and improve it)
This is a discuss-discuss. It feels a bit odd to be evaluating a standards track competitor to a current BCP (RFC 3180). This document does not update or obsolete 3180, but contains rather strong arguments for the superiority of this mechanism. I would like to explore the level of IETF consensus for this specification, and the implications (if any) for RFC 3180.
I agree with Peter's concern WRT the document name. The Abstract could also do with clarifying to indicate this is a deployment imperative and not input to a new protocol specification.
The Gen-ART Review by Avshalom Houri on 2010-06-11 raised a question about about this portion of the document: > > That requirement is hereby relaxed. A resolver SHOULD send a UDP > query first, but MAY elect to send a TCP query instead if it has good > reason to expect the response would be truncated if it were sent over > UDP (with or without EDNS0) or for other operational reasons, in > particular if it already has an open TCP connection to the server. > The question was: > > What should be the behavior here? Try TCP and then revert to UDP? > What should be the timeout for the TCP trial? Seems that this needs > a bit of clarification. > The response to this question makes sense: > > In the latter case no text should be necessary (IMHO). This > document doesn't change the protocol processing. This particular > section merely permits TCP first in some cases, relaxing > Section 220.127.116.11 of RFC 1123. > A statement that this is relaxing Section 18.104.22.168 of RFC 1123 seems like an excellent idea.
Section 4, second bullet: s/so that the do not/so that they do not/ Is the text regarding proprietary stub resolvers in section 4 necessary? The section opens with "All general purpose DNS implementations MUST ...", and a proprietary stub resolver seems to be explicitly outside the scope of the section. If it is needed, I would suggest replacing that paragraph with something a little more restrictive, along the following lines: Stub resolver implementations specifically designed for deployment in restricted environments where truncation can never occur, or DNS lookup failure is acceptable, MAY omit support for TCP.
1. It would be useful to indicate the reference for the terms used in the normative text in section 4 (authoritative server, recursive resolver, stub resolver) - RFC 1035 or other 2. insection 5: 'This document therefore RECOMMENDS ...' - this phrase needs to be reformulated as 'RECOMMENDS' is not the 2119 keyword to be used in a capitalization
1. The title "DNS Transport over TCP - Implementation Requirements" makes it sound as if this document is defining requirements for subsequent work regarding implementation of DNS-over-TCP, not requiring implementations to support DNS- over-TCP. Perhaps something like "TCP Required for DNS Implementations" would be clearer. 2. The document exempts "proprietary stub resolver implementations" but does not define "proprietary" in this context. Does this mean that as long as my implementation is not open-source, I don't need to support TCP? Or by "proprietary" does the author mean that the implementation is deployed in a particular environment (as seems to be implied)? If the latter, then the exemption applies to deployments, not implementations.
These comments are all minor: 1) The first bullet of section 4 could be read incorrectly to mean that an authoritative server implementation can not limit the size of responses for any reason. 2) It is odd to put normative requirements (MAY) on proprietary (hence non- standard) implementations. Can the section about stub resolvers be rewritten as simple commentary? 3) +1 to Dan's comment re: RECOMMENDS
I'm glad to see this extension/relaxation move forward. It is needed. Thanks for writing this draft and bringing it up to the approval stage.
Contains several unused references.
I am no expert, but I found this document very readable. Thanks. It looks to me that this document is updating the IKEv2 specification. As the Abstract says... IKEv2 specifies that EAP authentication must be used together with public key signature based responder authentication. But this document seems to change that rule. So that would make it an update to RFC 4306 wouldn't it?
Section 4 The following EAP methods are believed to be secure when used with the current extension. In addition, there are likely other safe methods which have not been listed here. I found this text less than helpful. "believed to be secure" by whom? It surely makes a diffuerence whether we are talking about my 3 year old grandson or my 18 year old dog. "there are likely other safe methods which have not been listed here" Well, thanks! How is that helpful?
1) A number of terms are used without first expansion. for example, SK_pi, SK_pr, the terms in the flow diagram of section 3 (SAi1, KEi, Ni, etc.) I realize these are probably well-known to IKEv2 implementers, but not necessarily to others. I recommend, at a minimum, a comma-separated list of these terms and where their definitions can be found. 2) section 6.3 identifies a vulnerability, but provides no recommendations for how to mitigate the threat. If this vulnerability cannot be mitigated, then I question whether this should be approved as a standard. 3) section 6.3 talks about "(in message #3)" - where is message #3 defined? also messages 1,2, 3, and 4 in section 3.
1) I found it odd to have channel binding in the table in section 4, when there had been no discussion of channel bindings. I actually notated the text as "why discuss this here?" I found the discussion of the importance of channel bindings in section 6.2, which made it clear why this was being included in the table. I recommend moving the discussion of channel bindings (the 3-paragraph short summary from 6.2) prior to the table (or move the table back) 2) I found the text odd in 6.2 that says AAA proxies MUST be trusted ... and avoided. I assume there is someplace in the AAA standard that says that proxies MUST be trusted; it would be nice to specify where that is stated. and then it would be nice to explain WHY they should be avoided. 3) section 6.4 says "(The EAP Identity request/response pair is omitted, as usual in IKEv2.)" Does this mean the pair is omitted in IKEv2 documents by convention, or omitted in protocol exchanges? if this means protocol exchanges, can you cite where this is defined? 4) section 6.4 says ""In the context of the extension described here, this guidance applies both to the authentication of the client by the gateway and vice versa." I find this unclear. I find "In the context of the extensions described here" rather abstract. The guidance appears to be that one should use the EAP authenticated identity, but it is unclear to me when this should be used. The paragraph talsk about routing AAA messages and selecting authentication and EAP types, but it seems to be me it cannot be used when routing AAA messages and to select authentication, since you wouldn't have an authenicated EAP identity yet. Could this paragraph, or at least applicability of the guidance, be restated? 5) in section 6, "this is somewhat unfortunate" seems to be an opinion that doesn't seem helpful to nayboidy implementing this standard. Do we need it here? 7) 6.5 put a discussion about responder indentity in the middle of a discussion about initiator identity. The third paragraph seems much more natural directly after paragraph 1. 8) B1. what ar ethe pro and cons of B1? of B.2? of B.3? 9) g^xy might be well-known to IKEv2 experts; should I just assume it is an abbreviation for galaxy? ;-)
Please consider the Routing Area Directorate review from Ross Callon.
Hi, 1) Section 3.3 contains a list of RFCs; in the References, some are listed as normative, others as informational. Since they are the subject of a SHALL, I think they should all be normative. 2) There is a "MAY unless" that is itself inside a conditional. Normative language might be clearer specified outside the conditional, and specified as a "MUST NOT if". Are the following equivalent? OLD: Where enhanced security is desirable, and a trust relationship exists between an LSR and its peer, the LSR MAY choose to discard a packet received from a particular neighbour unless one of the following two conditions holds: NEW: Where enhanced security is desirable, and a trust relationship exists between an LSR and its peer, the LSR MAY choose to discard a packet received from a particular neighbour. The LSR MUST NOT discard the packet if: 3) The conditions for the "MAY unless" talk about "Any MPLS label". Is this any label in the relevant packet, or a global "any label"?
Comments: section2: "occurs" is used twice as the verb in a sentence s/further processing occurs to determine the context of a packet occurs when/ further processing occurs to determine the context of a packet when/ 3.2 lists the service types. It would seem nice to be consistent with the list of LSP types in 3.1.3; on first glance, it appears only three of the four LSP types are permitted to be supported in a section. If I understand correctly, you simply chose to aggregate the bidirectionals into one entry here, while not aggregating them in 3.1.3. 3.3 might be more easily readable if you included titles (or hints) about the contents of the RFCs listed. It would be nice if the list was in numerical order. s/the the/the/ "note that" is seldom actually needed, since you are noting it. s/Note that a swap /A swap s/Note that, except for/Except for s/Note that the requirements/The requirements s/Note that this does not preclude the future definition /This does not preclude the future definition s/Note that the payload of an MPLS-TP LSP may be a packet /The payload of an MPLS-TP LSP may be a packet/ s/Note that the MPLS label stack/The MPLS label stack / s/Note also that in order/In order s/Note that an LSP of any of the types listed/An LSP of any of the types listed s/Note however that MPLS-TP forwarding/MPLS-TP forwarding s/Note that normal packet forwarding/Normal packet forwarding s/Note that what appears/What appears
The following spurious text appears in the IAN section: To: email@example.com Subject: Registration of new Sieve extensions
Section 1 For clarity, I suggest... s/users may not be allowed/users might not be allowed/ or s/users may not be allowed/users are not allowed/ --- Section 1 s/sieve/Sieve/ --- Section 4 OLD None of the new envelope parts defined here have address syntax NEW None of the new envelope parts defined here has address syntax
Please consider the Gen-ART Review comments by Spencer Dawkins: Section 7, redirect-deliverby extension, says: > > :bytime specifies the number of seconds within which the message > should be delivered. :bymode specifies whether a notification should > be sent or the message simply returned if the time limit is exceeded. > The default is "return" if :bymode is not specified. See The > semantics of delivery time limits are specified and discussed at > length in [RFC2852]. > Spencer said: I'm not sure if this is a cut-and-paste error or if you really meant to say something that got left out, but someone smarter than I am needs to look at the "See The" here.
I think Ned argued successfully against this change, but I haven't checked all email exchange between Ned and Tero: Section 5 also says that the "bytime" is "the initial integer part of the delive-by extension", but then comments that deliver-by by-time is decremented as message passes through the transport infrastructure. This does not make it clear whether the Sieve filtering system should also decrement the number while message is waiting to be processed. I.e. if message was received earlier, but it took some time before the Sieve email filter could be run on the message, should the "bytime" be the original time from the smtp MAIL FROM BY= part, or whether it is decremented. (This needs to be clarified for both "envelope-deliverby" and "redirect-deliverby", because the answer is likely to be different for them.)
Section 5. The first paragraph states: The "envelope-deliverby" extension does not define any new tests or actions, rather, it adds three values to the list of possible (case- insensitive) envelope-part strings defined in Section 5.4 of [RFC5228]. but the text following the list of envelope-part strings states: All of these tests fail unconditionally if ... perhaps the following substitution would be clearer: OLD All of these tests fail unconditionally if the BY SMTP MAIL FROM parameter does not exist for the current message or recipient. NEW The envelope test fails unconditionally for each of these envelope-part strings if the BY SMTP MAIL FROM parameter does not exist for the current message or recipient.
I support Alexey's DISCUSS position.
I support Peter's discuss.
Given RFC 4270 and subsequent research over the last 5 years, this statement is surprising: It is known that SHA1 and SHA256 hash spaces are resilient to collisions, If you are going to assert that SHA1 is resilient to collision attacks, I think you need to provide some evidence.
You might motivate the discussion more clearly. For example: A message can contain multiple signatures of a common sender authentication mechanism, such as [DKIM]. In fact you are talking about multiple signatures from the same sender, not signatures from multiple senders. Perhaps you could add a sentence about why the same sender might sign the same message twice. Furthermore, you might provide an example at the beginning to show such a message "before header b".
I support Peter's DISCUSS.
A reference to POSIX spec or the term "UNIX time" would be useful for clarity -- I had to look up whether the definitions are the same here and there. (Both DO skip leap seconds but I didn't remember if that was indeed the case.) This could be added as an RFC Editor note.
Section 5 says However, if both of these attributes are present, they MUST provide the same date and time. Wouldn't it be helpful to say what should be done if they do not provide the same date and time? --- Let is be a lesson to all writers and reviewers of I-Ds. The Abstract says: This document specifies a new ASN.1 type This is no longer true; the novelty has worn off.
I am not sure that RFC2119 language is appropriate here Figures 1 through 5 show models that MAY be used when benchmarking Sub-IP Protection mechanisms, which MUST use a Protection Switching System that consists of a minimum of two Protection-Switching Nodes, an Ingress Node known as the Headend Node and an Egress Node known as the Merge Node. Ideally the RFC2119 definition should appear before first use in the document The Protection Switching System MUST include either a Primary Path and Backup Path, as shown in Figures 1 through 4, or a Primary Node and Standby Node, as shown in Figure 5. I am not a mathematician, can an equation have a pluarity of sub-equations, or is a different mathematical construct needed? TBLM as shown in Equation 2: (Equation 2) (Equation 2a) TBLM Failover Time = Time(Failover) - Time(Failover Event) (Equation 2b) TBLM Reversion Time = Time(Reversion) - Time(Restoration) Same with Eq3
Section 3., paragraph 0: > 3. Test Considerations DISCUSS: Some of the "discussion" sections of the definitions in Sections 3.1-3.4 use RFC2119 terms, which is not appropriate, because those paragraphs are clearly informative.
> Benchmarking Terminology > for Protection Performance As stated in the abstract, Section 3.5 actually defines some tests. The title should reflect that this document is not only defining terminology. Section 3.1., paragraph 4: > b. Ri is a node which forwards data frames to R[i+1] over Link > Li[i+1] for all i, 1<i<n, based on information in the sub-IP > layer. Since R1/L12 are defined in (a) and (c) defines Rn, you probably want to change 1<i<n to 1<i<n-1, so that Rn isn't defined twice. (And then you need to define L(n-1)n in (c)). (I also wonder why you define these sets of links and nodes when they aren't used anymore in the remainder of the document.)
I have a huge raft of issues and concerns about this document. In the end I raised a COMMENT not a DISCUSS because I don't believe that the publication of this document as an Informational RFC without making the changes will be harmful. However, attending to these comments would, I believe significantly improve the value of your work. The responsible AD may decide that the comments need to be addressed. --- idnits (http://tools.ietf.org/tools/idnits/) throws up a number of issues. Although many of these are minor or editorial, it would have made the document easier to read had you fixed them. I think that some of the boilerplate issues are more significant and that the I-D cannot be accepted unless a new revision with the correct boilerplate is submitted. The document writeup says: (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? There are a few errors in the nits: http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-bmwg- protection-term-08.txt These can be corrected after AD-review, but there will be some work necessary to adopt the new boilerplate, update references, fix page lengths, etc. Clearly this did not happen, and I really think we need to push back on document shepherds to understand that the only acceptable answer to the question is "Yes, idnits passes cleanly". --- There is a significant different between the document title ("Benchmarking Terminology for Protection Performance") and the content of the document as explained in the Abstract and Introduction. Viz. This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms. 1. The title should mention metrics 2. The title should indicate the scope is sub-IP --- The Introduction starts off with... Technologies that function at sub-IP layers can be enabled to provide further protection of IP traffic by providing the failure recovery at the sub-IP layers so that the outage is not observed at the IP-layer. This seems a reasonable statement, but isn't it in contradiction with the whole premise of this document as stated in the Abstract... The performance benchmarks are measured at the IP-Layer, avoiding dependence on specific sub-IP protection mechanisms. In other words, if the outage is not observed at the IP-layer, how will you measure the benchmarks at the IP-Layer? --- I would really have liked this work to be aligned with RFC 4427. That document sets out terminology for protection and restoration in GMPLS networks (i.e. sub-IP) and attempts to achieve alignment with ITU-T Recommendations G.808.1 and G.841. It is important to use identical rather than similar terms for protection and restoration techniques across the IETF when we are referring to sub-IP layers. Actually, I find the terminology rather woolly. For example, in Section 1 The Working Path is the Primary Path prior to the Failover Event and the Backup Path after the Failover Event. Yet in Section 3.1.3 The Primary Path is the Path that traffic traverses prior to a Failover Event. And it is difficult to read a document where the terms are used well in advance of their definitions. It might help if Section 3 was split with sections 3.1 through 3.4 presented as terminology, and sections 3.5 onwards as Test Considerations. The definition of "Restoration" in section 3.3.5 is unlike anything I have seen before and is very much at odds with the way the term is used in sub-IP networks. --- Figure 4 There is a spurious arrow head on the left-hand end of the arrow marked "IP-Layer Forwarding" --- Section 3.1.1 a. R1 is the ingress node and forwards IP packets, which input into DUT/SUT, to R2 as sub-IP frames over link L12. b. Ri is a node which forwards data frames to R[i+1] over Link Li[i+1] for all i, 1<i<n, based on information in the sub-IP layer. I don't think you should assume anything about the encapsulation method or transport mechanisms in the sub-IP technology. What is a sub-IP frame in packet over WDM? In many technologies, node Ri does not forward sub-IP frames. It forwards a signal. --- Section 3.1.1 "A bidirectional path", which transmits traffic in both directions along the same nodes, consists of two unidirectional paths. Therefore, the two unidirectional paths belonging to "one bidirectional path" will be treated independently when benchmarking for "a bidirectional path". Doesn't that mean that there will be different observed performance in the IP layer according to whether bidirecitonal or unidirecitonal protection is enabled in the sub-IP layer? But you are saying that you will not distinguish the two cases and so you will report benchmarks incorrectly. --- Section 3.1.3 Definition: The preferred path for forwarding traffic between two or more nodes. This is (possibly) the only mention of p2mp sub-IP paths. Is this really in scope for your draft? --- Section 3.1.5 The Backup Path MUST be created prior to the Failover Event. This seems to rule out the use of restoration (in the stadard transport network sense of the word) in the sub-IP network. Why do you rule this out? In fact, section 3.1.7 seems to contradict this statement. --- Section 3.1.5 Is the list intended to be exhaustive? This seems to have forgotten 1:1 protection. --- Section 3.1.5 The backup path generally originates at the point of failure, and terminates at a node along a primary path. I don't find the term "point of failure" in the rest of the document, but it seems to me this is wrong. It the backup path starts at the point of failure (for example, a failed node), what use will it be? --- Section 3.1.8 3.1.8. Disjoint Paths Definition: A pair of paths that do not share a common link. Discussion: Two paths are disjoint if they do not share a common node other than the ingress and egress. While these two paragraphs are compatible it is not clear that the Discussion is simply observing that node-disjoint paths are necessarily link-disjoint. Usually, one talks about link-disjoint paths and node-disjoint paths. --- Section 3.1.9 You use the term "penultimate egress node" which may be a bit confusing. After all, there is only one egress node. --- Section 3.1.10 Definition: SRLG is a set of links which share a physical resource. This is a debatable definition! What is a physical resource? Does it include a power supply? What about separate ducts in the same bridge? Or transit of the same politically unstable country? The last line of the Discussion seems to be the really key bit. Discussion: SRLG is considered the set of links to be avoided when the primary and secondary paths are considered disjoint. The SRLG will fail as a group if the shared resource fails. --- Section 3.2 I am not really comfortable with the split of "link protection" and "local link protection", but it I see how it may be interesting for benchmarking. I don't understand why there isn't a concept of "local node protection" where the failure of node C on the path ABCDE is protected by a direct link BD. --- Section 3.2.3 Path Protection provides Node Protection and Link Protection for every node and link along the Primary Path. A Backup Path providing Path Protection MUST have the same ingress node as the Primary Path. I don't see why you rule out a backup path that is not fully link and node diverse --- Section 3.2.7 The State Control Interface MAY be used for Redundant Node Protection. The State Control Interface MUST be out-of-band. It is possible to have Redundant Node Protection in which there is no state control or state control is provided in-band. This is hard to parse. It appears to say that stat control must be provided out of band. And yet it also says it is possible for it to be in band. --- Section 3.5 The following Benchmarks MAY be assessed on a per-flow basis using at least 16 flows spread over the routing table (more flows is better). Isn't this SHOULD?
I suspect this is clear enough for its intended audience, but a more detailed description of the calculations in 3.6.1 and 3.6.3 would help novice readers. I couldn't quite sort out the equations. For example in 3.6.3 (TBM), are the following interpretations correct? (1) Time(Failover) = Timestamp on first unimpaired packet received at egress node after the backup path became the working (2) Time(Failover Event) = Timestamp on the last unimpaired packet received at egress node on the primary path before failure I was unable to construct similar statements for the TBLM in 3.6.1 at all. Nits: in section 3.1.1, there is a confusing mixture of notation, using parentheses and brackets interchangeably. The definition of path uses parentheses, as in "L(n-1)n", but the description of node in subitem b. uses brackets, as in "Li[i+1]". In 3.6.3 under discussion, the comma following "observation of unimpaired packets" should be a period.
It looks to me that 'Benchmarking Terminology for Performance of sub-IP layer Protection Mechanisms' would be a more apropriate name for this document.
1. The document does not pass ID-nits. http://tools.ietf.org/tools/idnits/ 2. This is a very interesting normative reference:  Not used. Please delete that non-reference and renumber accordingly. 3. It appears that references  and  (RFC 4090 and RFC 2474) are not in fact normative.
This is a good draft and I will ballot Yes on it. However, there were a few issues that I would like to see corrected first: 1. IANA considerations section should describe what the policy is for allocating new bits from the flag field, and request IANA to create a name space for the bits. 2. The draft is using unclear/wrong terminology with regards to "host". For instance: Section: 3.1: When a host sending a HIP packet needs to record the hosts that are on the path that the HIP packet traverses, it includes an empty ROUTE_VIA parameter to the packet. Section 3.2: A host that needs to define the other hosts that should be on the path a HIP packet traverses adds a ROUTE_DST parameter to the HIP packet. Section 4: Both parameters have critical type (as defined in Section 5.2.1 of [RFC5201]) since the packet will not be properly routed unless all hosts on path recognize the parameters. The traditional meaning of a host is an end system, whereas here the node acts as a router. I would suggest that perhaps the term "node" would be more appropriate. RFC 5204 used both "node" and "server" in its descriptions. 3. Also, the draft is imprecise in its description of behaviors associated with packet reception: Section 3.1: A host that receives a packet with a ROUTE_VIA parameter SHOULD add its own HIT to the end of the ROUTE_VIA parameter, unless it is the receiver of the packet. Section 3.3: When a host receives a HIP packet that contains a ROUTE_DST parameter, it first looks up its own HIT from the route list. If host's own HIT is not in the list and the host is not the receiver of the packet, the packet was incorrectly forwarded and MUST be dropped. I am particularly reacting to the "... host receives ... if the host is not the receiver" language here. I think it would be better to say "... node receives a HIP packet ... the receiver's host identity tag is not one of the node's own HITs ..." or something along those lines. 4 .Section 1 should indicate that the draft deals only with the routing of the HIP signalling packets, not actual data packets. 5. Finally, the security considerations should cover more issues with source routing than just loops. See, e.g., http://tools.ietf.org/html/draft-savola-ipv6-rh-ha-security for some generic packet filtering and other issues around source routing. Also, the current draft seems susceptible to a similar issue that led to the deprecation of IPv6 routing headers. See RFC 5095 for the history. Assuming an otherwise 100-byte HIP packet, a host could add a 1400-byte ROUTE_DST parameter with 88 intermediate destinations. By sending out this one 1500 byte packet, it would be routed in the network 88 times. The draft does require that the same HIT not appear twice in the list, and this is an improvement over the IPv6 routing header situation. However, if a sufficient number of willing router nodes can be found in the Internet, significant amplification factors can still be reached. It would make sense to document this issue and perhaps even restrict the maximum number of destinations in ROUTE_DST.
Fine work, but just some small points about source routing I couldn't work out. Is it OK for additional HIP hosts to be inserted in the sequence specified? That is, is the sequence a loose sequence that can be expanded? Does the destination HIP host have to be present in the sequence, or can the sequence "end early"? Do you need to worry about the possibility of the recorded list of hosts becoming too large? When symmetry is applied, do you need to use the source route as supplied, or the actual route as recorded? If the answer to the first question is "no" and the second question "yes", can additional HIP hosts be inserted between the last host in the sequence provided, and the destination host? Is this an ordered list (sequence) or just a list? The bit flags seem to imply that the sequence can be broken - is this by leaving out hosts, or by rearrangement?
Please consider the the editorial comments raised by Gen-ART Review by Ben Campbell on 2010-06-11: -- General: IDNITS turns up some outdated references and boilerplate questions. Please check. -- Section 1, para 2, "HIP BONE": Please expand on first mention. -- Section 1, last paragraph: I'm not sure we can assume the reader knows what you mean by "customary sections." -- Section 3.2.2, para 3, last sentence, "Given that each operation requires the attacker to generate a new key pair, the attack is completely impractical": It would be better to avoid hyperbole when describing the practicality of an attack. Perhaps something to the effect of "impractical with current technology and techniques"? -- Section 3.4, para 2, last sentence, "with such straightforward approach": Missing article. -- Section 5.1, para 2, "The enrollment server of an overlay that were to use HITs derived from public keys as Node IDs could just authorize users to use the public keys and HITs associated to their nodes.": I have trouble parsing the first part of the sentence, around "that were to use". -- Section 5.3, para 1, "Nodes in an overlay need to establish connection with other nodes": Connections (singular/plural mismatch) -- Section 5.5, para before last bullet list, "It is assumed that areas not covered by a particular HIP BONE instance specification are specified by the peer protocol or elsewhere.": This seems more a requirement than an assumption. -- Section 6.1,"[ TBD by IANA; 980 ]": Does this mean IANA has already picked the number? Or is it a recommended number? (Pattern repeats for other registrations.)
Please ensure that the changes prompted by Catherine Meadows secdir are incorporated!
1. I think that this document (and the other hip documents) need to included a short explanation of the reasons for which the WG was chartered to issue Experimental RFCs, what kind of experimentation should be planned for the protocol extension, what are the expected results, and whether there are deployment concerns or limitations that need to be taken into consideration by operators. If this information can be found in some other hip document a reference would be fine. 2. The document says nothing about how hosts are being configured to support this extension and how are the lists parameters configured.
Consider adding a pointer to the discussion of fragmentation in the primary HIP draft.
I'm fine with this draft as an Experimental RFC, however, there were a couple of points where the draft was not clear enough to the reader: 1. My understanding is that with this mechanism, it will be possible to provide data origin authentication (via the signature) and integrity protection (via the MIC and the signature). But not confidentiality. This seems like a difference to the base HIP functionality that should be highlighted, along with DoS protection. 2. The draft does not explain when the HOST_ID parameter can be omitted (it is listed as optional in Section 4). How would the verification of the signature happen without the sender's HOST_ID? Presumably you can omit it if there's reason to assume the receiver already has it, but the specification does not tell us how we can determine that, or what the recourse is if that assumption fails. 3. I did not understand how to use PAYLOAD_MIC. Quoting the draft: The PAYLOAD_MIC contains the checksum of the payload following after the HIP DATA. ... The payload that is protected by the PAYLOAD_MIC parameter has been linked to the appropriate upper-layer protocol by storing the upper-layer protocol number, 8 bytes of payload data, and by calculating a hash sum (MIC) over the data. ... Next Header Identifies the data that protected by this MIC. The values for are defined by IANA "Assigned Numbers". Payload Data 8 last bytes of the payload data over which the MIC is calculated. This field is used to uniquely bind PAYLOAD_MIC parameter to next header, in case there are multiple copies of same type. Payload MIC MIC computed over the data to which the Next Header and Payload Data points to. ... If there is multiple next header types which the host wants to protect it SHOULD create separate PAYLOAD_MIC parameter for each of these. I guess you are assuming that the last 8 bytes of payload data are unique, right? If so, say so and indicate that as a limitation of what traffic can be carried. Not that I can think of any case where that would practically not be the case, but theoretically... Otherwise I may be missing what you intend to do here.
Section 4., paragraph 0: > 4. The hosts sends the created HIP DATA packet and starts a DATA > timer. The default value for the timer is 2 * RTT estimate. DISCUSS: Most often, the sending host will not have an RTT estimate for the recipient. Even when there is an RTT estimate taken during some previous packet exchanges, the question is whether that is still accurate enough after some time. Suggest to do instead what TCP does for SYN retransmissions and make this timer 3 seconds. Section 5., paragraph 0: > 5. If the DATA timer expires, the HIP DATA packet is resent. The > HIP DATA packet can be resent DATA_RETRY_MAX times. The DATA > timer SHOULD be exponentially backed off for subsequent > retransmissions. DISCUSS: The exponential backoff needs to be a MUST and not just a SHOULD.
The Introduction says... The HIP_DATA packet is not aimed to be a replacement for ESP transport instead it SHOULD only be used to exchange few packets between the peers. I find this woolly on three counts. 1. "not aimed" Is it or is it not? 2. "SHOULD only" Feels like you need to flip this to a "SHOULD NOT" For example: "SHOULD NOT be used to exchange more than..." 3. "exchange [a] few packets" Your opinion of "a few" may differ from mine. What is the real 2119 constraint here? --- Would be helpful to explain what a MAC is in section 2. --- Is it the intention that new HIP implementations should include support for the DATA packet? If so, doesn't this I-D update 5201? --- Section 4 appears to use some form of syntax to define the DATA packet. You should probably include a reference to the definition of that syntax.
The Gen-ART Review by Elwyn Davies on 15 June 2010 offers many minor comments and editorial nits. Please consider them.
The following issues are probably trivial, but I think they still need to be fixed before I can recommend approval of this document. 5.1. Handling of SEQ_DATA and ACK_DATA A HIP DATA packet contains zero or one ACK_DATA parameters. The ACK parameter echoes the SEQ_DATA sequence number of the HIP DATA packet packet being ACKed. One ACK_DATA parameter MUST contain one more sequence numbers of the HIP DATA packets being ACKed. "one or more"? The definition of ACK_DATA Parameter in Section 4.2 doesn't seem to allow for multiple acknowledged sequence numbers. At least the format doesn't show multiple values. 5.2. Generation of a HIP DATA packet 5. If the DATA timer expires, the HIP DATA packet is resent. The HIP DATA packet can be resent DATA_RETRY_MAX times. The DATA timer SHOULD be exponentially backed off for subsequent retransmissions. If no acknowledgment is received from the peer after DATA_RETRY_MAX times, the delivery of the HIP DATA packet is considered unsuccessful and the application is notified about the error. The DATA timer is canceled upon receiving an ACK from the peer that acknowledges receipt of the HIP DATA packet. Where DATA_RETRY_MAX defined? 8. IANA considerations This document updates the IANA Registry for HIP Packet types by introducing new packet type for the new HIP_DATA (Section 4) packet. This document updates the IANA Registry for HIP Parameter Types by introducing new parameter values for the SEQ_DATA (Section 4.1), ACK_DATA (Section 4.2), and PAYLOAD_MIC (Section 4.3) parameters. This doesn't mention TRANSACTION_ID defined in Section 4.4.
Agreeing with Peter's DISCUSS (at least agreeing that we should have a discussion). In Section 5.3.1: suggestion to reorder paragraphs to make processing order more logical. I.e. SIGNATURE processing first, then PAYLOAD_MIC processing, then SEQ_DATA processing. Similar comment regarding 5.3.2.
The authors need to respond to David McGrew's secdir review.
I support Peter's discuss position.
The content of the DISCUSS is based in part on the OPS-DIR review performed by Bernard Aboba. 1. I think that this document (and the other hip documents) need to included a short explanation of the reasons for which the WG was chartered to issue Experimental RFCs, what kind of experimentation should be planned for the protocol extension, what are the expected results, and whether there are deployment concerns or limitations that need to be taken into consideration by operators. If this information can be found in some other hip document a reference would be fine. 2. Section 6 makes the following recommendations related to the usage of the HIP DATA packet: > Therefore, applications SHOULD NOT use HIP DATA packets in environments where DoS attacks are believed to be an issue. For example, a HIP-based overlay may have policies in place to control which nodes can join the overlay. Any particular node in the overlay may want to accept HIP DATA packets from other nodes in the overlay given that those other were authorized to join the overlay. However, the same node may not want to accept HIP DATA packets from random nodes that are not part of the overlay. > The type of data to be sent is also relevant to whether the use of a HIP DATA packet is appropriate. HIP itself does not support fragmentation but relies on underlying IP-layer fragmentation. This may lead to reliability problems in the case where a message cannot be easily split over multiple HIP messages. Therefore, applications in environments where fragmentation could be an issue SHOULD NOT generate too large HIP DATA packets that may lead to fragmentation. The implementation SHOULD check the MTU of the link before sending the packet and if the packet size is larger than MTU it SHOULD signal to the upper-layer protocol if the packet results in to a ICMP error message. Note that there are environments where fragmentation is not an issue. For example, in some HIP-based overlays, nodes can exchange HIP DATA packets on top of TCP connections that provide transport-level fragmentation and, thus, avoid IP-level fragmentation. However, experience hows that the kind of use restrictions referred to above are difficult to maintain in practice, because it is difficult to determine the situations in which a DoS attack will not be an issue. For example, even though HIP DATA might be designed to be used in a closed network not connected to the Internet, something unexpected could happen (e.g. one or more hosts become infected, the "closed" network gets connected unexpectedly, etc.). Also with respect to MTU/fragmentation issues, a request might not cause fragmentation, but a response might. The classic case is a DNS response carrying DNSSEC information. In such a situation, it seems that the HIP DATA packet could cause failures that would be difficult to diagnose. 3. There is a possible concern for backwards compatibility which is not sufficiently explored. Implementations which rely on the HIP DATA packet for essential functionality will not interoperate with existing implementations which rely on the HIP base exchange. To prevent this, it's necessary for the document to state that an implementation must use the HIP base exchange in situations where the other peer doesn't support HIP DATA. I am not sure however how this situation is detected in advance. 4. The document doesn't describe how an implementation would determine what traffic will be sent using HIP DATA packets. For example, one might expect a filter model to be used, similar to that in use for IPsec.
Despite various warnings in the spec and the fact that it is Experimental, this seems to be a bad idea. Why are we encouraging implementers to bypass normal HIP authentication handshakes to convey arbitrary protocol messages? Isn't that similar to, say, SIP INFO (which we're madly working to stamp out)? Five years from now, will we be writing a spec entitled "HIP DATA Packets Considered Harmful"? The shepherd writeup says of the WG that "there was strong consensus on this document", but did the WG also consider whether this extension would be harmful to the Internet?
I'm trying to get HIP. #1) draft-ietf-hip-bone says "Before two HIP hosts exchange upper-layer traffic, they perform a four-way handshake that is referred to as the HIP base exchange" and now this I-D says that the DATA packet can be used to convey (in a secure and reliable way) protocol messages to a remote host without running the HIP base exchange between them. So am I to infer that the contents of the DATA packet is not upper-layer traffic? Nope at the end of Section 4 it says "Upper- layer protocol messages, such as overlay network control traffic, sent in HIP DATA messages ..." Is one of the documents wrong or is some rewording needed? #2) In Section 6: Where is the mechanism defined that allows these policies to enforce authorization to join the overlay? If it's out-of-scope or not defined please add that.
I support Peter's DISCUSS. I also support Jari's first DISCUSS position.
50% of the text are a "Background on HIP" (Section 3), which seems a bit excessive.
The document doesn't describe byte order used for the OVERLAY_TTL parameter. Section 6.1 and 6.2 list possible parameter numbers to be used by IANA, these should have been left out to avoid conflicting allocations. 6.2. Overlay TTL The type of the OVERLAY_TTL parameter is critical (as defined in Section 5.2.1 of [RFC5201]) and therefore the final recipient of the packet, and all HIP hosts on the path, MUST support it. If the parameter is used in a scenario where the final recipient does not support the parameter, the parameter SHOULD be removed before forwarding the packet to the final recipient. The last quoted sentence seem to contradict the previous one. But even if it doesn't, how can the sender or an intermediate node learn about the recipient not supporting the OVERLAY_TTL parameter?
This is a very well written document and it helped me a lot to understand how HIP works and how overlay networks will be built and deployed based on it. As with the other hip documents I think it needs to include a short explanation of the reasons for which the WG was chartered to issue Experimental RFCs, what kind of experimentation should be planned for the deployment of the framwork described in this document, what are the expected results, and whether there are deployment concerns or limitations that need to be taken into consideration by operators. If this information can be found in some other hip document a reference would be fine, or maybe this is the place to incude such information and be refered by other documents.
In section 3.1.2 it says: Before two HIP hosts exchange upper-layer traffic, they perform a four-way handshake that is referred to as the HIP base exchange. draft-ietf-hip-hiccups says it's required in Section 6. But then in 5.4 of this document and draft-ietf-hip-hiccups it says that this isn't true. In fact, Upper-layer traffic can be exchanged without the base exchange. Seems like 3.1.2 needs to be rephrased or the model needs to be expanded.
Please consider the SECDIR review comments for your next revision.
I should have liked to see an update to the Implementation Report. I am sure something has moved on, but maybe not.
This is a well-written memo that documents actual deployment history. I would be glad to clear this DISCUSS of the authors would add a sentence or two stating that the codepoint used in this document has been deprecated and may, at some point in the future, be reassigned by IANA. Depending on the context in which it is assigned, codepoint collisions may have adverse consequences.