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
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
2.2 Individual Submissions
2.2.1 New Items
Telechat:
Telechat:
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 Independent Submissions Via RFC Editor
3.3.1 New Items
Telechat:
Telechat:
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
Telechat:
Telechat:
Telechat:
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
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
Other
1335 EDT Adjourned
(at 2010-06-17 08:30:00 PDT)
draft-ietf-enum-3761bis
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:
"4.4.2.0.7.9.4.6.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.
draft-ietf-enum-enumservices-guide
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)
4.2.2.1. 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)
4.2.3.1. 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].
4.2.4.1. 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.
draft-ietf-enum-enumservices-transition
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., [15] and [7]) 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 [4]
iMIP [6]
CalDAV [7]
RFC4694 [10]
'http:' [11]
[12] and [13]
Short Message Service (SMS) [14]
EMS content is sent over SMTP using the format
specified by TS 23.140 [15] Section 8.4.4 and TS
26.140 [16] Section 4, as an MMS message.
The header fields used in such MMSE are
described in detail in [17].
#1) draft-ietf-enum-3761bis-08.txt also obsoletes RFC 3761.
draft-ietf-netconf-monitoring
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 [1], [2], ..." )
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.
draft-ietf-mboned-ipv4-uni-based-mcast
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.
draft-ietf-dnsext-dns-tcp-requirements
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 6.1.3.2 of RFC 1123. > A statement that this is relaxing Section 6.1.3.2 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
draft-ietf-ipsecme-eap-mutual
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? ;-)
draft-ietf-mpls-tp-data-plane
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
draft-freed-sieve-notary
The following spurious text appears in the IAN section:
To: iana@iana.org
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.
draft-kucherawy-authres-header-b
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.
rfc4049
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.
draft-ietf-bmwg-protection-term
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:
[6] Not used.
Please delete that non-reference and renumber accordingly.
3. It appears that references [8] and [9] (RFC 4090 and RFC 2474) are not in
fact normative.
draft-ietf-hip-via
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.
draft-ietf-hip-hiccups
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.
draft-ietf-hip-bone
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.
rfc5652
I should have liked to see an update to the Implementation Report. I am sure something has moved on, but maybe not.
draft-rosen-vpn-mcast
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.
draft-resman-idna2008-mappings