IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2011-05-26. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Pete, David
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
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:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
Telechat:
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
3.3.2 Returning Items
no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
Telechat:
4.1.2 Proposed for Approval
Telechat:
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat:
Telechat:
4.2.2 Proposed for Approval
Telechat:
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1417 EDT Adjourned
(at 2011-05-26 07:30:04 PDT)
draft-ietf-xcon-common-data-model
This was an overall OK document. I did have a few small question marks, however:
I am wondering if <language> can contain multiple languages or appear multiple
times. The text says nothing exact but seems to indicate just one language. Some
of the schema definitions seems to say that multiple languages can appear.
Please clarify and align.
Then I had a question on this:
In order to facilitate the comparison of the XCON-USERID identifiers,
all the components of the identifiers MUST be converted to lowercase.
After normalizing the URI strings, the URIs comparison MUST applied a
character-by-character basis as prescribed by RFC3986, Section 6.2.1.
Question: is this sufficient to deal with internationalized user identifiers?
I'm about as far as one can be from an i18n expert, but I thought there were
situations were you'd have to map characters to other characters in order
to do proper comparisons. Maybe that's not needed for user identifiers.
Please check.
Can notifications come after the end of the conference, too?
The data type is integer, not NonNegativeInteger:
<xs:element name="notify-end-of-conference"
type="xs:integer" minOccurs="0"/>
Please clarify and ensure you meant all integers.
Are mixing start offsets really absolute time values? By their name, I was
expecting an offset not an absolute value. Either approach is fine with me, of
course, but perhaps the document needs to say explicitly that the offsets are
actually absolute values and not differences to the start/end time.
element xcon:mixing-start-offset {
time-type,
attribute required-participant { single-role-type },
anyAttribute
}?,
On the basis of trusting that others who have greater knowledge of this subject matter have reviewed this document I am voting no-objection.
There are enough detailed Discuss points from other people that I can't find much to add. Please note that you should not include references from the Abstract which is supposed to be stand-alone text. I was a little surprised that there isn't an Informative reference to draft- ietf-xcon-ccmp. Is http://www.relaxng.org/ the right reference to give for Relax NG given that it is published as an international standard by ISO?
(1) I agree with the secdir reviewer (Tero Kivinen) [1] that passwords
and personally identifying information do warrant specific protection
in the DB. The security considerations seems to nearly, but not quite
do this, when it says that the DB SHOULD be accessed via TLS or
equivalent. However, I think you need two more things: a) to say when
its ok to not follow the SHOULD but also b) you need to RECOMMEND that
the (sensitive parts of the) DB be encrypted as stored in long term
storage (i.e. disk) which is different from how its accessed via the
network.
[1] http://www.ietf.org/mail-archive/web/secdir/current/msg02482.html
(2) I would think that conference object identifier URIs (and maybe
also other URIs that are not typed by people) MUST or SHOULD be
unguessable. The reason is that this provides a defence-in-depth for
cases where e.g. TLS is not used when it ought be etc. Basically, if
a URI is unlikely to be typed by a person, then it seems best to make
sure they're unguessable and since this is something that
implementations often get wrong this would seem like a good place for
that statement.
(5) 4.2.12 What does "set by an administrator" mean for a data model?
How could I tell by looking? If it said "typically set..." that'd be
fine but it currently reads like normative text.
(7) Section 6 says "The IETF MAY extend the data model schema..." What
does that mean? Why the 2119 MAY? Is a standards-track document
needed, or informational, what about ISE/IRTF or other streams?
(8) Security considerations: what does "There is no other encoding
considerations for XCON-USERID or XCON-URI not discussed in RFC 3986
[RFC3986]." mean? I don't get it anyway.
(1) Typo: "the URIs comparison MUST applied a character-by-character basis" (2) In 3.2.2 if you don't want IP addresses to be used, then why not just say so? Maybe add text that says that xcon:foo@10.0.0.1 is not the same as xcon:foo@167772161 (but for one of the proper example IP addresses) if that's what is meant. (3) I think this (on p25) could do with rephrasing: "A 'closedAuthenticated' policy MUST have each conference participant in the allowed users list (listed under the <allowed-users-list> element) with each participant being sufficiently (up to local policy) authenticated." (4) In 4.6.5, maybe s/authenticated user identities/authenticated user identifiers/ - a pet peeve of mine, but probably more correct as identifiers. (5) 4.6.5.3 seems a bit overstated - given that the highest level of protection still has non-anonymous identifiers for the user in the common model, calling if anonymous seems wrong and liable to give the wrong impression. I'd suggest changing the name of this to "<hide-name>". (This is not a discuss because I guess it could be that code depending on this name is out there already and its a small point.) If changing the name's not doable, then maybe add a sentence that implementations SHOULD make it clear to users that real anonymity is not being provided.
After getting most of the way though draft-ietf-xcon-ccmp and draft-ietf-xcon-
examples-08, I have decided to move this to DISCUSS. These three documents
repeat things from documents to which they normatively refer. Aside from
increasing the overall length of what are already very long documents, I think
this actually introduces a danger that the documents will "get out of sync": If
the normative text happens to differ between the documents, it's unclear which
is authoritative. If there's disagreement in even non-normative text, it
introduces the potential for confusion. I really think the redundant text needs
to be eliminated and the documents shortened.
In this document: RFCs 3986, 4575, and 5239 are all normative references and are
absolutely required reading to use this document. Therefore I don't see any
reason for all of the redundancies in this document, and note the potential for
problems above. So:
Intro - Paragraphs 2, 3, 4 and figure are redundant and unneeded. Strike.
(Indeed, figure 1 is subtly different from the ones in 5239. Maybe not in any
important way, but why introduce the potential for confusion.)
4.1 - Shorten:
A conference object document begins with the root element
<conference-info>, which is defined in [RFC4575]. The
attributes 'state' and 'version' defined in [RFC4575] are
not used for this element in this specification because these
attributes only apply to notification mechanisms.
This specification adds the child element <floor-information>
to the <conference-info> element.
4.2 - Shorten:
The <conference-description> element, which is defined in [RFC4575],
describes the conference as a whole. This specification adds the
child elements <language>, <allow-sidebars>, <cloning-parent>, <sidebar-
parent>, and <conference-time>. This specification also adds a new
<conference-password> child element to the <entry> child element of the
<conf-uris> child element, and adds the <mixing-mode>, <codecs>, and
<controls> child elements to the <entry> child element of the
<available-media> child element.
Strike 4.2.2, 4.2.3, 4.2.4, 4.2.5
4.2.10 - Just define <conference-password> here.
Strike 4.2.11, 4.2.12
4.2.13 - Just define <mixing-mode>, <codecs>, and <controls> here.
Strike 4.3, 4.4.2, 4.4.3, 4.4.4, 4.6.5.1, 4.6.5.2, 4.6.5.5, 4.6.5.6
ABNF issue: In 3.3.1, conf-object-id is very liberal. Is everyone OK with the idea of a conf-object-id of "---...+++===///"? (I understand that 3986 also allows "---...", but I'm just checking. [Update 2011-05-24: The author claims this is desirable. I am willing to take his word for it, but leave this comment in just in case.] Editorial: Top of section 4 - The use of the word "operator" twice here is goofy. This is notation, not a formal operation. I say just strike it. [Update 2011-05-24: To be fixed.] Also, why is the figure specified as "non-normative". What could be taken as normative in there? [Update 2011-05-25: To be fixed.] 4.2.1 - "defined in IANA [IANA-Lan]". That looks funny. [Update 2011-05-24: To be fixed.] 4.2 - Why is "lang" on the <conference-description> rather than on its children? And why does it need to be called out normatively in this document? (Shouldn't all elements have a lang aatribute? Why is this one special?)
First, my apologies for not reviewing this document earlier in the
process, as requested by the RAI ADs.
1. RFC 4575 says that a conference object MUST be encoded using UTF-8,
yet this document says it SHOULD be encoded using UTF-8. Why the change?
How would a UTF-16-encoded conference object be handled? I strongly
suggest changing the SHOULD to MUST.
2. Section 3.3 states:
When created within the
conferencing system, the 'conference ID' has a 1:1 mapping to the
unique conference object Identifier(XCON-URI).
However, Section 3.3.1 defines XCON-URI as:
XCON-URI = "xcon" ":" [conf-object-id "@"] host
Is there a 1:1 mapping between the "conference ID" and the full
XCON-URI, or between the "conference ID" and the conf-object-id rule?
3. Section 3.3.1 says that "the XCON-URI can not be resolved to
addresses and/or ports". Does this mean that an application MUST NOT
attempt to resolve an XCON-URI, or only that such URIs are not designed
to be resolvable?
4. Regarding Section 3.3.2, why not just reference Section 6 of RFC
3986?
5. Please add a note that the XCON-URI construction does not directly
support characters outside the ASCII range, but that such characters can
be encoded (at least in the "host" portion) using the rules in RFC 3987.
6. Section 4.1 states:
Note that the
<conference-info> element does not have the attributes 'state' and
'version' defined in [RFC4575] for this element because these
attributes only apply to notification mechanisms.
What does it mean to say that the element "does not have" the attributes?
Does it mean that for this usage, the attribute MUST NOT be included? If
so then it appears that this document might be updating RFC 4575.
(Similar text appears in Section 4.6, Section 4.6.5, etc.)
7. Section 4.2 states:
The <conference-description> element, which is defined in [RFC4575],
describes the conference as a whole. It SHOULD have an attribute
'lang' to specify the language used in the contents of this element.
However, the 'lang' attribute is not specified in RFC 4575 schema. The
RelaxNG definition in this document includes not 'lang' but 'xml:lang':
conference-description-type =
element conference-description {
attribute xml:lang { xsd:language }?
If you mean 'xml:lang' instead of 'lang' then please say so.
8. A number of elements have boolean values, such as Section 4.2.6:
The <allow-sidebars> element represents a boolean value. If set to
TRUE, the conference is allowed to create sidebar conferences. If
absent, or set to FALSE, the conference can not create sidebar
conferences.
Please note that in W3C XML Schema Part 2 (Datatypes), there are two
lexical representations for boolean values: "true"/"1" for the concept
TRUE and "false"/"0" for the concept FALSE. You might want to add a
general note about this somewhere in the text (or in each section say
'"true" or "1"' instead of 'TRUE', '"false" or "0"' instead of 'FALSE').
9. Given that the conference object is entirely defined in XML, why
does the <base> child of the <conference-time> element contain the
textual representation of an iCalendar object (RFC 5545) instead of
the XML representation (draft-daboo-et-al-icalendar-in-xml, on the
same telechat as this document)?
10. Section 4.2.9 states the following about the <mixing-start-offset>
element (same for <mixing-end-offset>):
The <mixing-start-offset> has the mandatory
'required-participant' attribute. This attribute contains one of
the following values: "none", "administrator", "moderator",
"user", "observer", and "participant". The roles' semantic
definitions are out of the scope of this document and is subject
to future policy documents. More values can be specified in the
future.
Not defining the attribute values seems problematic. Yes, we all have
a common-sense idea of what administrators and moderators (etc.) are,
but why leave the definitions to future policy documents? And given
that more values can be specified in the future, is a registry in
order?
11. Section 4.6.3 states:
The <persistent-list> child element
stores persistent information about users who are not actively part
of an ongoing chatroom session. The <persistent-list> element stores
the following information:
o user: The <user> element stores the name, nickname, the conference
user identifier (XCON-USERID) and email address of a user. It has
three attributes: 'name', 'nickname' and 'id' and an <email>
element. Future extensions to this schema may define new elements
for the <user> element.
Why is it required to store email address? What are the privacy and
security implications of storing email addresses (e.g., possible
directory harvesting attacks)?
12. Section 6 states:
The Conference Information Data Model defined in this document is
meant to be extensible toward specific application domains. Such
extensions are accomplished by defining elements, child elements and
attributes that are specific to the desired application domain. The
IETF MAY extend the data model schema with unqualified attributes or
extension elements from the "urn:ietf:params:xml:ns:" "sub-namespace"
in the future. Other instances are free to define extension elements
or attributes under other namespaces.
I see no reason to talk about the "urn:ietf:params:xml:ns:" tree here,
although if you want to talk about it then the MAY seems out of place
and it would be good to provide a pointer to RFC 3553. I would suggest:
The Conference Information Data Model defined in this document is
meant to be extensible. Extensions are accomplished by defining
elements or attributes qualified by namespaces other than
"urn:ietf:params:xml:ns:conference-info" and
"urn:ietf:params:xml:ns:xcon-conference-info" for use wherever
the schema allows such extensions (i.e., where the RelaxNG
definition specifies "anyAttribute" or "anyElement").
1. Section 3.4 says:
Note that some of the elements described above such <conference-
info>, <conference-description>, <sidebars-by-ref>, or <sidebars-by-
val> are not defined in the data model in this specification but are
defined in the data format of [RFC4575]. We describe them here
because they are part of the basic structure of the data model.
In fact *only* <floor-information/> is defined in this specification.
It would be good to make that clear.
2. In Section 4.2.13:
* The <mute> element is used in conjunction with an audio stream
to cease transmission of any audio from the associated stream.
That means that for the entire duration where mute is
applicable, all current and future participants of the
conference are muted and will not receive any audio.
To be precise, muting applies to the sending of audio, not the receiving
of audio.
3. I haven't had time to complete detailed checking of the RelaxNG
schema (compact or XML syntax), the W3C XML Schema document, or the
examples. However, including the formal definition in three different
representations might introduce the possibility that they are out of
sync. The fact that only the compact syntax is normative helps.
Finally, I merely note that the formal definition in RFC 4575 uses
W3C XML Schema, whereas the formal definition in this document uses
RelaxNG; the disconnect might make it difficult for implementers to
compare and reuse the formal definition.
#1) Mandatory is used a couple of times in the document to indicate support
level for certain attributes (e.g., in Sec 4.2.9). I think these should be
changed to use 2119 language.
#2) Sec 4 include the following:
The operator "!" preceding an element indicates
that the element is mandatory in the data model.
Shouldn't mandatory be REQUIRED (i.e., use 2119 language).
#3) I'm trying to reconcile the following statement from Sec 4.2.9 and Figure 3:
Every <entry> element contains the following child elements:
I read that to mean the child elements MUST be present. Is that the case?
Same thing in 4.2.13:
Each <entry> element contains the following child elements:
#3) Sec 4.2, 4.3, 4.4, 4.6: Which of the sub-elements MUST be supported? E.g.,
is it allowable to have an empty <conference-state> or <users>? If so how's that
handled?
#4) Sec 4.5: Which of the four elements MUST be supported? Is <conference-ID> a
MUST? What happens when <floor-request-handling> isn't included - is there
default behavior like <allow-floor-events>?
#5) Sec 4.5.4 includes the following:
The <conference-floor-policy> element has one or more <floor> child
elements.
Doesn't this mean "floor" is a MUST? Then, Figure 3 needs to be updated and
this sentence should be reworded to clearly state it's a MUST support.
#6) Sec 4.6.5.10 needs to indicate that it MUST be included in every <user>.
#1) I support Stephen's discuss. #2) Should this document indicate that it updates RFC 4575? #3) Sec 1 includes the following: This core data set called the 'conference information data model' is defined in this document using an Extensible Markup Language (XML)- based. I think this sentence is missing some additional words. #4) Sec 4.5.4: r/is optional/is OPTIONAL r/The optional/The OPTIONAL
draft-ietf-vcarddav-vcardrev
Updated Discuss in view of the RFC Editor Note
A fine piece of work, but one small issue need resolution before
publication as an RFC.
---
draft-ietf-vcarddav-vcardxml sets two requirements for extensions to
this document:
It is expected that [...] vCard extensions will also specify
extensions to the XML format
New XML vCard property and parameter element names MUST be lower-
case.
I think you should include these two requirements in this document.
(1) I'm surprised that there is no security considerations text about the fact that you might run into trouble if you blindly follow URLs that are embedded in vCards. There's probably easily copied text somewhere on that. (2) Similar point about embedded images and audio - again security considerations about parsing/rendering these carefully would be good. (3) You can specify a key but no signature? That's a pity but I guess would be another spec entirely. Just wondering if anyone's developing that. (4) This allows a whole bunch of things to be included (e.g. PGP keys, URLs etc.) but there are no conformance requirements for what has to be supported. I guess that's in some other spec somewhere?
1) in xCard, New XML vCard property and parameter element names MUST be lower- case. This is necessary to ensure that round-tripping between XML and plain-text vCard works correctly. in vCard, Based on experience with vCard 3 interoperability, it is RECOMMENDED that property and parameter names be upper- case on output. are these consistent? 2) references need updating (see id-nits)
The discussion following the Gen-ART Review by Kathleen Moriarty on
8-Apr-2011 lead to the following proposed text:
o vCards often carry information that can be sensitive (e.g.
birthday, address, and phone information). Although vCards have no
inherent authentication or privacy provisions, they can easily be
carried by any security mechanism that transfers MIME objects to
address authentication or privacy (e.g. S/MIME [RFC5751], OpenPGP
[RFC4880]). In cases where the privacy or authenticity of
information contained in vCard is a concern, the vCard SHOULD be
transported using one of these secure mechanisms. The KEY
property (Section 6.8.1) can be used to transport the public key
used by these mechanisms.
I would prefer the use of "confidentiality" instead of "privacy".
That would better align with the definitions in RFC 2828.
3.3 -
NON-ASCII = %x80-FF
; Use is restricted by UTF-8
Why not use UTF8-char and reference RFC 3629?
4 -
TEXT-CHAR = "\\" / "\," / "\n"
/ <any VALUE-CHAR except , or \>
; Backslashes, commas, and newlines must be encoded.
Is it so bad to expand this out?
TEXT-CHAR = "\\" / "\," / "\n" / WSP / NON-ASCII
/ %x21-2B / %x2D-5B / %x5D-7E
; Backslashes, commas, and newlines must be encoded.
6.1.2/6.1.3 -
BEGIN-param = 0dummy ; no parameter allowed
END-param = 0dummy ; no parameter allowed
BEGIN-param = 0" " ; no parameter allowed
END-param = 0" " ; no parameter allowed
That looks neater to me.
6.5.1 - Is it worth an informative reference to
draft-lear-iana-timezone-database (approved BCP)?
I support the issues raised by Stephen Farrell in his COMMENT.
Is this document deprecating text/directory? It obsoletes the RFC that defined
it, but the only mention is in the media registration of text/vcard as "should
be considered deprecated in favor of text/vcard". Why isn't this stated more
clearly in the text (particularly the introduction) of the document?
It would help to point to Appendix A earlier in the document, perhaps with a very high-level overview of what's been updated. An implementer will use Appendix A as a checklist of items to check against code - is it complete? There are changes called out in B (which will be deleted before being published) that don't seem to be reflected in A. Were there any changes to what 4770 specified?
#1) Sorry to inflict an this on the authors, but I gotta ask: Do you want to
move the obsoleted RFCs to Historic?
#2) The last line in the abstract doesn't match up with the header. Is 2739
being updated or obsoleted?
#3) Sec 3.1: What should happen if another charset is included?
#1) Section 5.2 & 5.3: r/parameter is optional/parameter is OPTIONAL #2) Sometimes the document uses ASCII and other it uses US-ASCII. Was this intentional? #3) Sec 6.8.1: lots of people use .cer or .pem for X.509 certificates can we change the example to: KEY:http://www.example.com/keys/jdoe.cer?
draft-ietf-vcarddav-vcardxml
The Relax NG specification really does need a reference that would help identify the correct base specification. I think you could use an OASIS URL, but I would prefer the ISO number.
1) I did not validate Appendix A. Has this had independent validation by, say, the XML directorate?
The Security Considerations say:
All the security considerations applicable to plain vCard
[I-D.ietf-vcarddav-vcardrev] are applicable to this document
as well.
This is completely correct; however, the use of XML digital
signature and XML encryption are appropriate security mechanisms
in this situation, while these mechanisms are not appropriate for
a plain vCard. This seems worthy of mention.
5.1. Extensibility The original vCard format is extensible. New properties, parameters, data types and values (collectively known as vCard objects) can be registered with IANA. It is expected that these vCard extensions will also specify extensions to the XML format described in this document. I think that this paragraph refers to the procedure described in Section 10.2 of http://www.ietf.org/id/draft-ietf-vcarddav-vcardrev-21.txt for registering new vCard elements. I beleieve that an explicit reference would be useful. Also, why are the vCard extensions called 'objects' in this document and 'elements' in the other? Also just saying 'can be registered with IANA' is somehow mis-leading (especially in the absence of the reference) as this is no routine IANA registration, but a procedure that requires a standards-track RFC in some cases.
draft-ietf-xcon-ccmp
On the basis of trusting that others who have greater knowledge of this subject matter have reviewed this document I am voting no-objection.
What is the scope of the uniqueness for an XCON-USERID? Is XCON-USERID intended to be used across multiple conferences or is it specific to a conference?
A very weighty tome that I cannot pretend to have read in full detail.
I am relying on the WG and responsible ADs for assurance of quality,
but I noticed a few smaller issues that I believe need to be resolved
before publication.
---
Section 4
The specification recommends the use of HTTP as
a transport solution, including CCMP requests in HTTP POST messages
and CCMP responses in HTTP 200 OK replies. This implementation
approach is further described in Section 4.4.
Section 9
This section describes the use of HTTP [RFC2616] and HTTP Over TLS
[RFC2818] as transport mechanisms for the CCMP protocol, which a
conforming conference Server and Conferencing client MUST support.
Section 10
3. The protocol MUST support a confidentiality and integrity
mechanism. As described in Section 9, implementations of CCMP
MUST implement the HTTP transport over TLS [RFC2818].
So it looks like Section 4 is under-egging the situation and you need
s/recommends/requires/
It is probable that Seciton 4.4 needs to be tightened in this regard as
well.
---
I think the 2119 language needs to be tightened up. As a completely
random example:
Section 5.1
operation: An optional parameter refining the type of specialized
request message. The "operation" parameter is REQUIRED in all
requests except for the "blueprintsRequest" and "confsRequest"
specialized messages.
Why "optional" in lowercase but "REQUIRED" in uppercase?
I think the only sure way to sort this will be to grep all the lowercase
versions of the 2119 words and think about them carefully.
---
Section 5.1
conference-password: An optional parameter that MUST be inserted in
all requests whose target conference object is password-protected
(as per the <conference-password> element in
[I-D.ietf-xcon-common-data-model]).
This "MUST" implies that ommission would be treated as a malformed
message, not a password failure (i.e. 400 not 401). Does it matter?
But later I see you have defined 424 which is probably what you would
use. Add some clarity?
---
Shouldn't the sample phone number (uri="tel:+390817683823") be taken
from one of the set of "unreal" phone numbers?
---
Section 7
This document proposes the use of DNS to locate the conferencing
server.
What is the upshot of this proposal? Does a conformant implementation
get to choose? Is this language you can tighten as s/propose/specifies/
BTW, I appreciated the many examples, although they might have been moved to an appendix to clear the floor for the main meat of text (is that metaphor too horribly mixed?). I also wasn't convinced by including all of the schema fragments in-line as well as in Section 11, but this is probably a stlistic choice that is not important. --- Nit 5.4. All CCMP response messages MUST include a ""response-code"". The You probably don't need the quad-quotes.
(1) Not requiring HTTP or TLS client-authentication mechanism seems to me to be
a mistake. Its more likely that HTTP authentication will be maintained in
future (e.g. extended for oauth, saml, etc) than that CCMP will be. I would
suggest getting rid of the "not required" in section 9 on that.
(2) The response codes in 5.4 seem to be a subset of those from rfc 2616. I
think it'd be better to not replicate the descriptive text about those, nor the
codes themselves - how is the combination of HTTP response codes and CCMP
response codes supposed to work? E.g. if I get a HTTP 200 but a CCMP 404 in one
response then what? I could imagine coders getting this wrong, or having
difficulty doing the right thing with libraries.
(1) This could do with being rephrased. "Their identifiers, respectively the conference XCON-URI and the conferencing client XCON-USERID, and their XML representations compliant with the XML Schema defined in the XCON data model are widely used for creating the CCMP requests and responses." (2) The AUTO_GENERATE_X stuff on p12 seems complex - I don't think I really followed the description and I wondered if it'd be easy to write code for this. I'd suggest maybe looking at that text again to see if there's a way to make it clearer for an implementer who hasn't been involved in the WG. (3) In 4.4, if a client's timer expires and it closes the connection, then what, if anything, is the server supposed to do? E.g. if the request was ok and the server has done an update but not yet sent the 200 response for some reason. I think the server doesn't have to do anything (e.g. try to unwind the update), but that'd be good to say. (4) What is the limit of the xPathFilter mechanism? Could I use it to select all the users or conferences with the password foo? Maybe there's some security considerations text needed for that?
As with draft-ietf-xcon-common-data-model, section 3 of this document repeats
things from RFC 5239. I think this introduces a danger that the documents will
"get out of sync": If the normative text happens to differ between the
documents, it's unclear which is authoritative. If there's disagreement in even
non-normative text, it introduces the potential for confusion. Strike all of
section 3. Completely redundant with RFC 5239, which is a normative reference
anyway.
The intro to section 4 gives an implementation requirement without using 2119
language:
Each operation in the protocol model, as summarized in Section 4.1 is
atomic and either succeeds or fails as a whole. The conference
server must ensure that the operations are atomic in that the
operation invoked by a specific conference client completes prior to
another client's operation on the same conference object.
4.3 needs a reference to the data model document.
5.2 defines the "version" parameter as optional. However, there are clearly
instances (specified in 4.2) where it is required. 5.2 should probably indicate
that.
5.3.1 - "A blueprintsRequest message REQUIRES no "confObjID" and "operation"
parameters". Do you mean that they are OPTIONAL or that they MUST NOT be
present? "REQUIRES no" is not appropriate.
Intro to section 4: CCMP is a client-server, XML-based protocol, which has been specifically conceived to provide users with the necessary means for the creation, retrieval, modification and deletion of conference objects. CCMP is also state-less, which means implementations can safely handle transactions independently from each other. Conference-related information is encapsulated into CCMP messages in the form of XML documents or XML document fragments compliant with the XCON data model representation. That's a bit fluffy. How about instead: CCMP is a client-server, XML-based protocol for user creation, retrieval, modification and deletion of conference objects. CCMP is a stateless protocol, such that implementations can safely handle transactions independently from each other. CCMP messages are XML documents or XML document fragments compliant with the XCON data model representation. [REF?] See also use of the word "conceived" in the intro to 4 and in 5.3.1. Could tighten up the language there. 4.2 would be much easier to read if you stated the requirement (that responses with documents MUST have a version) first and then gave the explanation. Implementers don't need dramatic build-up. Get to the point. Then most of the explanation can be reduced. 4.4 first paragraph (or two; I can't tell if what spans the page break is 1 paragraph or two) can be reduced to: CCMP is implemented using HTTP, placing the CCMP request messages into the body of an HTTP POST operation and placing the CCMP responses into the body of the HTTP response messages. For information as to why this implementation method was chosen, refer to Appendix A. Then trim the second to last paragraph of 4.4 to get rid of redundancies. 5.3 Overall - I wouldn't mind seeing all of the XML *not* repeated here. It's already in section 11. 5.3 Intro - Move the discussion of optionsRequest/optionsResponse down to 5.3.12. No need to distinguish it here. 6 - I think this should either be in an appendix or in draft-ietf-xcon-examples.
The OPS-DIR review performed by Juergen Quittek raised a few issues and made a
number of suggestions. None of them are critical, but in case the document is
open to fix other issues I suggest to consider these ones as well:
1) Section 2: Terminology
> First-Party: A request issued by the client to manipulate their own
> conferencing data.
>
> Third-Party: A request issued by a client to manipulate the
> conference data of another client.
"First-Party" and "Third-Party" alone are not requests.
At least the term is not used this way in the draft.
Rather "third-party request" is used in the text for Referring to requests.
I would suggest:
NEW
First-Party request: A request issued by the client to
manipulate their own conferencing data.
Third-Party request: A request issued by a client to
manipulate the conference data of another client.
2) Section 3, third paragraph, 1st line:
OLD
Conference object and conference users do represent key elements
NEW
Conference object and conference user objects do represent key elements
Implementation and operation of the protocol would become drastically simpler if
the CCMP server would not be required anymore to create users. Just creating
user objects would probably be sufficient already
3) Section 3.2, 1st paragraph, lines 7-8
OLD
or a common administrator. The Conference Control Server creates
individual users, assigning them a unique Conference User Identifier
NEW
or a common administrator. The Conference Control Server creates
individual user objects, assigning them a unique Conference User
Identifier
4) Section 4.1, 2nd paragraph
OLD
create: for the creation of a conference, a conference user, a
sidebar, or a blueprint.
NEW
create: for the creation of a conference object, a conference
user object, a sidebar, or a blueprint.
5) Section 4.3, item (b), line 2:
OLD
in the request has (have) been replaced by the newly created
NEW
in the request have been replaced by the newly created
6) Section 5.3.4, paragraph after Figure 8, line 7:
What is "the referenced conference document"?
Is it the conference object?
7) Section 5.3.5, 1st paragraph, Last two lines:
Again "conference document", see issue 6)
8) Section 5.2.12, first bullet item, line two:
"ten standard message names"
It would be helpful to add a reference to Table 1.
9) Section 7, first lines:
> If a conference control client is not pre-
configured to use a
> specific conference control server for the requests,
the client MUST
> first discover the conference control server before it can
send any
> requests.
Is this really a capital "MUST"? Would the client be
able to send any request before discovering the server?
1. Section 4.2 appears to assume that HTTP is the transport; for
example:
If the
modifications are all successfully applied, the server sends back to
the client a "200" response which also carries information about the
current server-side version of the modified object.
If that is so, please either change SHOULD to MUST (i.e., make HTTP
mandatory-to-implement as a baseline data transfer protocol) or at
least add a note to the effect that HTTP is a SHOULD but all the
examples use HTTP.
This would also be consistent with Section 9, which states:
This section describes the use of HTTP [RFC2616] and HTTP Over TLS
[RFC2818] as transport mechanisms for the CCMP protocol, which a
conforming conference Server and Conferencing client MUST support.
2. In Section 4.3:
The XCON data model identifies some elements/attributes as mandatory.
Since the XML documents carried in the CCMP need to be compliant with
the XCON data model, there can be a problem in cases of client-
initiated operations, like the creation/update of conference objects.
In such cases, not all of the mandatory data can be known in advance
to the client issuing a CCMP request. As an example, a client has no
means to know, at the time it issues a conference creation request,
the XCON-URI that the server will assign to the yet-to-be-created
conference and hence it is not able to appropriately fill with that
value the mandatory "entity" attribute of the conference document
contained in the request. To solve this issue, the CCMP client fills
all mandatory data model fields, for which no value is available at
the time the request is constructed, with fake values in the form of
a wildcard string, AUTO_GENERATE_X (all uppercase), with X being a
unique numeric index for each data model field for which the value is
unknown.
Instead of sending fake values, how about fixing the data model so that
these elements and attributes are not mandatory?
3. The CCMP namespace is "urn:ietf:params:xml:ns:xcon:ccmp". Why is it
not "urn:ietf:params:xml:ns:xcon-ccmp"? On the meaning of ":" here
please see Section 3 of RFC 3553...
Declaration of structure:
The namespace is primarily opaque. The IANA, as operator of the
registry, may take suggestions for names to assign but they
reserve the right to assign whatever name they desire, within
guidelines set by the IESG. The colon character (":") is used to
denote a very limited concept of hierarchy. If a colon is present
then the items on both sides of it are valid names. In general,
if a name has a colon then the item on the left hand side
represents a class of those items that would contain other items
of that class. For example, a name can be assigned to the entire
list of DNS resource record type codes as well as for each
individual code. The URN for the list might look like this:
urn:ietf:params:dns:rr-type-codes
while the URN for the SOA records type code might look like this:
urn:ietf:params:dns:rr-type-codes:soa
It appears that "urn:ietf:params:xml:ns:xcon" is not a valid name. Thus
"urn:ietf:params:xml:ns:xcon-ccmp" seems better. Notice also that the
XCON conference info URN is "urn:ietf:params:xml:ns:xcon-conference-info"
not "urn:ietf:params:xml:ns:xcon:conference-info".
4. Section 9 states:
a conferencing server may not be a fully compliant HTTP server
Do you mean "might" or "MAY"? I.e., is it OPTIONAL for a conferencing
server to fully comply with HTTP?
1. Section 4 states: The conference server must ensure that the operations are atomic in that the operation invoked by a specific conference client completes prior to another client's operation on the same conference object. Change "must" to "MUST"? 2. Also in Section 4: The specification recommends the use of HTTP as a transport solution... Change to the following? Implementations SHOULD use HTTP as the transport... 3. In Section 4.2: The "version" parameter is not REQUIRED for requests... There is no "not REQUIRED" in RFC 2119. I suggest: The "version" parameter is OPTIONAL for requests... 4. In Section 5, the terms "mandatory" and "optional" are used for the various parameters. Using RFC 2119 language, are these really "REQUIRED" and "OPTIONAL"? 5. The table in Section 5.4 has bad line breaks. I suggest changing this: +---------------+------------+------------+------------+------------+ | Response code | Create | Retrieve | Update | Delete | +---------------+------------+------------+------------+------------+ to this: +----------+-------------+-------------+-------------+-------------+ | Response | Create | Retrieve | Update | Delete | | Code | | | | | +----------+-------------+-------------+-------------+-------------+ or even to this: +------+--------------+--------------+--------------+--------------+ | Code | Create | Retrieve | Update | Delete | +------+--------------+--------------+--------------+--------------+ That will give you more room in each column. 6. Various examples have "form the server" instead of "from the server". 7. In schema snippet from Section 6.9, the example extension does not specify an XML namespace, implying that the extension is qualified by the base namespace. This would be wrong. The examples are right, here. 8. Section 9 states: A conferencing client that conforms to this specification is not required to support HTTP authentication [RFC2617] or cookies [RFC6265]. There is no "not required" in RFC 2119. Do you mean that it is OPTIONAL for a conferencing server to support RFC 2617 and RFC 6265? 9. In Section 10.4, please add an informational reference to RFC 4732.
This is an updated discuss. I've included the authors responses to the first 4
between [MB] and [/MB]. #5 and #6 are new.
#1) This document sometimes uses optional and mandatory to indicate support
requirements. These should be changed to use 2119 language. E.g., in 5.1, 5.2,
and 5.3.12.
[MB] Agreed. [/MB]
#2) Sec 4 includes the following:
The specification recommends the use of HTTP as
a transport solution, including CCMP requests in HTTP POST messages
and CCMP responses in HTTP 200 OK replies.
Should it be "RECOMMEND"? There were musts earlier but I think they were
specified in other RFCs.
[MB] Definitely yes. [/MB]
#3) Sec 4.4 includes the following:
In addition, to mitigate
the situation clients MUST NOT wait indefinitely for a response and
MUST implement a timer (in the range of seconds) such that when it
expires, the client MUST close the connection
Is there some recommendation you could give about how long to wait? 1 minute, 5
minutes?
[MB] It should be in 10s of seconds. I think 60 secs would be an upper range.
I'm inclined to suggest 30 secs as the default. [/MB]
#4) Sec 5.3.5 includes the following:
Through a "usersRequest" message the CCMP client manipulates the XML
<users> element of the conference document associated with the
conference identified by the "confObjID" parameter complusory
included in the request.
Is "complusory" supposed to mean it's mandatory? It would be better to just use
the 2119 language.
[MB] Yes. [/MB]
#5) I couldn't find an explicit statement that clients and server MUST support
both the request and response. Do we need that or is it assumed?
#6) In the CCMP Request there are 5 fields defined. All are optional. Doesn't
at least one field need to be a MUST? If there's no required field - can an
implementation that sends no fields in a CCMP Request considered compliant? I
had the same kind of comment against the xcom-common-data-model: It seems odd to
me that the protocol would specify sub-elements all of which are optional.
Maybe this is done all the time in XML land and I'm just picking on this draft?
In ASN.1-land, where I'm from, it's like having a CHOICE and not explaining
which one of the choices is a MUST.
#1) Section 5.1 subject references AAA, a reference is needed - it kind of came out of the blue. [MB] Okay. [/MB] #2) Sec 6 message 1 has: <confUserID>xcon-userid:alice@example.com</confUserID> shouldn't it be: <confUserID>xcon-userid:Alice@example.com</confUserID> [MB] Yes, this needs to be corrected. [/MB] #3) Sec 9 - "REQUIRED" is not 2119 language. [MB] "REQUIRED" is in the 2119 template that we used and is specified in RFC 2119 in the following context: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. [/MB] [spt] duh - homer simpson moment. [/spt] #4) Sec 10.1: r/the client must be able to validate the certificate./the client MUST be able to validate the certificate. [MB] Okay. [/MB] #5) Sec 10.1 - A reference to RFC 6125 is needed to ensure the server's ID is properly checked. [MB] Are you suggesting that we change the following sentence to something like the following? OLD: Note that in order for the presented certificate to be valid at the client, the client must be able to validate the certificate. NEW: Note that in order for the presented certificate to be valid at the client, the client must be able to validate the certificate, using a mechansim such as that specified in RFC 6125. [/MB] [spt] this or a pointer to 2818.
draft-ietf-avtext-multicast-acq-rtcp-xr
It would have helped me as a reader to have had some idea of the range of potential sizes of the random acquisition delay. I suspect that it can be expressed in packets and extrapolated to a time interval based on line speeds, etc. Obviously (?) if the range is 0 to < 1ms we might conclude that this work is not very necessary. Can you add a short note to help scope the work? --- Section 3 says: This document uses the following acronyms and definitions from [I-D.ietf-avt-rapid-acquisition-for-rtp]: But the definitions presented are somewhat different from those in the referenced document. Although the intent may be the same, I don't think it is helpful to have different definitions and I recommend that you remove all but a list of terms and a pointer to the other I-D. --- Nit Abstract s/ore/or/
(1) s/one ore more/one or more/
(C2 The constant 11 - I assume that's decimal - probably worth
saying just in case someone interprets it as '11'H or 3 or
whatever.
(C3 I think you want to to s/this bit/this field/g below.
o Rsvd. (16 bits): The RTP receiver MUST set this bit to zero. The
recipient MUST ignore this bit when received.
(4) Suggest rephrasing this in 4.2.1 (how can a time measured
locally be negative?)
OLD
o SFGMP Join Time (32 bits): TLV element that denotes the greater
of zero or the time difference (in ms) between the instant SFGMP
Join message has been sent and the instant the first packet was
received in the multicast session.
NEW
o SFGMP Join Time (32 bits): TLV element
with the time difference (in ms) between the instant the SFGMP
Join message was sent and the instant the first packet was
received in the multicast session.
1) in 4.1, "Rsvd. (16 bits): The RTP receiver MUST set this bit to zero. The recipient MUST ignore this bit when received." - MUST ignore these bits or MUST ignore this field. 2) in 7.1, do you want to replcae or supplement the existing RFC#? 3) in 7.4, should 0, 255, and 128-254 be included in the registry with approrpiate notations?
In 4:
It is better to send the MA report block after all the necessary
information is collected and computed. Partial reporting is
generally not useful as it cannot give the full picture of the
multicast acquisition, and causes additional complexity in terms of
report block matching and correlation. The MA report block is only
sent as a part of an RTCP compound packet, and it is sent in the
primary multicast session.
Is there a reason 2119 language was not used here? (i.e., SHOULD send
only after all information is collected, MUST send as part of an RTCP
compound packet in the primary multicast session)
In 4.2.1:
o SFGMP Join Time (32 bits): TLV element that denotes the greater
of zero or the time difference (in ms) between the instant SFGMP
Join message has been sent and the instant the first packet was
received in the multicast session. If the multicast join was
successful, this element MUST be included. If no multicast packet
has been received, this element MUST NOT exist in the report
block.
and
o Size of Burst-to-Multicast Gap (32 bits): Optional TLV element
that denotes the greater of zero or the difference between the
sequence number of the first multicast packet (received from the
primary multicast stream) and the sequence number of the last
burst packet minus 1 (considering the wrapping of the sequence
numbers). If no burst packet has been received in the unicast
session or no RTP packet has been received from the primary
multicast stream, this element MUST NOT exist in the report block.
When could the "greater of zero or" part kick in? That is, when can the
difference possibly be negative?
1. Some of the basic terms for the understanding of this document are being
referenced from [I-D.ietf-avt-rapid-acquisition-for-rtp]. It looks to me that
this document should be a Normative rather than Informational reference.
2. The Specification Required policy defined in Section 7.5 makes the following
recommendation.
The length of the Status field is two octets, allowing 65536 codes.
However, the status codes have been registered to allow for an easier
classification. For example, the values between (and including) 1
and 1000 are primarily used by the MA method of simple join. The
values between (and including) 1001 and 2000 are used by the MA
method described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. When
registering new status codes for the existing MA methods or newly
defined MA methods, a similar classification scheme is encouraged to
be followed.
However, there are currently 253 unassigned method values, so there is no room
for an allocation of 1000 codes for each of them which creates a potential
problem in the future. The language should be ammended (something else than
'similar classification scheme') and include some warning to IANA for caution on
this issue.
Additional text describing the assumptions around when you would use a status code of zero would help greatly. The expected use is that the sender of a report would only use that code when it knew from out-of-band methods that the receiver would understand the private TLVs in the report - one of those private TLVs, ostensibly, would replace semantics of the status code. Saying that explicitly would help avoid the situation where a client unintentionally throws away information like "multicast join was successful" by adding a private TLV that the server doesn't understand to a report that it would otherwise have used a status code of 1 on.
Sec 4.1: Please use 2119 language to indicate support requirements. Mandatory
is not 2119 language. Also, are block length and Rsvd optional?
Sec 4: r/The optional extensions that are/The OPTIONAL extensions that are Sec 4.2.1: r/Optional/OPTIONAL x 9. For Types 1 and 2 - are they optional too?
draft-ietf-mmusic-ice-options-registry
(1) s/these ICE options needs/these ICE options need/ (2) Are there no existing ice-options that should be added to the registry? Looks like there aren't but just checking.
draft-ietf-savi-fcfs
I support the discusses raised against this document.
1. The definitions of "source address validation", "address ownership"
and the concept that a " source address [...] belongs to the
originator of the packet" need to be clarified this paragraph:
2.3. Address ownership proof
The main function performed by FCFS SAVI is to verify that the source
address used in data packets actually belongs to the originator of
the packet. Since FCFS SAVI scope is limited to the local link, the
originator of the packet is attached to the local link. In order to
define a source address validation solution, we need to define some
address ownership proof concept i.e. what it means that a given host
owns a given address in the sense that the host is entitled to send
packets with that source address.
FCFS SAVI does not require that a host provide any sort of proof of
"ownership" of an address before that address is registered in an FCFS
SAVI function. A host merely needs to claim the address through
traffic sent to the FCFS SAVI function. In contrast, a SAVI function
implemented by bindings learned through manual configuration or
through interactions with a DHCPv6 address assignment function can
make a statement that an IP address belongs to a host.
What FCFS SAVI does is prevent simultaneous use of a single IP address
as a source address through multiple ports. There is no guarantee
that the FCFS binding in any way reflects intended ownership of the
bound address.
2. There needs to be text in section 2.1 explaining why FCFS SAVI is
applicable or inapplicable to addresses assigned through DHCPv6.
3. What about links for which there are no prefixes that are
advertised as on-link? Similarly, what about addresses that are
assigned through DHCPv6 but are not taken from an on-link prefix?
4. In section 3.2.2:
* If the IP source address does not belong to one of the local
prefixes of the receiving interface, this means that the data
packet is transit traffic and the packet SHOULD be discarded.
s/SHOULD/MUST/
How are the FCFS SAVI assumptions maintained and how is
spoofed traffic discarded if the FCFS SAVI function decides to forward
transit traffic?
5. Section 3.2.4 must be worded more strongly to guarantee FCFS SAVI
protection. Some of the items in the list are "MUST" or FCFS SAVI
protection will not be provided:
o Ports connected to hosts SHOULD be configured as Validating ports.
Not doing so will allow the host connected to that port to send
packets with spoofed source address.
o Ports connected to a chain of one or more legacy switches that
have hosts connected SHOULD be configured as Validating ports.
Not doing so will allow the host connected to any of these
switches to send packets with spoofed source address.
This requirement is a MUST. There are no alternatives to the given
configurations that still provide FCFS SAVI protection.
6. I agree with Stephen Farrell's DISCUSS points 3 and 4, but feel
less strongly about a fix. Specifically, I agree that FCFS SAVI is
inappropriate for a deployment in which an external router can pass
transit traffic to an FCFS SAVI function. But that just means SAVI
FCFS is inappropriate. There are other SAVI mechanisms that can work;
for example, a DHCPv6-based mechanism in which the (non-FCFS) SAVI
function is aware of the addresses and prefixes assigned through a
binding anchor and, therefore, bound to that binding anchor.
One way to address this issue some additional text describing how SAVI
can be used to provide perimeter security, where that SAVI might be
FCFS SAVI over part of the perimeter or some other kind of SAVI over
the remainder of the perimeter.
7. This paragraph from section 4 needs some clarification:
The other type of attack is when an attacker manages to create state
in the SAVI device that will result in blocking the data packets sent
by the legitimate owner of the address. In IPv6 these attacks are
not an issue thanks to the 2^64 addresses available in each link.
Random address selection makes it difficult for an attacker to hijack
an address and deny legitimate use of an address. However, in
deployments that use SLAAC, a host has a predictable global address
(perhaps augmented by random privacy addresses) that can be hijacked.
8. In TESTING_VP state, section 3.2.3:
o If a data packet is received through a Trusted Port port that is
other than port P, the state is moved to TESTING_TP-LT, and the
packet MAY is discarded.
Certainly it can't be just any packet received through a Trusted Port
that triggers this action. And, if P is a validating port, won't
traffic on any Trusted Port be "other than port P"? This bullet needs
to be corrected.
9. Throughout section 3.2.3, there are several occurrences of "If a
DAD_NSOL" which need the qualification ""with target address set to
IPAddr".
10. In section 3.2.3, does "==" mean "is set to"? In the last bullet
of TESTING_VP, does the FCFS SAVI function continue the TESTING_VP
state and is the lifetime modified?
1. What is the relationship between the contributors in section 6 and
the contents of the document and the list of authors? A quick
sentence about why the contributors are listed as such - rather than
as authors or in the acknowledgments - would be helpful.
2 I think it should be made clear whether the term "SAVI" refers to
"FCFS SAVI" or, more generally, to any form of SAVI throughout the
document. Section 2.6, for example, is unclear about the use of
"SAVI". It's important to be clear in section 2.6 because in my
opinion a SAVI perimeter could be composed out of various kinds of
SAVI functions.
3. What is the definition of a "realm"? It's important to define
realm because, by using ND to confirm the correctness of SAVI
bindings, the FCFS SAVI function only checks on the link to which it
is attached, not across the entire FCFS SAVI perimeter.
4. Also in section 3.2.3:
NO_BIND
o Upon the reception through a Validating Port (VP) of a Neighbour
Solicitation (NSOL) generated by the Duplicate Address Detection
(DAD) procedure (hereafter named DAD_NSOL) containing Target
Address IPAddr, the SAVI device MUST forward the NSOL and 250
In the last line, s/NSOL/DAD_NSOL/ How does the FCFS SAVI function
differentiate between NSOLs generated by DAD and other NSOLs?
5. In TENTATIVE state, section 3.2.3:
the state remains in
TENTATIVE_DAD_NSOL,
s/TENTATIVE_DAD_NSOL/TENTATIVE/
Some questions I think the authors should respond to:
I believe the RetransTimer is configurable in RFC 4861, so why is 250 ms a magic
number in Section 3.2.3 of this document? Are there scenarios where this value
needs to be configured differently or is this really one size fits all? I
didn't notice the motivation for this constant in the document, and it probably
should be explained. It seems to be fixed rather than just a default, but the
wording in this document is actually a little ambiguous about this.
The same comment applies to TENT_LT (500 ms) and DEFAULT_LT (5 minutes). If
these constants are special for some reason and not just defaults that can be
tweaked to suit a deployment, it needs to be described why, otherwise the logic
for setting them a certain way needs to be given.
Some comments that I don't think are very important and that the authors should feel free to either take or ignore: In section 2.1, second paragraph, it might make sense to be more clear that routers use their own MAC address, but the packets that they forward have an off-link source address that doesn't belong to them. However, I don't think anyone will really be confused either way, so this is just a suggestion. The definition of the term "binding anchor" is somewhat implicit in this document. It might be a good idea to make it more explicit with just a sentence or so more where it's first used in 2.3, and only one very brief example is given. In section 2.3, second paragraph, should "(e.g. the port in a switched LAN)" be "(e.g. the MAC address and/or port in a switched LAN)"?
There are plenty of Discuss points already raised with which I agree. --- Section 1 "The proposed mechanism..." It is no longer a proposal. --- The figure on page 9 has a misalignment. --- The writeup says: There are existing implementations of a very similar feature for IPv4. This is fair enough, but I am surprised to see no reference to this in the document and no description of the differences.
While this is quite long and maybe has some controversial things, it
doesn't impact that much on details of the actual scheme so I hope
it's less bad than it appears.
(1) A general point about SAVI that also applies to SAVI FCFS: Since
SAVI is only about spoofed source addresses and is not about
monitoring hosts that never spoof anything, and since privacy is a
concern for the (I assume) huge majority of non-spoofing hosts I
would like to see this (and all SAVI standards track documents) say
something like:
"Compliant implementations MUST NOT log binding anchor information
except where there is an identified reason (see section X for the
list of reasons applying for FCFS-SAVI) why that information is
likely to be involved in detection or prevention of actual source
address spoofing. Information that is not logged MUST be deleted as
soon as possible (see section Y for the conditions that make it safe
to delete information). Information about the majority of hosts that
never spoof SHOULD NOT be logged."
The conditions for when logging is allowed and when each piece of
state can be deleted need to be specifically called out. Those would
be the putative sections X & Y in the above suggested paragraph above.
I realise this may seem like a significant change (though not to the
parts of the protocol that actually detect spoofing) but I think it is
an important one.
(2) Abstract - SAVI is not about the general "control of source
addresses used" - it is chartered to help detect/prevent source
address spoofing and that is all.
(3) My phone can be a WiFi access point. How would that continue to
work if SAVI-FCFS were deployed? I think the document needs to say how
one can differentiate transit traffic from spoofed source addresses in
that case or that SAVI FCFS MUST NOT be used in networks that should
allow my phone to do its thing. 2.1 says that this technique only
applies to local traffic so implementers will need to know how to do
this.
(4) I think SAVI FCFS needs a way to allow transit traffic and
disallow spoofed source addresses but that is not trivial to fool by
just pretending to be a router. If that is not possible, then this
technique just seems broken. Its not clear to me whether the spec has
this problem or not.
(5) 2.4 - saying you "assume" that the binding anchor is a port on a
switched network implies that SAVI-FCFS MUST NOT be used in any other
case. You need to say that. On a related point, you need to clearly
say that this is just for IPv6 if that is the case, (depending on rfc
4861 seems to make that the case). All text that implies that the
binding anchor for SAVI FCFS can be anything other than a port number
should also be excised since SAVI FCFS is only defined for the port
number being the binding anchor as far as I can see. This could
probably best be done via an applicability statement section at the
front. (Probably just a short paragraph is all that's needed.)
(6) 2.5 I totally disagree that its a good idea for SAVI to log all
this information. I'd like to see the section removed. (And as in (1)
above, replaced with a MUST NOT for "normal" traffic and binding
anchor information.)
(7) (If 2.5 ends up staying...) Where in the SAVI charter does it say
that "a secondary goal is to assist in traceability.."? Is there IETF
consensus for this goal? I don't believe there is. RFC 2804 would
imply the opposite.
(8) If I end up in the rough on point (1) above, I would like to
discuss whether not not SAVI goals could be met while only dealing
with an anonymized form of binding anchor information. If so, then
maybe you should have a MUST for doing that where the binding anchor
information could be personally identifying. While this is less
relevant for SAVI-FCFS than perhaps other variants, (e.g. MAC address
or NAI) even a port can be personally identifying in a some networks.
(9) The SAVI DB content says "such as the layer-2 address" but you've
gone to lengths to say that's not trustworthy so its presumably not
useful for detection of source address spoofing and should not be
included here. See also point (1) above - MAC addresses of
non-spoofing users should not be retained casually like this. I'd like
to see a statement that personally identifying data MUST NOT be
included in the SAVI DB with the MAC address as the canonical example.
(If packets do indicate attempted spoofing then I've no problem about
logging the MAC address.)
(10) The prefix in the prefix list is v6 only - right? If so maybe
worth saying so.
(11) 3.2.1 talks about what the SAVI device does when it boots - is
that the only time it is supposed to update the prefix list for
transit traffic? That seems wrong.
(12) 3.2.2 uses the phrase "local prefixes" which doesn't seem to be
defined - does that cover prefixes for routers or not?`
(13) 3.2.2 seems to say that transit traffic received on validating
ports is just dropped - that can't be right so maybe the text needs to
be rephrased to make it clear what happens. This may be related to
(12) above, but I find 3.2.2 just too hard to follow.
(14) MLD is used without expansion and with no reference.
(15) End of state machine, p17 - what does "P'==P''" mean here?
(16) Why are the security considerations talking about the binding
anchor being a MAC address when you've ruled that out? The spec needs
to be clear about what binding anchor information can be used and not
discuss other possible binding anchor information types.
[The next 3 are from the secdir review by Juergen Schoenwaelder.]
(17) [secdir#1]
My first question was triggered by text on page 8:
[...] Before creating a SAVI binding in the local SAVI database,
the SAVI device will send a NSOL message querying for the address
involved. Should any host reply to that message with a NADV message,
the SAVI device that sent the NSOL will infer that a binding for that
address exists in another SAVI device and will not create a local
binding for it.
Now, that sounded like it is easy to DoS new devices simply by
generating fake NADV messages. Later in section 3, it seems you only
accept NADV messages from trusted ports. If my reading is correct,
then a better wording might be:
[...] Before creating a SAVI binding in the local SAVI database,
the SAVI device will send a NSOL message querying for the address
involved. Should any host _on a trusted port_ reply to that message
with a NADV message, the SAVI device that sent the NSOL will infer
that a binding for that address exists in another SAVI device and will
not create a local binding for it.
But then I am not sure whether it is really practical to assume that
NADV messages always come from a trusted port.
(18) [secdir#2]
My second question concerns the construction of the prefix list. One
option is to learn prefixes by listening to Router Advertisements. Is
there a way to make SAVI do bad things by announcing bogus prefixes?
(19) [secdir#3]
My third question concerns this statement in the security
considerations:
The other type of attack is when an attacker manages to create
state in the SAVI device that will result in blocking the data packets
sent by the legitimate owner of the address. In IPv6 these attacks
are not an issue thanks to the 2^64 addresses available in each link.
The second sentence makes this sound like a non-issue but it seems to
be correct only if devices uniformly pick random addresses out of the
full 2^64 address space. If for whatever reason I can guess with a
decent likelihood an address, it looks like SAVI becomes a tool to
help me with denying service for such an address.
(20) The "Security Logging" section should be changed significantly to
say that only suspected spoofing should be logged and that for privacy
reasons SAVI MUST NOT otherwise log normal use of the network.
(1) I don't understand the sentence at the end of 2.1 " Manually configured IPv6 addresses can be supported by FCFS SAVI, but manual configuration of the binding on the SAVI device provides higher security and seems compatible with manual address management." (2) 2.2 says that "non-compliant" packets can be dropped - there's no IESG write-up so I'm wondering if this is safe or if there's any evidence that this would be safe? Has this been implemented and if so have any results of its effects been published? (I know that's not a requirement for PS, but in this case, I think it would be very useful information.) (3) 2.3 "prove address ownership" is too strong and I think ownership is the wrong phrase in any case. (4) I don't understand "FCFS SAVI function relies on state information binding the source address used in data packets to the binding anchor that contained the first packet that used that source IP address." Seems like it needs re-phrasing - "contained the first packet" is the wrong bit. (5) The "it" in "CFS SAVI function relies on state information binding the source address used in data packets to the binding anchor that contained the first packet that used that source IP address" seems ambiguous. I'm fairly sure it refers to each SAVI instance rather than the set of instances in a SAVI perimeter but that should be made clear. (6) State machine ascii art - expanding T.O. to timeout (I guess) would be clearer. (7) "MLD considerations" - should you s/relay/rely/? (8) From section 4 on there are more English language errors that should be fixed, e.g "The attacks against the SAVI device basically consist on making the SAVI device to consume its resources until it runs out of them" has two (and maybe 3) errors. There are also some similar problems in Appendix A. (I have some marked up on paper so easiest will be if I try to list any that remain if you rev. the I-D.) (9) [secdir review nits] Editorial nits: - p10: s/because the connect/because they connect/ (twice) - p10: s/through validating port/through validating ports/ - p11: s/prefixes.A/prefixes. A/ - p13: s/may due/may be due/ - p13: s/packets has been/packets have been/ - p18: s/relay/rely/ - p24: s/coalition/collision/ - p26: s/case fixed/case of fixed/
There are many points in my DISCUSS, but most are requests to tighten the
RFC2119 language, or explain in the text what the valid exceptions are to each
SHOULD.
1) this only deals with ipv6. The charter says ipv4 and ipv6 must be covered.
Why doesn't this document also deal with ipv4, and is there another document
that deals with ipv4?
2) in 2.4, "For the rest of the document, we will assume that the binding
anchors are ports of a switched network." Having this statement at the end of a
paragraph in non-normative background text seems insufficient. To be compliant
to this standard, the binding anchors MUST be ports of a switched network. I
think this should be clearly specified in RFC2119 langauge in the normative
section.
3) in 2.5, "a secondary goal is to assist in traceability for determining who an
improper actor is." I don't see this in the charter, and question whether this
is an IETF-supported secondary goal. (I see that Stephen has raised a DISCUSS on
this in more detail).
4) in 3.2.2, "transit traffic and the packet SHOULD be discarded" why only
SHOULD? what are the valid exceptions to this?
5) in 3.2.3, "the SAVI device
SHOULD execute the process of sending Neighbour Solicitation messages"
s/SHOULD/MUST/
6) "are NOT forwarded" s/are NOT/MUST NOT be/
s/they are
sent/they MUST be sent/
s/are discarded/MUST be discarded/
s/is discarded/MUST
be discarded/
s/packet is either stored or discarded/ - why the choice? Please
use RFC2119 language.
... the rest o fthe state table shoul dbe in RFC2119
terms.
s/relay/rely/
s/must join/MUST join/
s/SHOULD join/MUST join/
7) 3.2.4
"SHOULD be connected" - when is ti valid to not be connected? should thi sbe a
MUST to ensure that transit traffic is not dropped?
multiple SHOULDs here; why
not MUSTs? If SHOULD, what are the valid exceptions?
8) 3.2.5 "will behave as if
" - MUST behave as if
9) section 4, why 4 bindings? where did 4 come from?
Doesn't this exhuast memory four times faster than an implementation that
reserves memory for 1 binding per port? Isn't the reserved memory wasted if the
port consistently has only one binding?
10) "A SAVI device MUST limit the amount
of memory" I think this should be a SHOULD. If an implemnter chooses to allocate
unlimited memory, they should probably be allowed to. How will thi sbeing a
SHOULD impact interoperability, as compared to its being a MUST?
11) "The other
type of attack is when an attacker manages to create state in the SAVI device
that will result in blocking the data packets sent by the legitimate owner of
the address. In IPv6 these attacks are not an issue thanks to the 2^64 addresses
available in each link." I don't see how the 2^64 addresses available mitigates
the ability of an attacker to create state that would block a valid address.
12)
"the SAVI device can be used as an amplifier by attackers. In order to limit
this type of attack, it is RECOMMENDED that the SAVI device performs rate
limiting " why not MUST?
1) in 2.3, "SAVI checks would not be fulfilled by the transit traffic" I think fulfilled might be the wrong word here; do you mean performed? 2) a stylistiuc point. The document often uses "This means". This is totally unnecessary. Just say what it means without the "this means phrase". This means don't use this means. 3) in 2.6, summary, "A SAVI device only verifies packets coming through one interface connected to the untrusted part of the topology." why only ***one interface*** per SAVI device? 4) in 2.6, "In particular, it is important to avoid that the same source address is bound to different binding anchors in different SAVI devices. Should that occur, then it would mean that two hosts are allowed to send packets with the same source address, which is what SAVI is trying to prevent." Is this accurate? Does it necessarily imply there are two hosts?
Section 2 title - I would prefer to strike "non-normative". I see no reason for it and the use of this expression is turning into an IETF fetish. Instead, you can add on to the the Introduction: "Section 2 gives the background and description of FCFS SAVI, and Section 3 specifies the FCFS SAVI protocol." Section 2.6: Before creating a SAVI binding in the local SAVI database, the SAVI device will send a NSOL message querying for the address involved. Should any host reply to that message with a NADV message, the SAVI device that sent the NSOL will infer that a binding for that address exists in another SAVI device and will not create a local binding for it. If no NADV message is received as a reply to the NSOL, then the local SAVI device will infer that no binding for that address exists in other SAVI device and will create the local SAVI binding for that address. (NOTE that the description included here is overly simplified to illustrate the mechanism used to preserve the coherency of the binding databases of the different SAVI devices. The actual SAVI mechanism normative specification as described in Section 3 varies in the fact that in some cases it is the SAVI device that generates the NSOL while in other cases it simply forwards the NSOL generated by the end host, and that the SAVI device will send multiple copies of the NSOL in order to improve the reliability of the message exchange, among other things). Start with the words, "As a simplified example of how this might work:", and then strike the parenthetical NOTE entirely. Section 3 title - strike "normative"
Section 3.2.5 speaks 'the case the SAVI device is a switch that supports
VLANs'but provides no reference to what IEEE 802,1 specification it refers and
what types of VLAN capable bridges (switches) are covered. Is the intent to
cover all types of VLANs defined by IEEE 802.1? Clarification and proper
references are required.
Please expand "DoS" on first use and add an informational reference to RFC 4732.
rfc5590
rfc5591
rfc5953
I'd like to understand this bit of text in the interop report:
Neither implementation claims to be a complete, bug-free
production ready implementation, and occasional differences have
been found noted between the implementations. To date, however,
all the differences have fallen into one of these categories:
- object not implemented yet
- corner cases not handled yet
- code needs to be refactored to meet requirement
In other words, so far all issues are with a particular
implementation, not with the specification.
These are very general statements and I'm simply not clear on how it
was determined that this wasn't a specification problem.
Much as I would love to believe that changing a bit of text in Section 7 solves
the problem of moving SNMP-over-TLS from IDNA2003 to IDNA2008 (and recognizing
that I provided that bit of text to the responsible AD!), I fear that it does
not. I realize that probably few if any implementations of RFC 5953 have been
deployed with internationalized domain names, which might be why the
implementation report does not mention IDNs. However, from the standpoint of
both protocol development and technology deployment I think there's more work to
be done here. I look forward to discussing this on the IESG telechat.
1) There are several normative references in this document to RFCs that are not
ready to progress to Draft Standard. It's not clear that the parts of those
drafts that are used are stable. In particular, this RFC currently references
RFC3490 - the RFC Editor note updates the reference to 5890, but did the interop
testing cover implementations of this protocol using the techniques in 5890?
Would any further changes to IDNA impact what's specified in this draft?
Similarly, the draft references RFC5280, which has errata and a clarification
draft in progress. Are the parts of 5280 this protocol uses stable?
2) I believe asking the RFC Editor to issue a new RFC based on the existing RFC
and a set of RFC Editor notes is likely to lead to unexpected trouble that could
be avoided by processing this as a draft. At a minimum:
- Is it clear what
boilerplate the RFC Editor should use on the new RFC?
- Who signs off on the
new RFC in AUTH48?
rfc5343
draft-daboo-et-al-icalendar-in-xml
I have no objection to the publication of this document altough I raise a point below that seems to me to be a potntial issue. --- I'm not convinced that this document is completely future-proofed. I understand how future components, properties, and parameters will be converted into XML elements using a designated naming convention. But it seems to me that more complex entities (such as multi-valued properties) cannot be simply and automatically handled. Indeed, the need to present a schema in Appendix A (rather than simply define the rules for how it is automatically created) seems to imply that there is a little more work that will be needed when future extensions to iCalendar are made. In view of this, I think we need a section specifically discussing extensions to iCalendar. I think that the current Section 5 is a subset of this new section. --- Nit Section 1 "semantic meaning" One of the words is redundant.
(1) In 3.6.5 can the date-time element value include TZ offsets? I think it'd be worth being explicit about this and adding a 2nd example with an offset if that's allowed. (It looks from the later examples like this is allowed.) (2) In 3.6.8 is INTEGER can be negative, then it'd be worth adding a 2nd example with a negative number. (3) In 3.6.11, if UTF8 characters are allowed, then it'd be good to add an example like that, or if that's hard in an RFC, then just say so and if they're not allowed, then just say that to make a coder's life easier. (4) In 4.2 when it says "IANA, non-standard, inline encoding..." should there be a reference to make it easier for an implementer to figure out what this means?
- You claim that round-tripping is a design goal. I'm wondering about the base64 and folding round-tripping. The document clearly takes into account cases of iCalendar objects that have unnecessary base64. Is it at all problematic that this will not round-trip according to the rules you set out? - Instead of "the table is a non-normative reference", how about "the table gives examples of ...". The words "non-normative reference" have a specific meaning in RFCs and there is no "referencing" going on here. If you really need to call out that these tables are not normative, say something in section 2 like "The examples given in the tables throughout this document, along with the schema in Appendix A and examples in Appendix B, are not authoritative, and if there is a conflict between these and the definitions given in sections 3 and 4, the definitions in section 3 and 4 are to be taken as authoritative."
#1) Sec 3.1: Do you need a normative reference to the Base64 RFC:
http://datatracker.ietf.org/doc/rfc4648/? Also do you need to specify which
alphabet you're using?
#2) Sec 3.2: r/is an optional/is an OPTIONAL ?
draft-josefsson-gss-capsulate
The introduction to this document says:
The intention is that text from this specification should be possible
to use for implementation documentation, and for this reason this
entire document should be considered a code component.
Claiming that the whole document is a code component is inappropriate.
However, I have no objection to claiming that Sections 3, 4, and 5 are
code components.
The writeup says that there are 3 implementations. Are they independent? Is there any sense in which the interoperate? The "interoperate" question is the really important one to me: I'm trying to figure out why a PS is being used for an API. Is there some way in which having the same API will make things interoperate better?
This document seems more Informational than Standards Track to me, but I have no objections to publishing it as a Proposed Standard.
I agree with Russ' discuss regarding what portion of the document is a code component.
draft-ietf-xcon-examples
I am ballotting "No Objection" after only a light skim of the document, mainly trusting the RAI ADs to have checked this document. However, I do wonder whether one sentence in the Abstract is open to misinterpretation. It says: The objective is to provide a base reference for both protocol researchers and developers. That sounds like the flows in this document form part of the normative definition of the protocol. This is presumably not the intention of this Informational I-D. You can resolve this simply by moving that sentence from the Abstract to the Introduction and qualifying it by deferring to I-D.ietf-xcon- ccmp.
The Gen-ART Review by Francis Dupont on 5-Mar-2011 suggested several editorial changes. Please consider them.
It's not clear to me why RFCs 3261, 4579, 4597, 4575, 5567, and draft-ietf-xcon-
common-data-model and draft-ietf-mediactrl-call-flows are not all normative
references. As far as I can tell, these are all required reading to understand
this document.
[I will likely clear this next one immediately, but I'm leaving here because I
want to discuss this in the context of the other two xcon documents] I'm again
worried about text that is common between documents, especially section 4 of
this document. In particular, the information in 4.2 looks like it should be in
section 9 of draft-ietf-xcon-ccmp.
Two issues related to passwords:
a. Is it <password> or <conference-password>? It's <password> in 6.2 message 1?
Where is that defined? It's not in 4575, or any of the other two xcon drafts on
the telechat this week.
b. Should these be exchanged over HTTPS!?
There's a couple of places where Alice's xcon-userid: is alice@example.com and not Alice@example.com. Not sure if you did this on purpose or not.
draft-ietf-siprec-req
I think this is a bunch of what should be fairly easily resolved
things.
(2) I don't understand REQ-025's statement about the "same or
different" encryption keys, and I suspect that the requirement, as
stated, might lead to bad designs, e.g. adding bad key export APIs
to products. I think stating this in terms of keys is mistaken, it
should probably be stated in terms of restricting access to the media
(or something like that, not sure).
(4) What non-repudiation requirements exist here? Put another way,
who is expected to repudiate what, and how is that supposed to be
prevented? Including NR might lead to significant complexity if not
fairly tightly constrained. I'd suggest just dropping mention of NR,
unless there are specific requirements known at this point.
(5) The security considerations says: "Means for ensuring the
integrity and correctness of media and metadata emitted by an SRC are
outside the scope of this work. Other organizational and technical
controls will need to be used to prevent tampering." That however,
seems to conflict with REQ-029 at least. Perhaps something else was
meant, or I'm just confused?
(1) "Furthermore, the scale and cost burdens vary widely, in all markets, where the different needs for solution capabilities such as media injection, transcoding, and security-related needs do not conform well to a one-size-fits-all model." That could do with being rephrased, I had to read it a few times before I got the message that one size doesn't easily fit all. (2) In figure 2, I assume that time runs from left to right but you might want to say that, e.g. add "t --->" at the bottom. If its meant to be something else, then you definitely want to say what. (3) REQ-005 - I think the "without loss of media" refers to the RS but not the CS - is that right? Maybe worth clarifying. (4) Just asking: REQ-019 is good, but was there any discussion about how much information to make available to a UA? E.g. whether or not card numbers won't be recorded.
REQ-012 refers to "the identities of parties involved". The term "identity" is vague. I suggest changing "identities" to "identifiers" or, even better, "SIP identifiers" or "SIP addresses". In REQ-024, what is "wall clock time"? Regarding terms such as "authentication", "confidentiality", "encryption", and "integrity" in REQ-025 through REQ-032, an informational reference to RFC 4949 seems appropriate.
draft-ietf-grow-geomrt
6. Security Considerations This extension to the "MRT format" [I-D.ietf-grow-mrt] defines fields that are of a descriptive nature and provide information that is useful in the analysis of routing systems. As such, the author believes that they do not constitute an additional security risk. It is recommended that the operators of the BGP collector and Peers consider their own privacy concerns before supplying geographical coordinates in MRT dumps. Comment: Isn't there also an enhanced threat in revealing to a physical attacker the precise geographical location of a strategic router?
I agree with other points raised about revealing physical location, and I have a couple of additional questions: 1. How does the BGP collector obtain the geolocation of its peers? 2. From section 8: It is recommended that the operators of the BGP collector and BGP peers consider their own privacy concerns before supplying geographical coordinates to BGP data collection systems. Depending on the answer to 1, how does the BGP peer control how its geographical coordinates are supplied to the BGP collector?
Support the other ADs DISCUSS positions on Informational vs. Standards Track Further, the security considerations should at least mention the fact that there's no way to prevent someone from lying about location data, yet would appear to have no bearing at all on BGP operation. It might totally mess up any later analysis someone is trying to use the MRT data for as they'd have little way to validate historic coordinates for a given router.
draft-ietf-grow-mrt is Standard Track. I don't understand why this
I-D (which defines further protocol extensions) is Informational.
Given that "This document extends the Border Gateway Protocol (BGP)
Multi-threaded Routing Toolkit (MRT)..." I don't see why there isn't
an "Updates" statement in the header.
---
draft-ietf-grow-mrt appears to create an IANA registry to track
subtypes. Why does this document not include IANA actions for the new
subtype that it defines?
Note that the allocation procedures in draft-ietf-grow-mrt are "IETF
Review" so you would be OK if this document does stay as Informational,
but you would still need an IANA section.
I agree with Stewart's point about physical security, and suggest that you should highlight the point.
- MRT is not expanded. - Good luck with the PhD/hope it went well:-)
The Gen-ART Review by Roni Even on 16-Apr-2011 included two questions.
These questions were asked in a Last Call comment, but the questions
were not answered. I would like to know the answers.
1. Why not include it in draft-ietf-grow-mrt?
2. Why is this Informational RFC and not standard-track like
draft-ietf-grow-mrt?
Please expand MRT when first used.
This can either be Standards Track or Experimental. It's not Informational. It's
extending a Standards Track protocol.
draft-ietf-savi-threat-scope
A useful document which I enjoyed reading
I will raise a meta-discussion issue before listing several specific
Discuss points. This issue may be just the suppressed pedantic
ex-professor side of my personality expressing itself. My issue is
that the contents of this document are useful and not incorrect.
However, in my opinion the document would be more useful, especially
to someone who reads this document without a lot of background in the
type of threats described, with some additional detail. I could be
persuaded that I am being overly pedantic, in which case I will clear
my Discuss and move my points to Comments. I will be happy to send
text if the authors would find it helpful.
1. In section 1:
At the IP Network Layer, or Internet Layer, there is typically no
required transactional state when communicating with other hosts on
the network. Hosts generating packets for transmission have the
opportunity to spoof (forge) the source address of packets which they
transmit.
I think this paragraph needs more detail to connect the first sentence
with the last sentence.
2. Next paragraph:
Source address verification is necessary in order to detect and
reject spoofed packets and contribute to the overall security of IP
networks. In particular, source address verification techniques
enable detection and rejection of spoofed packets, and also
implicitly provide some assurances that the source address in an IP
packet is legitimately assigned to the system that generated the
packet.
"Source address verification" can be used or is necessary? You
haven't told us what source address verification is, yet. The second
sentence in this paragraph doesn't seem to add any new information.
What would be more helpful would be a sentence or two foreshadowing
the details in section 3. Why are packets with spoofed addresses
dangerous?
3. The attacks in section 3 fall, roughly, into two buckets: those that
require spoofed source addresses and those that can use spoofed
addresses to obfuscate the source of the attack. SAVI can eliminate
the former but only deter, through threat of discovering the
perpetrator, the latter. The difference is important to someone using
this document to learn about how SAVI contributes to security in a
network. Otherwise, a network administrator might expect to eliminate
all of the listed attacks with SAVI.
An improvement would be to explain the two types of attacks and
indicate the type of the attacks in section 3.
4. I found the second sentence of the first paragraph of section 4
very hard to parse and not entirely consistent with the title of the
section. While most of the solutions in section 4 have to do with the
network topology, the first bullet:
o The IP source address is appropriate for the lower layer address
(they both identify the same system)
has nothing to do with network topology.
The second bullet:
o The IP source address is appropriate for the device at the layer 2
switch port (the address was assigned to a, and perhaps the,
system that uses that port)
does use network topology, but seems specific to wired networks; in
fact, later in section 4, wireless networks are mentioned as using
different techniques. Might be better to write:
o The IP source address is explicitly identified as appropriate
for the physical topology; for example, the source address
is appropriate for the layer 2 switch port through which the
datagram was received
5. Section 4.1.1 changes in mid-section from checking the IP address
against the Link Layer address to checking the IP address against the
physical attachment point. Is Link Layer address checking ever
implemented on switches or is it always IP address checking versus the
physical attachment point?
6. I suggest augmenting section 4.1.3 with a mention of IPv6 prefix
checking, where the PE can be populated with the customer prefix
through monitoring DHCPv6 prefix delegation.
Also, the enterprise case can be augmented with prefix filtering based
on the prefixes known by the ISP to be assigned to the customer.
7. Sections 4.1.5 either needs more detail or pointers to references
where more detail is available. In its current form, it has little
or no content. The interesting parts of DOCSIS are the authentication
and trust model, in which the ISP can control and trust the cable
modem.
8. Section 4.1.6 has more detail than section 4.1.5, but assumes some
experience with DSL deployments and architectures. Both of these
sections would benefit from some explanation of the accountability
model in which packets can be traced to an accountable entity,
regardless of the specific address or prefix in the source address of
a packet.
9. Section 4.2.3.2 might benefit from just a little more detail, or a
pointer to more detail:
switch uses IP address to port binding
switch enforces restrictions that DHCP server traffic is only
accepted from "upstream"
switch monitors DHCP traffic to glean address-port bindings
This technique works for both IPv4 and IPv6.
And, the discussion of SLAAC brings up the issue of authenticated SAVI
versus "ad hoc" SAVI. In the case of DHCP based SAVI, the switch can
have authoritative information about the address/port binding, because
it came from a reliable source (DHCP server). SLAAC-based SAVI can
only identify claimed addresses, where the hose may not be authorized
to use the claimed address.
10. Are the techniques mentioned in 4.2.4 really SAVI?
11. What is a "residual attack" and how does the text in section 4.2.5
describe a residual attack?
1. Add DoS (yeah, I know DoS is pretty widely used already), "binding anchor" (and use "binding anchor" through the document), MITM, LAND, smurf attack, uRPF to section 2. Some of these also have first-use expansion, which might be OK ... this suggestion is just a Comment. 2. Suggestion: it would be more useful to incorporate any issues specific to IPv6 in the body of the document. 3. First sentence of section 4: The first requirement is to eliminate datagrams with spoofed IP addresses from the Internet. First requirement for what? I thought this document was exactly about "eliminat[ing] datagrams with spoofed IP addresses from the Internet." I suggest dropping the sentence. 4. At the end of section 4, the bullet list calls out "enterprise CPE Router" explicitly. Aren't residential CPE routers also a big opportunity? How are they different from enterprise CPE routers. In fact, perhaps "CPE" is not the best term? How about "Enterprise edge router" and add "subscriber home router"? 5. At the end of section 1, have the strength of your convictions: This document provides [...], and discusses [...]. 6. For consistency, in sections 3.2.1 and 4.1.1 s/MAC address/Layer 2 address/ 7. Is "source address verification" equivalent to "Source Address Validation Improvement (SAVI)"? If so, for consistency use one phrase or acronym throughout.
The document looks good, I just have a few comments that the authors might think about: Section 3.1.7 is titled "other blind spoofing attacks" but talks about non-blind attacks just as much. The example given of a host on-link with routers is non- blind, for instance. However, seciton 3.2 is where non-blind attacks are supposed to be discussed, so this part of 3.1.7 seems rather odd. Why isn't the relationship to SeND discussed in this document? VPN gateways have similar considerations as the Mobile IP HA in sectino 5.2.6, but VPN gateways don't appear to be discussed in 5.2.
(1) What's the difference between "validation" (abstract) and
"verification" (overview, 3rd para) as used here? If there is
none, then just use one. If this is a difference, then where are
these defined? I think in either case, some definition is needed.
(2) I expected this document to also analyse source-address
spoofing threats after SAVI mechanisms are deployed. If some simple
form(s) of source address spoofing will work regardless of which
SAVI mechanism(s) are in place then one would have to wonder if
SAVI is worth deploying or not. If this is not the right document
to cover that then what is? The fact that the SAVI mechanisms will
each be in separate documents would seem to mean that this question
won't otherwise be answered by the WG, and I think we do need an
answer somewhere. (The security considerations of the SAVI
framework is currently one paragraph so that's not the place, at
least not now.) Its probably worth noting that this issue is behind
a number of cases below where I ask for evidence to justify what
appear to be overly broad claims made.
(3) What is the evidence that "Source address verification is
necessary in order to detect and reject spoofed packets"? I'm
asking why this is "necessary"as opposed to sufficient (if it is
sufficient - see (2) above).
(2) This presumably needs some form of qualification if not all
packets with spoofed source addresses can be spotted: "source
address verification techniques enable detection and rejection of
spoofed packets." I'm not sure if "some spoofed packets" would be a
good thing to say there but it does seem to be the case - a better
qualification (or a forward reference to where that is described)
would represent truth-in-advertising.
(3) Where in the charter is "local traceability" in scope? The
charter does say that "tracking other protocols is not in scope" so
local traceability needs to be defined as something limited
to/scoped to spoofed source addresses.
(4) "For example, when an enterprise receives a report of an attack
originating within that enterprise, the operational staff needs to
be able to track from the IP address sourcing the attack to the
particular machine within the enterprise that is the source." I
don't think that's true in general - "needs" is wrong since there
can be other ways to find a zombie.
(5) Spoofing is defined to cover both IP and MAC address spoofing.
SAVI does not address the latter I believe (right?). If so, then I
think you need to separate these as otherwise confusion between
them might lead to incorrect conclusions being stated. Spoofing is
also defined as "forging" but that is not defined and could be
considered to be synonymous with "spoofing" here which would make
this a circular definition. I think the definition of spoofing
needs to be more precise basically.
(6) 3.1: " The result is that they have no access to legitimate
source and target systems." I think that's wrong - are you trying
to say that "The attacker in this case should have no legitimate
access to source and target systems."
(7) Does the ARP example in 3.2.1 really involve a spoofed IP
source? If not, then you should note that its not in scope for
SAVI. If it is, then say why its in scope.
(8) I'd be interested in knowing if SAVI can help with 3.2.2 - if
not then saying so would be right. If so, then saying when SAVI
might help would be good.
(9) If "The first requirement is to eliminate datagrams with
spoofed IP addresses from the Internet." then SAVI would seem to be
facing an impossible problem. The "can eliminate such datagrams"
part also seems overstated - where's the evidence that that's true?
s/eliminate/reduce/ would seem to be more correct.
(10) Saying that "Internet devices can...confirm...that the IP
address is appropriate for the lower layer address" is not true of
all "Internet devices" only for some near the source, so that's
also overstated and needs to be qualified. (It is later to be fair
but the statement itself is wrong.)
(11) I don't know the answer here, so this is just a question -
what is the likelihood the uRPF check works well? (I didn't find
the string uRPF in RFC 3704, so I'm not sure, but I didn't really
read 3704;-) I guess the real question is whether a failure in uRPF
might break anything for a non-spoofing host and whether a spoofing
host could make it so that uRPF checks allow the packet with a
spoofed address through (from e.g. the same subnet, or for certain
guessable source addresses). I ask (in part) since 4.2.2 says that
uRPF is a crude mechanism.
(12) I'm not sure whether 4.1.3 and 4.1.4 are in or out of scope
for SAVI. Can you make that clear?
(13) What does "unforgeable" mean in 4.2.3? Perhaps you need to
define that term as well? It may be that the meaning differs for
e.g. MAC addresses and other credentials (noting that passwords can
be guessed or shared of course).
(14) In 4.2.3 where is the evidence that "a large portion of the
...threat space...can be marginalized" - I think that needs some
qualification.
(15) 4.2.3.2 says that DHCP and sniffing "can...auotmatically
provide sufficient binding information" - is there evidence for
that somewhere? Be good to reference it.
(16) 802.1X determines the identity of a user, not a system I
think.
(17) I think 4.2.5 needs to better characterise the "residual
threat" (not "residual attack") - for each of the various forms of
SAVI. I had hoped this document would say what spoofing
possibilities remain. Providing just one example doesn't seem
sufficient.
(18) Section 6 (at least) should also recognise that there are
privacy considerations that apply and that more-or-less directly
run counter to the ability to trace the source of problems.
(19) Section 8 should note that circumstantial evidence linking a
person to an IP address can be dangerous for the person. There have
been cases where such tracking has mis-identified people
responsible for some act. (I don't have a reference to hand sorry.)
(20) If no set of deployed SAVI instances can prevent all spoofing
from a given network then an attacker could probe the network to
find out what spoofing works from where they are at, and then use
that. Success in spoofing would then likely have more consequences
for an innocent spoofed party. This would be a new threat caused by
SAVI itself.
(21) If binding anchors are personally identifying or stable over
time or location then recording those creates new threats for tracking
the user or host associated with the binding anchor. That needs to
be noted.
(1) 2nd para of overview says that there is "typically no required transactional state when communicating with other hosts on the network." I think it'd be good to say why that's the case, via a reference to something. (Not sure what reference is best exactly.) (2) What is a "better Internet participant"? It sounds like a scary thing. (3) s/This both that the information be useable/This requires both that the information be useable/ (4) I expected to see some CVE references in section 3 but didn't see any. I'd encourage adding some of those for each of the threats covered since that should help motivate the work and would demonstrate that there are real threats to mitigate. (E.g. a quick search on "CVE spoofed source" throws up a bunch.) To take one example, 3.1.4 could do with such a reference. (5) Expand "LAND" (6) The DNS attack described around the top of page 9 isn't relevant to SAVI, right? Maybe the smurf attack is enough there. (7) Do 3.1.6 and 3.1.7 really fit in 3.1? (8) Do *all* CMTS employ DOCSIS? 4.1.5 says that they do. (9) Even IPsec doesn't unquestionably verify source address if load-balancing is in place with private key sharing.
I found this document to be very informative about the problem space. I think this document could have been far more effective if the text didn't meander around the points it was trying to make; it could habve been far more succinct. Here are some suggestions that I think could improve the document. 1) I find the following ambiguous, "the operational staff needs to be able to track from the IP address sourcing the attack to the particular machine within the enterprise that is the source. " I think the intention is that "the IP address sourcing the attack" means the spoofed address, and "that is the source" means the actual sending machine, but I'm not sure. This can be read as "the staff needs to track from the source to the source." 2) This sentence doesn't parse properly, "This both that the information be useable ..." I think the sentence is missing "means" or "requires" or something. 3) The glossary should include references to the defining documents. 4) "or order to disrupt" -> "in order to disrupt" 5) 3.1.3 doesn't describe what a poison attack is. It also refers to "the same kinds of poisonings as above", but above never spoke of poisoning attacks. 6) the following seems a bit perverted logic - a malware attack is important because it is a justification for SAVI? "This attack is important both in terms of an attack vector that SAVI may help prevent, and also as a problem which SAVI can help track back to find infected systems. " Shouldn't you be arguing that savi is important for preventing these types of attacks? 7) section 3.2.2 "Another example of sighted attack" - this is the first mention of "sighted attack". Please use consistent terminology. 8) in section 3.2.2, "The use of spoofed addresses, while not necessary for this, can often provide additional information, and helps mask the traceability of the activity." would seem to be the conclusion of the paragraph, but this precedes the discussion of what the attack is. 9) in scetion 4, "the first requirement" isn't followed by any further requirements. and is this section going to describe the requirements or the solutions? 10) "The IP source address is appropriate for the lower layer address (they both identify the same system)". I find "is appropriate" too ambiguous, although the following parethetical text explains it. I suggest this would be better written as "the IP source address and the lower layer address both identify the same system." 11) "The IP source address is appropriate for the device at the layer 2 switch port" I find "is appropriate" too ambiguous. " (the address was assigned to a, and perhaps the, system that uses that port) " doesn't parse appropriately. I think this bullet needs a better description. 12) section 4.1.1 "Port identification prevents transmission of malicious datagrams" Is thistrue? or is port identification one method that can be used to help prevent transmission? 13) 4.1.3 "An obvious special case of the discussion is with an ISP PE router, " - what discussion? This section seems based on speculation about possible solutions, including contract negotiations. I think this would be much better if it actually focused on technical solutions for validating addresses for ISP edge routers. 14) 4.1.4 again discusses business agreements between two conpanies. Please focus on ***technical*** solutions at this topological location. 15) 4.1.4 "However, when it can be shown that spoofed addresses are present, the procedure can be applied. " what procedure? 16) 4.2.5 is entitled residual attacks, but there is no discussion of residual attacks in the paragraph. The hand-waving contained in the paragraph doesn't seem worth documenting. 17) why is 4.2.5, "residual attacks", included in section 4 "Current anti-spoofing solutions"? 18) 5.2.6 what does "proper member" mean? where is this defined? 19) 5.2.7 - doesn't this sum up the whole section 5? since it includes anything not covered in 5.1 or 5.2, shouldn't this be 5.3? 20) is 5.3 about topological challenges? it seems to meander on about additioonal capabilites, rather than discussing the topological challenge to SAVI.
The Gen-ART Review by David Black on 12-May-2011 lead to a discussion
with one of the authors. At the end of the discussion, several
changes to the document were agreed. However, those changes have
not been made.
I find the document comprehensive but I share DBH's observation that it's a
little too verbose and could use some fixes in the details.
Beyond what he found I have a few more observations. None is critical for this
informational document, but cleaning up all these text unclarities in a new
version would be recommended;
1. In the Glossary section
NNI Router: Network to Network Interface Router. This router
interface faces a similar system operated by another ISP or other
large network.
I think that the definition should read something like 'A router with interfaces
facing a similar system ...'
2. Section 4.2.3.3
IEEE 802.1x is an authentication protocol that permits a network to
determine the identity of a system seeking to join it and apply
authorization rules to permit or deny the action. In and of
themselves, such tools confirm only that the user is authorized to
use the network, but do not enforce what IP address the user is
allowed to use. It is worth noting that elements of 802.1x may well
be useful as binding anchors for SAVI solutions.
This is quite confusing. IEEE 802.1X is a port (in the sense of bridge or layer
2 switch) access control standard that controls the joining of devices to a
layer 2 bridged network. The term 'tools' is not in place and there is nothing
about the 'user' in the protocol itself but about the device - the standard uses
the term 'supplicant' which is rather the device or the piece of software
running on the device that presents credentials to an authenticator.
3. In section 5.2 'hosts connected to switch ports that may have one or more IP
addresses' is probably rather 'hosts that may have one or more IP addresses
connected to (layer 2) switch ports'
Please expand "DoS" on first use and add an informational reference to RFC 4732.
draft-giralt-schac-ns
(1) Some examples would be nice. (2) https://urnreg.terena.org/ doesn't seem to currently have anything very human readable. Be good to fix that before the RFC issues.
#1) I followed the MACE link and got a 404 error. Maybe this one instead:
http://middleware.internet2.edu/urn-mace/
or you could point to RFC 3613?
#2) Sec 2: I compared the SCHAC-NSS and MACE-NSS. The only difference is as
follows:
MACE-NSS = 1*(subStChar) 0*(":" 1*(subStChar))
SCHAC-NSS = 1*subStChar *( ":" 1*subStChar )
I assume they evaluate to the same thing?
#3) A couple of nits on the last paragraph of Section 3:
... sites offering credentials signed by a community recognised
^ SCHAC-community
Certificate Authority (CA) and that WILL require the latest secure
^ion ^^^^will
methods for accessing a web site, that currently being HTTP [11] over
the latest version of TLS [12].
Normally, I'd say point to RFC 2818 for HTTP over TLS (i.e., HTTPS), but I guess
you might be trying to make people use TLS 1.2? What about the following:
In order to guarantee the validity and origin of SCHAC-NSS URN
values, they MUST be published over https links [11]. The https links
MUST be secured by sites offering credentials signed by a SHAC-community
recognised Certification Authority (CA) using the latest secure
methods for accessing a web site, that currently being the latest
version of TLS [12].
Replace [11] with 2818 instead of 2616 because 2818 points to 2616.
#4) Because of the MUST(s) in the last paragraph references [11] and [12] are
now normative.
draft-haleplidis-forces-implementation-experience
2. NAT issues. ForCES can be deployed everywhere and can run over
SCTP/IP. In order for the FE and CE to work behind NATs you must
ensure that the TML ports are forwarded and that the firewall
allows SCTP through.
This seems to be mixing NAT and firewall issues. Clearly, support NATs
requires for those NATs to be capable of handling SCTP traffic to begin
with. In addition, firewalls may have to be configured to let the traffic
through.
I found Section 3.3 very hard to understand for someone who is not
closely familiar with the Forces technology.
I don't understand why we need sections that talk about very generic topics,
like 3.4.2 that describes how to decode a protocol message.
And maybe more generally, I'm not sure what I learned from this document
in terms of real forces implementation experience. Where are the difficult
areas? Is the spec broken in places? Are there interoperability problems?
Is further work needed in some issue?
Developers of ForCES FEs and CEs should take the security considerations of the Forwarding and Control Element Separation Framework [RFC3746] and the Forwarding and Control Element Separation Protocol [RFC5810] into account. Why is this a should and not a must?
In this text: 3.3. Model The model inherently is very dynamic. What "model"? The Forces data model? More generally, I agree with Jari's comment about the content of the document. I learned a little about potential issues in implementing the struct component (but no details). Are there any other major implementation issues aside from struct components and handling protocol messages?
s/difficulty lie/difficulty lies/
The Gen-ART Review by Francis Dupont on 9-May-2011 suggested several editorial changes. Please consider them.
draft-hoffman-alt-streams-tracker
The Independent stream need a rejected (sub)state.
The "no longer in ISS" state as it stands seems to leave open the posibility of
a DOS attack by resubmitting the same text.
ISE "On hold" looks like it needs a sub state to deal with the case where it is
desirable to sequence a WG document ahead of an ISE document but otherwise there
is no objection.
There should be a security note stateing that putting April 1st IDs in the tracker would be damaging to their purpose.
I intend to ballot "Yes" on this document. However, as discussed within the
IESG, this document needs some text making it clear that the IETF Data Tracker
is not (or, upon approval of this document, will not be) limited to the IETF
stream. I suggest adding the following note after the third paragraph of the
Introduction.
Note: The term "IETF Data Tracker" is used as a generic name for
the existing tool used to track state changes as Internet-Drafts are
processed before hand-off to the RFC Editor. The word "IETF" in
the name "IETF Data Tracker" is not meant to limit use of the tool
to the IETF document stream; this document expands use of the
tool to the other streams described in [RFC4844].
Section 7 should be filed as a bug against the tracker and be removed from this
draft before publication as an RFC.
The intent of this document (and the other recent tracker requirements document)
is to inform an initial development effort. I don't believe they were intended
to stand as the requirements against a running tracker, being updated frequently
and gathering errata. It would probably help to say that explicitly.
Specifically, I don't think it's a good idea to have to update the RFC this
becomes to change the Subject line or contents of a notification email. Further,
I don't think updating this RFC (or the related ones) is the right tool to use
to refine the states defined in the tracker as experience with them tells us we
need new ones.
It would help to explicitly state that a document can't be in more than one stream at the same time. In particular, it can't be in the Candidate/Submission received states of more than one stream at the same time. It would probably be useful to the implementer to call out this includes the streams not covered in this document.