IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2010-09-23. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: Ralph
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
a=fec-source-flow:<source-id>; tag-len=0 a=fec-source-flow:<source-id>; tag-len= a=fec-source-flow:<source-id>
[...] fec-encoding-id = "encoding-id=" enc-id enc-id = 1*DIGIT ; FEC Encoding ID
[...]
separator = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
[...]
separator = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
repair-window-line = "a=repair-window:" window-size [unit] CRLF" window-size = 1*DIGIT unit = ms / us
unit = "ms" / "us"
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
Telechat:
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
Telechat:
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
3.2.2 Returning Items
Telechat:
3.3 Independent Submissions Via RFC Editor
3.3.1 New Items
Telechat:
3.3.2 Returning Items
1305 EDT break
1309 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
Telechat:
Telechat:
4.1.2 Proposed for Approval
Telechat:
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
Telechat:
Telechat:
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1414 EDT Adjourned
(at 2010-09-23 07:29:34 PDT)
draft-ietf-fecframe-sdp-elements
Please correct the use of ', |, HT from the ABNF, and remove any
duplication.
> If the FEC scheme does not require any specific
> information, the 'ss-fssi' and 'fssi' parameters MAY be null and
> ignored.
The ABNF allows both leaving these constructs out completely, or
specifying them without any elements. Which one, or either one do
you mean here? Please clarify.
Capitalization of udp/fec needs to be consistent throughout the
spec.
These issues came up in a review by Ari Keranen:
4.5. Repair Flows
sender-info = [ element *( ',' element ) ]
Shouldn't use "'" character in ABNF (same problem in multiple places)
separator = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
Should use "/" instead of "|" for alternatives. Should use "HTAB"
instead of "HT"?
Rules element, name, token, value, and separator are defined twice.
If the FEC scheme does not require any specific
information, the 'ss-fssi' and 'fssi' parameters MAY be null and
ignored.
By "be null" do you mean "not exist" or something else?
6.1. One Source Flow, One Repair Flow and One FEC Scheme
m=application 30000 udp/fec
change "udp/fec" into "UDP/FEC" to be consistent with sec 4.1.
Concerned that ABNF doesn't validate.
NITS
== Outdated reference: A later version (-10) exists of
draft-ietf-fecframe-framework-09
== Outdated reference: draft-ietf-mmusic-rfc4756bis has been published as
RFC 5956
== Outdated reference: draft-ietf-mmusic-sdp-capability-negotiation has
been published as RFC 5939
ABNF doesn't validate.
Section 4.6., paragraph 3: > can be adjusted if there are mising packets at the beginning of the Nit: s/mising/missing/
A couple of places in the text refer to "instances of the FEC Framework" (see Abstract, 3.3, etc.). I have trouble understanding this phrase. Can you instantiate a framework or an architecture? Or do you need to name a functional element that is instantiated?
I have several issues with the document I would like to discuss before
recommending its approval:
1) 4.1. Transport Protocol Identifiers
This specification defines a class of new transport protocol
identifiers for SDP media descriptions. For all existing identifiers
<proto> (listed in the table for the 'proto' field in the Session
Description Protocol (SDP) Parameters registry), this specification
defines the identifier 'FEC/<proto>'. This identifier MAY be used as
the transport protocol identifier in the media descriptions for the
source data to indicate that the FEC Source Packet format defined in
Section 5.3 of [I-D.ietf-fecframe-framework] is used, where the
original transport payload field is formatted according to <proto>.
Should 'FEC/<proto>' be registered in the Section 8.1?
2) 4.4. Source Flows
fec-source-flow-line = "a=fec-source-flow:" source-id
[";" SP tag-length] CRLF
source-id = "id=" src-id
src-id = 1*DIGIT
Any upper limit on src-id values? E.g. can I put a 128 bit unsigned value here?
Are leading zeros allowed here?
The same issue applies to tlen, enc-id and preference-level-of-the-flow [Section
4.5]
and window-size [Section 4.6].
tag-length = "tag-len=" tlen
tlen = *DIGIT
So, this (together with the definition of "fec-source-flow-line") allows for:
a=fec-source-flow:<source-id>; tag-len=0
a=fec-source-flow:<source-id>; tag-len=
a=fec-source-flow:<source-id>
Are all 3 representations equivalent?
If yes, why to allow all three?
3) 4.5. Repair Flows
[...]
fec-encoding-id = "encoding-id=" enc-id
enc-id = 1*DIGIT ; FEC Encoding ID
I think allowed values are from 0 to 255. If that is correct, it would be
good to at least say that in the ABNF comment.
[...]
separator = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
Note that this is not using the correct ABNF delimiter for alternatives
(should be / instead of |).
[...]
separator = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
As above.
4) 4.6. Repair Window
repair-window-line = "a=repair-window:" window-size
[unit] CRLF
window-size = 1*DIGIT
unit = ms / us
This is not correct, I think you are missing <">, i.e.
unit = "ms" / "us"
[Comment] Dave Cridland pointed out in his APPS Area Review that
this allows for too many choices. Would it be possible to
at least eliminate 1 of them (e.g. by making "unit" not optional,
or removing some of the choices from the "unit" itself).
5) From Dave Cridland's APPS Area Review:
In the Security Considerations section:
There is advice that "It is RECOMMENDED [to] follow the security
considerations of SDP". I would have thought that following those
recommendations would be a requirement. I'm quite taken with using
both RECOMMENDED and SHOULD in the same sentence, mind, but I think
this could be phrased better.
4.5. Repair Flows If the FEC scheme does not require any specific information, the 'ss-fssi' and 'fssi' parameters MAY be null and ignored. The last sentence: does this mean that these parameters can be omitted? If yes, I suggest you rephrase to just say that.
Why did you go with <proto>/FEC for the protos in the SDP parameters registry,
but FEC/UDP for UDP (as opposed to UDP/FEC)? (I'm not necessarily suggesting a
change)
In the ABNF, where are CHAR and CTLs defined? The productions that use them
could be cons
tructed more formally. Across all the added attribute lines, the
use of SP is inconsistan
t and that has led to interoperability problems with
other fields. Is there a reason not
to allow SP around any of the separators?
For instance, is it intentional that you aren't
allowing whitespace in the
repair-window-line?
Is allowing an empty production of preference-level-of-the-flow really what you
meant?
Similarly, did you really mean to allow an empty production for scheme-
info?
a=fec-repair-flow: encoding-id=314159265358979323844; preference-lvl=;
fssi=
Section 3.3 copies text from -framework. Would a pointer be sufficient? It would certainly be easier to maintain should these documents ever be revised. In the Security Considerations section: It is RECOMMENDED that you SHOULD is redundant.
1) Sec 4.5: Maybe add a reference to where the registration procedures are:
These identifiers MUST be registered with IANA by the FEC schemes that use the
FEC Framework [I-D.ietf-fecframe-framework].
2) as pointed out in the SECDIR review:
5.1. Declarative Considerations
In multicast-based applications, the FEC Framework Configuration
Information pertaining to all FEC protection options available at the
sender MAY be advertised to the receivers as a part of a session
announcement. This way, the sender can let the receivers know all
available options for FEC protection. Based on their needs, the
receivers MAY choose protection provided by one or more FEC Framework
instances and subscribe to the respective multicast session(s) to
receive the repair flow(s). Unless explicitly required by the CDP,
--> the receivers SHOULD NOT send an answer back to the sender specifying
their choices since this can easily overwhelm the sender particularly
in large-scale multicast applications.
Why not "MUST NOT" instead of "SHOULD NOT"? When would a receiver ever
want to send an answer back to a multicast sender?
draft-ietf-fecframe-framework
Ari Keranen asked about this:
5.6. FEC Scheme requirements
3. The name, type, semantics and text value encoding rules for zero
or more FEC Scheme-specific FEC Framework Configuration
Information elements. Names must conform to the "name"
production and values encodings to the "value" production defined
in Section 5.5
What text in the section 5.5 defines these productions? Or do you mean
the text "where the valid element names and value ranges are defined by
the FEC Scheme"? If so, it could be better to simply state it here
rather than reference to section 5.5.
Also, you probably mean "value encodings" instead of "values encodings"?
The term "ADU" is not defined until Page 9, but is used many times before this point in the document. It would assist the reader if it were defined earlier in the document.
Thanks for this document.
I have a Comment that might generate a substantial piece of work for
you. I do not feel strongly enough to enter a Discuss, but it would be
great if you thought about it and maybe added to the document.
It would be helpful, I think, if a framework/architecture like this
included a discussion of how the systems and networks described are
operated and managed. You might look at RFC 5706 for guidance.
--
I have a cople minor comments about Section 8
The authors of this draft are primarily interested in applications
s/draft/document/
We propose a third approach, which is to require at a minimum that
the use of this framework with any given application, in any given
environment, does not cause congestion issues which the
application alone would not itself cause i.e. the use of this
framework must not make things worse.
This is a Standards Track document. s/propose/define/
The Gen-ART Review by Joel Halpern on 19-Sep-2010 raised an issue
that ought to be addressed:
Section 5.6 says: "Names must conform to the "name" production and
values encodings to the "value" production defined in Section 5.5".
However, section 5.5 says that valid element names and value ranges
are defined by the FEC scheme. There are no productions for these
fields in section 5.5.
Please consider comments from the Gen-ART Review by Joel Halpern on 19-Sep-2010: The text in section 8 seems to imply that cellular devices experience high loss rates. This is misleading, as radio protocols generally provide sufficient flow control and retransmission so as to bring the link behavior to levels similar to that of other media. Please either recheck the assumptions being made, or consider removing the reference to cellular links. The definition of Application Data Unit should include an indication that this is referred to as an ADU.
I have only one issue I would like to discuss before recommending approval of
this document:
Section 5.6 says:
3. The name, type, semantics and text value encoding rules for zero
or more FEC Scheme-specific FEC Framework Configuration
Information elements. Names must conform to the "name"
production and values encodings to the "value" production defined
in Section 5.5
I am looking at section 5.5 and not seeing any definitions of "name" and "value"
there. If you intended to point to
ABNF in [I-D.ietf-fecframe-sdp-elements]
then it would be better to have a direct reference.
But anyway, maybe the text in 5.5 referenced in 4.6 is:
FEC Scheme-specific information elements MAY be encoded into a text
string for transport within Content Delivery Protocols. See Section
4.5 of [I-D.ietf-fecframe-sdp-elements] for the ABNF [RFC5234]
syntax.
But this would at least mean that [I-D.ietf-fecframe-sdp-elements] needs to be a
Normative reference.
I would like to raise the issue raised by Adrian to a DISCUSS - such a document
is expected to include information about operational impact and manageability of
devices and networks that will compy to the framework, also indication about
what kind of operations and manageability information future specifications of
protocols that comply to the framwork would include. This document includes no
such information. I would like to discuss this in the call, maybe these issues
are covered in other fecframe documents, or future work planned by the WG.
Section 8 states:
We propose a third approach, which is to require at a minimum that
the use of this framework with any given application, in any given
environment, does not cause congestion issues which the
application alone would not itself cause...
Yet a subsequent paragraph states:
One of the constraints effectively limits the bandwidth for the
FEC protected packet stream to be no more than roughly twice as
high as the original, non-FEC protected packet stream.
How can a FEC-protected packet stream not cause congestion issues if it uses
twice as much bandwidth as the non-FEC-protected packet stream?
In the section on congestion control, the document says "the use of this
framework must not make things worse". It then recommends that the bandwidth of
the repair stream be limited to the bandwidth the original application data
would have taken if the framework weren't used (did I read this right). I also
see the expectation that the source data will usually look like what the
application data would have looked like plus an ID (hence a little larger). So
if I've read this right, the intent is to limit the bandwidth of the protected
stream to around twice the bandwidth of what the unprotected application data
would have taken. If that's right (or even more if it isn't), it should be
stated more clearly.
Is it possible to add some text explaining how twice-the-
bandwidth was arrived at and how this satisfies "must not make things worse"?
There is some text that talks about protecting MIKEY with this framework. I'm
not seeing how that would help. Maybe a clearer applicability statement would
help? Is there text in the document that disuades attempting to protect DNS over
UDP (or is there a way to apply the framework to application data like that?)
There are a couple of places where the document requires (at MUST strength)
using consecutive values starting at 0 for a field. It would help to more
clearly say why, and to be explicit that receivers don't care if they see things
with gaps or reordering.
2nd paragraph of section 6 is mostly one sentence that is very hard to read.
This point is only to stimulate discussion on the telechat: The group's charter
calls out some specific technology (RFC3269 and 3452) that on a quick review
does not seem to be reflected here.
A couple of security related points I'd like raise before approving this
document:
1) The draft is silent wrt a mandatory to implement algorithm. I think this
draft needs to be clear that a) it purposely didn't pick a mandatory to
implement algorithm b) the applications MUST pick one.
2) In Sec 9, I'd like to see a discussion which differentiates the various
security requirements of interest:
- security WRT the data flow itself,
which essentially
concerns the content provider;
- security WRT the
FECFRAME system, which essentially
concerns the sending and receiving
hosts;
- security WRT the network, in the sense "additional
risks that
the use of FECFRAME may create for the
network", which of course concerns
all the hosts.
3) In Sec 9 penultimate paragraph, the paragraph should be reworked:
- if integrity protection is required, using it above
FECFRAME, at the ADU level, is operational since all
corrupted ADUs are finally detected as such. But of
course there are limits (e.g. DoS as already
explained).
- if integrity protection is required, using it below
FECFRAME has the advantage of reducing DoS risks.
This is therefore RECOMMENDED.
- however when applied below FECFRAME, this integrity
service will not necessarily be end-to-end (depends
on how FECFRAME is used, end-to-end or not). Whether
it's appropriate or not depends on whether one can
tell where the security threats are (which is
use-case dependent).
4) Sec 9 last paragraph: Please rework the paragraph as follows:
- when ADU flows with different security requirements
need to be FEC protected jointly, then each flow MAY
be processed appropriately before entering FECFRAME
e.g. to encrypt it.
(Note that this is not a MUST. E.g. there are situations
where the only insecure domain is the one over which
FECFRAME operates => this situation may be addressed
with IPsec/ESP, for the whole flow)
- it is then REQUIRED that the FECFRAME aggregate flow
be in line with the maximum security requirements of
the individual ADU flows. E.g. if DoS protection is
required, since the use of FECFRAME must not add any
additional threat, an integrity protection must be
provided below FECFRAME.
- generally speaking it is often RECOMMENDED to avoid
FEC protecting flows with largely different security
requirements.
5) Sec 9, last paragraph: Add IPsec as a mechanism to provide confidentiality in
the last paragraph. Also note that certain security transforms will add some
latency to the ADU flow delivery. This latency may need to be considered when
dealing with real-time flows.
6) Sec 9, new last paragraph: Text should be added to highlight the fact that
attacks targeting the congestion control building block (when applicable) may
severely damage the network. A pointer to section 8 should be added.
Sec 9, penultimate paragraph: Add informative reference for IPsec in 2nd to last paragraph.
draft-ietf-eai-frmwrk-4952bis
Thank you for this very clearly and concisely written document. I have only a few minor editorial comments: Section 7.1: s/left hand part/local part/ and right hand part/domain part/ for consistency with convention elsewhere in the document? Also in section 7.1: is US-ASCII equivalent to ASCII and can US-ASCII be replaced by ASCII for consistency? It's not terribly important, but the rest of the document is written carefully enough that when I read "US-ASCII" I thought it might have some significance relative to ASCII as used throughout the rest of the doc. In section 10.1, what, exactly, are "EAI mailbox names"?
> Intended status: Informational
and
Section 5322, paragraph 3:
> Although this document is Informational, those
> requirements are consistent with requirements specified in the
> Standards Track documents in this set as described in Section 5.
DISCUSS: The datatracker has this going for PS. Which is correct?
The Gen-ART Review by David Black on 10 Sep 2010 raised several
issues. The authors seem to agree that changes are appropriate,
but a revised Internet-Draft has not been posted yet.
There was a brief discussion amongst the IESG about the intended status before
IETF Last Call, which seemed to
support Informational Status. However, the
document was Last Called for PS and is on the telechat for PS. I
would like to
discuss why the sponsor feels standards track was the correct choice.
The phrase "this document" is used in a confusing manner in the first two
bullets of section 5. For example,
bullet 1 reads
o SMTP extensions. This document [RFC5336bis-SMTP] provides an SMTP
extension (as provided for in RFC 5321) for internationalized
addresses.
However, "this document" refers to the referenced specification [RFC5336bis-
SMTP] rather than this document
(the framework). Perhaps the clause could be
deleted in both bullets. Then bullet 1 would read:
o SMTP extensions. [RFC5336bis-SMTP] provides an SMTP
extension (as provided for in RFC 5321) for internationalized
addresses.
p21: s/Expecting and most/Expecting most/
Thank you for this clear, well-written document. Several sentences struck me as
difficult to parse...
1. In Section 8.1:
It is likely that the most common cases in which a message that
requires these extensions is sent to a system that does not will
involve the combination of ASCII-only forward-pointing addresses with
a non-ASCII backward-pointing one.
I suggest:
Sometimes a message that requires these extensions is sent to a
system that does not support these extensions; tt is likely that the most
common cases will involve the combination of ASCII-only forward-pointing
addresses with a non-ASCII backward-pointing one.
2. In Section 10.1:
While these
are permitted by the protocols and servers are expected to support
them and there are special cases where they can provide value, taking
advantage of those features is almost always bad practice unless the
intent is to create some form of security by obscurity.
I suggest:
These formations are permitted by the protocols and servers are
expected to support them. Although they can provide value in special
cases, taking advantage of them is almost always bad practice unless
the intent is to create some form of security by obscurity.
3. In Section 10.1:
o In general, it is wise to support addresses in Normalized form,
using either Normalization Form NFC and, except in unusual
circumstances, NFKC.
Is the intent to say that it is best to use NFC and to use NKFC only in unusual
circumstances?
4. In Section 11.1:
The mailto: schema [RFC2368] and discussed in the Internationalized
Resource Identifier (IRI) specification [RFC3987] may need to be
modified when this work is completed and standardized.
I suggest:
The mailto: schema, defined in RFC 2368 [RFC2368] and discussed
in the Internationalized Resource Identifier (IRI) specification [RFC3987],
may need to be modified when this work is completed and standardized.
5. In Section 12:
The key architectural difference between the
experimental specifications and this newer set is that the earlier
specifications supported in-transit downgrading including providing
syntax and functions to support passing alternate, all-ASCII,
addresses with the non-ASCII ones and special headers to indicate the
downgraded status of messages.
Yes, "downgrading including providing" is impressive, but I suggest:
The key architectural difference between the
experimental specifications and this newer set is that the earlier
specifications supported in-transit downgrading, which included the
definition of syntax and functions to support passing alternate, all-ASCII,
addresses with the non-ASCII ones as well as special headers to
indicate the downgraded status of messages.
6. In Section 14:
Expecting and most or all
such transformations prior to final delivery be done by systems that
are presumed to be under the administrative control of the sending
user ameliorates the potential problem somewhat as compared to what
it would be if the relationships were changed in transit.
I suggest:
This potential problem can be mitigated somewhat by enforcing the
expectation that most or all such transformations will be performed
prior to final delivery by systems that are presumed to be under the
administrative control of the sending user (as opposed to being
performed in transit by entities that are not under the administrative
control of the sending user).
Finally, a reference to RFC 5280 seems appropriate in Section 14 when
mentioning PKIX.
draft-ietf-mext-nemo-pd
I think the Abstract and, in particular, the Introduction need a little
work. Neither of them says what this document is, what it contains, or
why I should read it. The Introduction, which is no more than the
Abstract with citations should also set some scenery. Probably a couple
of paragraphs from section 3?
---
According to Section 2, [I-D.ietf-mext-rfc3775bis] and [RFC4885] are
normative references.
---
Section 3.3
s/must/MUST/ ?
---
Section 4
While the MR
is away from home, the IPsec security mechanism mandated by MIPv6
MUST be used to secure the DHCPv6 signaling.
I think this needs a reference to the MIPv6 document that mandates IPsec
There are a bunch of places where references are not given as citations. s/RFC3775bis/[I-D.ietf-mext-rfc3775bis]/ s/RFC 3315/[RFC3315]/ s/RFC 3633/[RFC3633]/ --- Nit: Section 3.1 Suddenly you use "Delegating Router" --- Nit: MIPv6, HoA, and CoA are used without explanation. BU is used without explanation (you can fix this a couple of lines earlier) --- Section 7. I love the use of RFC 2119 language :-)
Please consider the comments in the Gen-ART Review by Miguel Garcia on 17-Sep-2010.
I think that [I-D.ietf-mext-rfc3775bis] should be a Normative reference,
considering some cases how it is referenced (search for "rfc3775bis" - sometimes
used without a proper reference).
I found the document to be hard to read. Maybe because it is starting to use acronyms without always expanding them first.
in 3.3 paragraph 2 sentence, should "DHCPv6" be "DHCPv6PD"? Current sentence
is:
However, an HA may choose not to respond to the Solicit
messages from the MR because the HA does not provide DHCPv6.
In section 4 paragraph 3 theer is some awkward wording. Suggestion:
OLD
We use the same format than that used by of [RFC4877].
NEW
We use the same format used by [RFC4877].
Some other editorial issues were identified in Donald Eastlake's secdir review:
Section 3.1, page 5, "...currently used by the is about to expire..."
? perhaps "...by the Mobile Node..."
"an Mobile" -> "a Mobile"
Various acronyms, such as BU, HoA, while usually explained when first
used, are missing from Section 2. HoA is not explained at all. Even
better would be to vastly reduce the overuse of acronyms throughout
this document.
The OPS-DIR review by Jouni Korkonen raised a number of issues that require
clarification - please see them listed below, the first two are included in the
DISCUSS, the third is a (valid) editorial clarification, so I placed it in the
COMMENT.
1. In Section 3.1 the MR has two DHCPv6 functions: 1) client and 2) relay.
During the operation described in Section 3.1 the MR internal DHCPv6 client
sends a message to MR internal DHCPv6 relay using some goofy method (which is of
course not described). If I understand it correctly all this is to please
RFC3315, which does not allow a client to start DHCPv6 exchange directly using
DHCPv6 server's unicast address before the server has sent a OPTION_UNICAST to
the client. Is this correct? If not, go to 2nd comment.
If yes then.. while the attempt would be humble not to break existing RFCs I
find it ridiculous. Especially when in Section 3.3 it is stated that DHCPv6
server (which is always collocated in HA) implementation has to be modified
anyway. Then why to see the trouble on the MR side having the client-relay
workaround, which presumably still needs some MR side modifications to work
anyway (like the undefined client-relay communication and running two DHCPv6
instances in the same box)? Just accept the fact that this would work better in
Section 3.1 case having the DHCPv6 client in MR send an unicast message to the
DHCPv6 server in HA. Both MR & HA side DHCPv6 implementations are not off the
shelf implementations anyway and always collocated with MR/HA.
(We recently had a similar case when trying to get DHCPv6 working over existing
unmodified 3G network. because we had to add new options to DHCPv6 client and
get it running over PPP interface, we made also a small modification to the
client to send messages to server's unicast address. At the same time we made a
trivial change in the server to accept unicast messages. That we could justify &
accept in a special case we had i.e. no desire to run relay+client combination
on the end host, no site-scoped multicast support and client & server were
always at the ends of point to point links.)
2. Is the solution designed or supposed to work if a node behind the MR
initiates a DHCPv6-PD exchange? I would like to see some text what happens when
a MR receives a DHCPv6-PD request from one of its downstream interfaces (as
there is a relay in MR).
I would state more clearly that explicit mode is not supported if DHCPv6-PD is going to be used. Current text is Section 3.1 says it in a way but the wording like: delegation. Since the MR may not have yet requested any prefixes, implicit BU signaling MUST be used. While using the NEMO Basic Support protocol with DHCPv6PD, implicit BU signaling is the default mode of operation. ..leaves room for interpretation that the MR may start in explicit mode and then still request for more prefixes usinf DHCPv6-PD. Is this correct?
draft-ietf-tcpm-urgent-data
This is GREAT document, thank you for writing it. I am reading
it very carefully due to the importance of the Updates clause.
With this in mind, please consider the following:
As discussed in Section 1, the TCP urgent mechanism simply permits a
point in the data stream to be designated as the end of urgent
information, but does NOT provide a mechanism for sending out of band
data.
As far as I can tell, Section 1 does not discuss this. The intended
semantics of the urgent mechanism are also a crucial point for the
changes suggested in this document, so I hope to see a clear reference
and a rock solid explanation why this the case. That being said,
I think the matter is pretty clear, given that there is no start
pointer for the urgent data. However, RFC 793 confuses this a bit by
saying:
If the sending user also indicates a push, timely delivery of
the urgent information to the destination process is enhanced.
whereas in reality all data up to and including the urgent information
gets a higher priority treatment.
I have no comments on the rest of the contents of the document. However,
I think the document is lacking in two respects. First, as far as I can
tell, it does not describe the problems (if any) that result from a
different interpretation of the pointer and other semantics on the two
endpoints. Second, if there are significant problems, perhaps all the
evidence from this document should be taken as an indication that urgent
data is simply not used in the Internet (and might be deprecated). If
there are no problems, what's the fuss?
> This means that if this
> sysctl is set, an application might be unable to interoperate with
> itself if both the TCP sender and the TCP receiver are running on the
> same host.
Heh. Amusing, or perhaps a proof of the lack of real use.
Some questions from a review by Ari Keranen:
3.2. Semantics of the Urgent Pointer
[...] For example, Linux provides the sysctl
"tcp_stdurg" (i.e., net.ivp4.tcp_stdurg) that, when set, supposedly
changes the system behavior to interpret the semantics of the TCP
Urgent Pointer as specified in RFC 1122.
Since the Linux behavior may change later on, it would be a good idea to
note the version of the Linux with this behavior (same probably applies
to section 3.4 with Cisco PIX too). Maybe you could add a reference to
the related appendix with this info.
5. Advice to new applications employing TCP
As a result of the issues discussed in Section 3.2 and Section 3.4,
new applications SHOULD NOT employ the TCP urgent mechanism.
What about applications that supposedly do not use the urgent mechanism
but an attacker might use it against them? Should it be recommended for
all applications to always set the SO_OOBINLINE socket option to prevent
the attack described in [phrack]? Or perhaps recommend this to be made
the default in the kernels of the OSs -- even if they got it wrong the
first time.
This is a discuss-discuss. This sounds like a feature that never really worked.
Applications have been discouraged from using it for years. Many deployed middle
boxes defeat it.
Maybe a better approach would be to deprecate the feature and talk about
alternative methods of delivering urgent data (e.g. a separate TCP session for
urgent data only).
Section 2.1 (editorial): are "sending user" and "receiving user" typical terms in specifications of urgent data; do they imply human users? Would "sender" and "receiver" be more general? In section 3.2, I'm guessing "net.ivp4.tcp_stdurg" is a typo (ipv4?)
3.4. Interaction of middle-boxes with TCP urgent indications This should discourage applications from depending on urgent indications for their correct operation, as urgent indications may not be not reliable in the Did you mean "may not be *reliable*"? current Internet. <<Need to check Dave Cridland's SecDir/Apps review>>
This is a discuss-discuss. To be clear, I am not requesting any changes in the
document at this time. I would
like to discuss several issues before I either
clear or make this an actionable discuss.
(1) Given the content in the preceding sections, I was somewhat disappointed
with the scope of sections 4, 5 and 6.
Why did the wg choose not to update the
allowed length of urgent data, given that almost every implementation
supports
only one byte of urgent data? Even if the wg was not comfortable updating the
specifications in section 4,
wouldn't it be prudent to admonish applications not
to use this mechanism for more than a single byte in section 6?
Similarly,
section 5 reiterates that TCP implementations MUST support the urgent mechanism.
Do these implementations need to support urgent data of a single byte or "any
length"?
(2) I wonder why section 6 does not reiterate the closing text in 3.4: that
applications need to be designed for correct
operation even in the case where
the URG flag is cleared by middleboxes.
(3) I think the most important sentence in this document is the first sentence
of section 5:
"... new applications SHOULD NOT employ the TCP urgent mechanism."
Reading the Abstract and Introduction
provides no clue that such important
guidance is hidden within. Shouldn't this be highlighted?
(4) Last, but perhaps most important of all: given the guidance cited in (3),
did the wg consider making this a BCP?
While consistent with RFC 793, I found the references to "user" in section 2.1 (paragraphs 1 and 2) a little odd. Is this still the accepted terminology for TCP implementations?
1. Section 2.1 states: TCP incorporates an "urgent mechanism" that allows the sending user to stimulate the receiving user to accept some "urgent data" and to permit the receiving TCP to indicate to the receiving user when all the currently known urgent data have been received by the user. The phrase "have been received by the user" is ambiguous -- do you mean the sending user or the receiving user here? I would assume the receiving user, but it would be good to make that explicit. You could change "by the user" to "by the receiving user" or simply remove "by the user" at the end of the sentence.
draft-ietf-sip-session-policy-framework
I support Lisa's discuss: the draft seems to combine three quite separate things under the heading of "policy": 1. UAC retrieving information about what policies are being enforced. This is clearly useful so that UAC can avoid violating them, or can present more meaningful information why session failed. But it's also optional -- if the codec preferred by UAC is also allowed by the policy, then knowing the policy doesn't give you much extra. Or it could just do trial-and-error. 2. UAC retrieving settings, such as TURN server addresses. This seems quite different from "policies" (although like #1, it's something the UAC could also get by some other means, like manual local configuration). 3. UAC signalling various intermediaries (via the policy server) to set up state (like pinholes). This isn't just "retrieving policies" (or settings) any more -- this is a signaling protocol, and seems architecturally significantly different from #1 and #2.
Was waiting for response from RIM about IPR
I have some blocking issues with the document which I would like to
discuss/resolve before I can recommend approval of this document:
1)
4.4.1. UAC Behavior
The UAC MAY resend the unchanged request if it cannot setup a policy
channel to the policy server, for example, because the policy server
is unreachable or returns an error condition that cannot be resolved
by the UAC (i.e., error conditions other than, for example, a 401
(Unauthorized) responses). This is to avoid that the failure of a
policy server prevents a UA from communicating.
But the proxy will reject such requests again with 488, so what is the point?
To protect the integrity of the policy server URI in a Policy-Contact
header field, the UAC SHOULD use a secured transport protocol such as
TLS between UAC and proxy.
TLS needs an Informative Reference.
Similar text in Section 4.5.1:
4.5.1. Creation and Management
If setting up a policy channel to one of the discovered policy
servers fails, the UA MAY continue with the initiation of a session
without contacting this policy server. Setting up a policy channel
can fail, for example, because the server is unreachable or returns
an error condition that cannot be resolved by the UAC (i.e., error
conditions other than, for example, a 401 (Unauthorized) responses).
The UA SHOULD continue an ongoing session if a policy server fails
after the session has been set up. The UA SHOULD consider the
policies it has previously received from the failed policy server.
This is to avoid that the failure of a policy server prevents a UA
from communicating.
2)
4.4.2. Proxy Behavior
The proxy SHOULD remove the Policy-Id header field value of its
Why is this a SHOULD and not a MUST?
associated policy server from the Policy-Id header field before
forwarding the request. This value only increases message size and
is not relevant to other proxies on the path. It also would disclose
the policy server URI to subsequent proxies.
3)
4.4.3. UAS Behavior
A UAS can receive an INVITE, UPDATE or PRACK request (or another
request that can initiate offer/answer exchanges) that contains a
Policy-Contact header field with a list of policy server URIs. A UAS
that receives such a request needs to decide if it wants to accept
the session knowing that there are policy servers involved. If the
Policy-Contact header contains multiple URIs each with a different
URI scheme and containing an "alt-uri" parameter with identical
values these URI schemes represent alternative policy channel
mechanisms for obtaining the same policy. If the UAS accepts the
session, the UAS chooses one of any alternative URIs to use to obtain
the policy. The UAS MAY take as a hint the order of the alternative
URIs as indicating a preference as to which URI scheme to use. The
topmost URI schemes in the list might be more preferred by the domain
of the proxy for use to obtain the policy. The UAS MUST contact all
policy server URIs in a Policy-Contact header field that do not
contain an "alt-uri" parameter with identical values.
What happens if there are multiple groups of Policy servers, each using a
different
"alt-uri" parameter values? Is UAS required to contact at least one
Policy
Server in each group? If the answer is yes, then I don't think the text
as written actually say that.
4)
4.4.4. Caching the Local Policy Server URI
This section doesn't talk about the maximum cache validity limit. Is there any
limit?
5)
4.4.5.2. Policy-Contact Header Field
Policy-Contact = "Policy-Contact" HCOLON
*(COMMA policyContact-info)
This allows for a) empty Policy-Contact header field value and b) "Policy-
Contact:,..."
I think b) is an error and a) might not be intended. So I think
you meant something like:
Policy-Contact = "Policy-Contact" HCOLON
policyContact-info *(COMMA policyContact-info)
Also, are multiple Policy-Contact header fields allowed in a SIP message?
6)
4.5.1. Creation and Management
A UAC can receive a 488 (Not Acceptable Here) response with a Policy-
Contact header field containing a new policy server URI in response
to a mid-dialog request. This indicates that the set of policy
servers relevant for the current session has changed. If this
occurs, the UAC MUST retry sending the request as if it was the first
request in a dialog (i.e., without applying any policies except the
policies from the local policy server). This way, the UAC will re-
discover the list of policy servers for the current session.
But the UAC already has the list of policy servers in the 488 response
with a Policy-Contact header?
7)
4.5.1. Creation and Management
A UA MUST inform the policy server when a session is terminated via
the policy channel, unless a policy server indicates via the policy
channel that it does not need to be contacted at the end of the
session. This enables a policy server to free all resources it has
allocated for this session.
Can you elaborate on how this is done? I want to be sure that the MUST
is actually implementable.
8)
In Section 5:
Instead of removing a policy server URI, an attacker can also modify
the policy server URI and point the UA to a compromised policy
server. To prevent such an attack from being effective, it is
RECOMMENDED that a UA authenticates policy servers.
What are the reasons to violate the RECOMMENDED (i.e. why is this not a MUST)?
9) This document requires support for draft-ietf-sipping-config-framework.
However, draft-ietf-sipping-config-framework doesn't define any specific
configuration format. So I don't see how this can ever be implementable.
In particular, I see the following text in Section 4.5.2:
UACs usually contact a policy server twice during an offer/answer
exchange (unless a policy server indicates that it only needs to be
contacted once). Therefore the case of multiple policy servers
providing policies to a single UAC does not require additional steps
in most cases. However, a UAS usually contacts each policy server
only once (see Figure 4). If a session policy returned by one of the
policy servers requires that information is shared between multiple
servers and the UAS receives policies from more than one policy
server, then the UAS MUST contact all policy servers a second time
after contacting all servers the first time. Whether or not a second
round is required is determined by the type of information returned
by the policy server. The data format for session policies
explicitly states if a second round is needed for a particular data
element. If a UA supports this data format and receives such an
element, it knows that is expected to contact policy servers a second
time.
"URI" needs an Informative reference on first use (in Section 4.1)
The document states "[This specification] specifies a model, the overall architecture and new protocol mechanisms ..." in the introduction. Similar words are in the abstract. However, I can't find a model anywhere.
I support the issues raised by Lisa in her DISCUSS. I am also concerned by the statement in the protocol quality section of the annoucement that there are no implementations known for the mechanisms defined here. Actually in reality today SBCs implement session policies without mechanisms such as this. I am wondering whether Experimental would not have a more apropriate status for this document, but I will not block its approval on these reasons.
1. The description of session-specific policies in the introduction seems to
provide one justification for the specification:
Session-specific policies ... enable a network intermediary to
examine the session description a UA is proposing and to return a
policy specifically for this session description. For example, an
intermediary could open pinholes in a firewall/NAT for each media
stream in the proposed session description. It can then return a
policy for the session description that replaces the IP addresses and
ports of the UA with the ones opened in the firewall/NAT that are
reachable from external.
This kind of interaction seems more appropriate for a protocol like STUN or
TURN. Please add some text describing in slightly more detail how this is a
policy interaction and not a NAT traversal interaction.
2. The spec does not describe the impact of policy servers on user agents that
do not support the session policy framework; is it assumed that the addition of
policy servers to the SIP architecture will not degrade the user experience
because user agents that do not support the session policy framework will
experience session failure just as they always have? Adding at least some
discussion about the implications of modifying the SIP architecture would be
helpful in determining whether this specification helps or harms the Internet.
3. Section 4.4.1 states:
The Policy-Contact header can contain multiple URIs each with a
different URI scheme and containing an "alt-uri" parameter with
identical values. These URIs represent alternative policy channel
mechanisms for obtaining the same policy. The UAC chooses one of the
alternative URIs to use to obtain the policy. The UAC MAY take as a
hint the order of the alternative URIs as indicating a preference as
to which URI scheme to use. The topmost URI schemes in the list
might be more preferred by the domain of the proxy for use to obtain
the policy.
Is it the order of URIs that is significant, or the order of URI *schemes*?
4. Section 4.4.1 states:
In some cases, a request can traverse multiple domains with a
session-policy server. Each of these domains can return a 488 (Not
Acceptable Here) response containing a policy server URI. Since the
UAC contacts a policy server after receiving a 488 (Not Acceptable
Here) response from a domain and before re-sending the request,
session policies are always applied to a request in the order in
which the request traverses through the domains. The UAC MUST NOT
change this implicit order among policy servers.
How does the UAC determine the order in which the request traverses the domains?
5. Section 4.4.1 states:
The UAC SHOULD use the cached policy server URI to contact the local
policy server before sending a request that initiates the offer/
answer exchange for a new session (e.g., an INVITE request). The UAC
SHOULD NOT cache a policy server URI that is in a different domain
than the UAC even if it is the first policy server URI returned. The
first policy server URI returned can be from another domain if the
local domain does not have a policy server.
The meaning of "in a different domain" is undefined. Is this referring to the
DNS domain name of the right-hand side of the UAC's SIP address, an
administrative domain, or something else? If it is a DNS domain name, what
counts as "in" the domain?
6. Section 4.4.2 states:
More than one URI for the policy server using different URI schemes
MAY be provided by the proxy as alternative URIs to contact the
policy.
Does this mean that each alternative URI MUST have a different scheme, i.e.,
that there MUST NOT be more than one URI for each scheme?
7. Section 4.4.2 states:
The value used for the "alt-uri" parameter MUST be such that the same
value will not be included with other policy server URIs that a UA
needs to contact by any other proxy within the same domain or another
domain.
How can a proxy determine the full set of all "alt-uri" parameters that might be
provided by all policy servers along the path that the request might traverse?
Must the proxy ascertain that set (and remove any duplicates) before it can
offer any "alt-uri" parameters to the UA?
1. I support Alexey's DISCUSSes. 2. Section 3.2.1 states: A UA that supports session-independent policies compliant to this specification MUST attempt to retrieve session-independent policies from the local network and the SIP service provider domain, unless the UA knows (e.g., through configuration) that a domain does not provide session-independent policies. In this case, the UA SHOULD NOT retrieve session-independent policies from this specific domain. I think that the second sentence of that paragraph is meant to qualify the second clause of the first sentence. Thus I think it is meant to read as follows: A UA that supports session-independent policies compliant to this specification MUST attempt to retrieve session-independent policies from the local network and the SIP service provider domain, unless the UA knows (e.g., through configuration) that a domain does not provide session-independent policies (in which case the UA SHOULD NOT retrieve session-independent policies from this specific domain).
1) Please expand TLS on 1st use. 2) Add reference to TLS (i.e., [RFC5246]) in sections 4.4.1, 4.4.2, and 5 (x2). Also, add [RFC5246] as an informative reference.
draft-ietf-mip4-generic-notification-message
This is turning MIP into a reliable signaling protocol, which I think is a bad idea. I also don't understand how RFC3115 and RFC4917 aren't sufficient already.
There are plenty of usage scenarios listed in Section 3. But the document is very short of examples of what the notification might be used for (just a little in Seciton 5). I don't see any I-Ds in the working group proposing uses of this extension, and there is nothing referenced from this I-D. Are you sure that you haven't invented a protocol mechanism without any specific requirements? Will you be cluttering the protocol implementations with support for messages that will never be used? I note that the protocol write-up does not mention any implementations or plans for implementaiton. --- idnits says ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) --- Section 2 s/terms are/term is/ --- Section 4.3 needs to say when to give up retransmitting, and what to do with a GNAM that arrives for a GNM that was transmitted several retransmissions ago.
The authors have agreed to make several changes based on the Gen-ART Review by Sean Turner that was posted on 7-Sep-2009.
This protocol defines a semantic free messaging protocol. The problem with this is the semantics are derived from the payloads that it caries. This will result in several issues. 1) Lack of Interoperability: Different vendors will do different things. There is way for one vendor to find out what other vendors extensions or how they work as there is no requirement to register them in a standardized way. 2) Inappropriateness: Many of the things vendors do will not be and appropriate use of mip4. 3) Incorrectness: Many of the extensions will suffer from errors, security problems, race conditions, and other problems. This happens due to lack of review of payloads and constrains implied by the transport. These issues could be resolved with significant rework of the draft that moved it to have a way to negotiate payloads each side supported and preferred, a way of indicating if the payload was mandatory to understand or optional to understand. A way of upgrading from an early version of an extension to a later way. And finally a way of registering payloads that used IANA and was specification required.
I am on the edge of Abstaining on this document, due to its readability. The document is hard to read. Also it contains lots of duplicated text, so it is hard to verify if various sections of it consistent. 5. Future Extensibility This section needs to be edited for readability. 6. IANA Considerations This document describes two new messages, the GNM in section 4.1 and the GNAM in section 4.2. These two messages SHOULD be allocated from the same address space used by the Registration Request and Registration Reply messages in [RFC3344]. The subtype of these two messages indicate what kind of information is carried and will be under assigned by IANA namespace. The last sentence doesn't read well.
The new versions considerably improved the quality of the specification and I
thank the authors for the effort to address the IESG comments, including mine.
The changes in the last versions allow me to strike out the first two items on
my DISCUSS, however I did not find anything that addresses the third. If I
missed something please point me to the text changes or to the relevant
discussion
The remaining open issue: The specification is completely mute about the
management aspects of the notifications capability. At a minimum I would expect
that nodes and agennts expose a list of the supported notifications be
accessible to operators via some management interface, that there would be
switches to enable / disable notifications, and the capability to tune timers of
retransmission.
Henrik's given name starts with an H. not with an O. (front page)
Please consider adding text discussing how you envision: * Changing the requirements of a payload when it is revised. Are you anticipating abandoning the codepoint and using another, or will there be a way to talk about versions inside a payload. * negotiating what is preferred when more than one message type might be appropriate for solving a problem. * indicating that a payload is mandatory to understand (or is it the intent that there will never be a payload that is mandatory to understand?) Without this guidance, I expect the next attempt to add a message type will force revision of this document and you will be tightly constrained to what implementations already do when answering those questions.
1) In Section 4.1 of the description of "A": Set to "1" to indicate that acknowledgement is required. Set to "0" to indicate that acknowledgement is optional. Should they be REQUIRED and OPTIONAL? 2) In the final paragraph of 4.1: there are a lot of statements about this is required and this is optional. Shouldn't these use 2119 language? 3) In section 4.2 (identification and extensions): there are a lot of statements about this is required, this is mandatory, and this is optional. Shouldn't these use 2119 language?
The also wonder what the motivation for this generic mechanism is. Especially why does it need to be generic? Can't it purpose be expressed more clearly?
draft-thaler-v6ops-teredo-extensions
Trailer type field might benefit from having an IANA registry.
draft-ietf-netmod-arch
Section 1.1., paragraph 0: > 1. Introduction > 1.1. Origins of NETCONF and YANG Section 1 only consists of Section 1.1 - why not move the content of Section 1.1 into Section 1? (Also, I wonder if this history was better placed in an appendix; just start with Section 2 directly.) Section 1.1., paragraph 9: > hierarchies defined in other modules, seemlessly adding data at Nit: s/seemlessly/seamlessly/ Section 2.2.3., paragraph 12: > hierarchy for that area, complete with any augmentated data. Nit: s/augmentated/augmented/
This is a fine document, but I think it can be improved by inserting various
Informative references, in particular:
2.2.1. Constraints
The reference to XPath is missing.
2.2.3. Extensibility Model
The <no-neighbor-down-notification> element is then placed in the
vendorx namespace:
<ospf xmlns="http://example.org/netconf/ospf">
<area>
<name>0.0.0.0</name>
<interface>
<name>ge-0/0/0.0</name>
<priority>30</priority>
<vendorx:no-neighbor-down-notification/>
</interface>
</area>
</ospf>
I think the example is incomplete, as it is missing the "vendorx" namespace
definition.
3.2. Addressing Operator Requirements
o Full coverage: YANG modules can be defined that give full coverage
to all the native abilities of the device. Giving this access
avoids the need to resort to the command line interface (CLI)
using tools such as Expect.
I happen to know what Expect is, but maybe this needs an Informative Reference?
o Internationalization: YANG uses UTF-8 encoded unicode characters.
This needs an Informative reference to RFC that defines UTF-8.
o Security: NETCONF runs over transport protocols secured by SSH or
TLS, allowing secure communications and authentication using well-
trusted technology. The secure transport can use existing key and
credential management infrastructure, reducing deployment costs.
SSH and TLS need Informative references (actually they were referenced earlier
in the document).
Extremely well written. Thanks. It would be helpful if the security considerations section pointed to [RFC4741], [RFCYANG], and [RFCYANGUSAGE].
1. I'm happy to see that we are "allowing devices to express their unique capabilities". :) 2. Section 1.1 states: Many of the observations give insight into the problems operators were having with existing network management solutions, such as the lack of full coverage of device capabilities and the ability to distinguish between configuration data and other types of data. I think you mean "inability", not "ability". 3. Please add a reference to the XPath spec in Section 2.2.1. 4. Section 3.2 verges on marketing. Who is the audience for this text? 5. Section 4.3.1 states: It is necessary to make a clear distinction between configuration data, data that describes operational state and statistics. Are there three kinds of data here or only two? If three, I think this wording is better: It is necessary to make clear distinctions among three different kinds of data: configuration data, operational state data, and statistical data. However, Section 4.3.1 goes on to state: NETCONF does not follow the distinction formulated by the operators between configuration data, operational state data, and statistical data, since it considers state data to include both statistics and operational state data. Which is it? Are the relevant distinctions supported or not? If NETCONF treats both operational state data and statistical data as state data, is that a problem? 6. Section 5 claims that "this document discusses an architecture for network management"; however, instead the document seems to provide an overview of NETCONF and YANG, along with guidelines for applying those technologies to the solution of common network management problems. Does the title need to be changed so that readers are not disappointed?
1) Expand NETCONF and YANG in abstract and XSD, DSDL, NG, 2) Sec 3.2: Is "text-friendly" and "human friendly syntax" the same thing? 3) Sec 4.1: r/it's/its
draft-ietf-opsec-igp-crypto-requirements
For consistency, add citations to the defining RFCs that define the use of HMAC-SHA-256/HMAC-SHA-384/HMAC-SHA-512 in the various routing protocols; e.g., Implementations may start providing support for HMAC-SHA-256/HMAC- SHA-384/HMAC-SHA-512 [RFC5310] as these algorithms may be necessary in the future. at the end of section 3.2
INTRODUCTION, paragraph 3: > Cryptographic Authentication Algorithm Implementation > Best Practices for Routing Protocols It is odd to see the term "best practices" in the title of a document that is not actually targeted as a BCP. Plus, the contents of the document aren't best practices, they are rather suggestions to implementors to avoid potential future interoperability issues. Suggest to reword the title. Section 4.1, paragraph 4: > all conformant implentations MUST support this. Nit: s/implentations/implementations/ Section 11.1, paragraph 2: > [ISO] "Intermediate system to Intermediate system routeing Nit: s/routeing/routing/
I would like to "Yes" on this document because I think it is a
valuable and important piece of work, but there is a bunch of
issues that I think need to be addressed in a revision.
When these have been addressed, I will move to "Yes".
---
I agree with Sean's Comment about 2119 language. Not only is this an
Informational I-D, but it is referencing other sources to inherit
the use of this language. I recommend changing this to normal English
usage throughout, and dropping the (duplicated) 2119 boilerplate.
---
Section 3.1
In order for IS-IS implementations to interoperate, they must support
one or more authentication schemes in common.
This is not true as written! IS-IS implementations interoperate
perfectly well with the use of no authentication. It is possible that
you are assuming that "no authentication" *is* an authentication scheme,
but that sounds a little pedantica and rather confusing. So probably you
mean the "In order for IS-IS implementations to interoperate with the
use of security, they must..."
This subtle change in language should be applied throughout the
document (e.g. sections 4.1 and 4.2 - although, why is this text
duplicated in 4.1 and 4.2?)
---
Section 3.1 observes that there is a use for cleartext passwords, but
then says that the IETF believes the use should be deprecated. Would it
not be better to say "this mechanism does not provide any significant
level of security." This language has the additional benefit that it
avoids the discussion of whether this document is a BCP or PS rather
than Informational.
The language in the OSPF section (4.1) to cover the same point is much
better.
Section 6.1 manages to be better and worse :-)
Simple Password defined as a MUST in [RFC2453] should only be used
when the operator wishes to preclude the accidental introduction of a
RIP router into the domain. This authentication scheme is useful, but
not when the operator wants to protect RIPv2 message exchange in a
potentially hostile environment.
Implementations MUST provide support for Simple Password, but its
operational use is deprecated.
The first paragraph puts it nicely. The second paragraph:
- repeats the "MUST" which it does not need to do
- makes a deprecation statement that contradicts the utility stated in
the first paragraph.
---
Section 4.1 and 6.1
This section specifies the
requirements for standards conformant OSPFv2 implementations, which
desire to utilize the authentication feature.
The language used here is very different from that in section 3.1.
Why? Can you use the same advisory text that you have in 3.1?
---
Section 4.2
Keyed MD5 as defined in [RFC2328] is a MUST. It is our belief that
HMAC-SHA-1 and HMAC-SHA-256 as defined in [RFC5709] will likely be
preferred in the future. Keyed MD5 MUST be implemented, but its use
may be deprecated in future. Implementations must provide support for
HMAC-SHA-256 as this will become the algorithm of choice.
1. There is some duplication of the MUST implement keyed MD5.
2. Is the final sentence a statement that can be referenced, or are
you defining it here?
If you are defining it, then this is not an Informational I-D and
becomes PS with review needed by the OSPF WG.
I would prefer you to change this to be an observation.
For example:
[RFC2328] states that implementations must offer keyed MD5
authentication. It is likely that this will be deprecated in favor of
HMAC-SHA-1 and HMAC-SHA-256 [RFC5709] in future deployments, so new
implementations should support these algorithms.
---
Section 5 on OSPFv3
The algorithm requirements for AH and ESP are described in [RFC4835]
and are not discussed here.
This is true, but why not discuss them here? After all, the
requirements for OSPFv2 security are described in other documents, but
you still discuss them in this document. I think you should state what
the required algorithm support is, and observe that you think this is
sufficient (or not).
Ditto Section 7 on RIPng.
---
Section 6.1
Keyed-MD5 as defined in [RFC2082] is a MUST. However, [RFC2082] has
been obsoleted by [RFC4822] Cryptographic Authentication. Compliant
implementations MUST provide support for Keyed-MD5 as described in
[RFC2082] but should recognize that this is superseded by
Cryptographic Authentication as defined in [RFC4822].
This is a bit mixed up! RFC 2082 is obsolete so implementation should
not do anything as defined in that spec. They must conform to RFC 4822
which is quite clear on the requirements for MD5 and SHA, and which
also indicates the preferences between the schmes.
---
Dynamic key management is important and you cover it in Section 8.
To ensure greater security, the keys used should be changed
periodically and implementations MUST be able to store and use more
than one
key at the same time.
But this does not indicate whether the protocols actually support
changing keys. Shouldn't this be something covered in each of the
main sections 3 through 7?
What about automated key management?
Probably have a look at RFC 4107, and write some cosiderations of the
IGPs based on what it says.
Nit: Section 1 It should be recognized that preferred algorithm(s) will change over time in to adapt to the evolving threats. s/time in/time/ --- Nit: Sections 3 and 4 s/use of SHA family/use of the SHA family/ --- Nit: Section 3.1 s/scheme as provides/scheme as it provides/ --- Section 6 RIPv2, originally specified in [RFC1388], then [RFC1723], has been finalized in STD56 [RFC2453]. For some definition of "final". Can you: s/finalized in/updaed and published as/
Two spellings are used: "Null authentication" and "NULL
authentication". Please pick one.
In the Introduction, I think it is better to talk about the overall
technique before particular algorithms like MD5. Below I suggest
rewording for 3rd and 4th and 5th paragrahs of the introduction.
In a cryptographic authentication scheme, routers share a secret
key which is used to generate a message authentication code for
each of the protocol packets. Today, message authentication codes
often use a keyed MD5 digest. The recent escalating series of
attacks on MD5 raise concerns about its remaining useful lifetime.
These attacks may not necessarily result in direct vulnerabilities
for keyed MD5 digests as message authentication codes because the
colliding message may not correspond to a syntactically correct
protocol packet. There is a however a need felt to deprecate MD5
in favor of stronger message authentication code algorithms.
In section 4.2, Authentication Algorithm Selection (in the OSPFv2 section)
states:
Implementations must provide support for
HMAC-SHA-256 as this will become the algorithm of choice.
I think this should really be HMAC-SHA-1
Amplifying others' discusses on the use of 2119 language in this document - as
written, this document appears to be profiling other protocols, relaxing MUSTs.
For example, section 4.1 calls out three MUSTs in 2328 and says that you only
need implement one of them to be conformant. If something else formally changed
the requirements for the other two, please provide a reference. If that hasn't
happened yet, either this document needs to be on an entirely different track,
or the language needs to be reworded to report on deployment and perhaps future
standards work.
1) Is this draft supposed to be a BCP instead of informational? In the title it
has "Best Practices" and in the last sentence of the security considerations it
has:
We expect that new revisions of this document
will be issued in the future to reflect current thinking on best
practice in this area.
2) 2119 requirements language is used only to specify what's already in RFCs -
shouldn't there be requirements about switching to a new algorithm? If it's
just listing what's out there now, then do that and remove all the talk about
deprecating this or that algorithm. If you're suggesting that algorithms be
deprecated, then do that and use 2119 language.
3) Because there are no new recommendations this draft ought to called something
like "A survey of IGP Crypto". The purpose of this draft is very unclear to me.
4) If this document is in fact providing advice about the use of authentication
in IGP implementations and deployments, ad the name of the document implies,
then I agree with Adrian that the following issues need to be addressed:
- does an implementation support key change?
- how often is key change
recommended?
- can key change be in-service?
- how many keys can be configured
at once?
- how many keys can be active at once?
- can key change be dynamic
(i.e. by a protocol)
- can dynamic key change be managed by the IGP or does it
need a second protocol to manage the keys?
1) The RFC editor will make you scrub the references (i.e., [RFCXYZ]) from the abstract. Move them to the Introduction. 2) Section 2 and the "conventions used in this document" section are the same. Keep the 2nd (that's where the RFC editor will put it). 3) It's probably worth adding a reference to SHS (for the SHA family): [SHS] National Institute of Standards and Technology (NIST), FIPS Publication 180-3: Secure Hash Standard, October 2008. 4) Sec 6: Is there something missing from the end of this sentence maybe "packet": If the Address Family Identifier of the first (and only the first) entry in the message is 0xFFFF, then the remainder of the entry contains the authentication. 5) Sec 3.1: r/scheme as provides no/scheme as it provides no
draft-mavrogiannopoulos-rfc5081bis
This is a Discuss-Discuss. That is, no action is currently required from the
authors, but I want to discuss this issue with the sponsoring AD and the rest of
the IESG.
I'm a little confused :-(
Probably a result of re-using text from RFC 5081, but
does this
document "propose extensions" [see Abstract], "define extensions"
[see
Introduction : would be consistent with PS], "replace RFC 5081
with some
important modifications that are not backward-compatible"
[would be consistent
with Experimental], or "document extensions used
in a particular implementation"
[as described in the shepherd write-up : consistent with Informational]?
The shepherd write-up indicates a "previous last call", is that refering to RFC
5081's last call?
This is a relatively minor issue and I am happy for it to be addressed using an
RFC Editor note:
I am slightly confused. If this extension is not backward compatible, why is it
actually Ok to reuse the extension type 9 from <http://www.iana.org/assignments
/tls-extensiontype-values/tls-extensiontype-values.xhtml>?
draft-josefsson-pbkdf2-test-vectors
draft-cakulev-mikey-ibake
The document explains that the inclusion of the date in the identity virtually
eliminates the need for key revocation. The document also explains that in
typical usage, there is a need to contact the key management server only
occasionally, such as once a month. I may be dense or missing something, but I
have a very difficult time understanding how key revocation would work in this
context. If the key management server gives you daily keys for the next month,
your peer gets his daily keys for the month, and you two communicate directly,
then these communications will succeed no matter what someone else may have
decided about key revocation. This is a similar situation to any secret or
public key system without online key revocation checks. Perhaps the document
should have said that it cannot support key revocation at all, unless a real-
time always-available key management server can be assumed? (And even so, such
check roundtrip should be specified.)
The document also leaves something to desire in terms of explaining the overall
architecture and assumptions. Some of the base IBC documents talk about
mandatory TLS to the key management server. I assume that this is not required
by the architecture specified here, and instead you assume MIKEY shared secrets
between the hosts and the key management server? Assumptions like this should be
clearly described at the beginning of the document. Also, the IBC public
parameters concept is mentioned for the first time on page 10, and it would have
been nice to know early on that the key management server delivers those. It
would also be useful to know when such parameters can change (or can they?).
> For the description of IDR payload as well
> as for the definition of additional PRF functions and encryption
> algorithms not defined in [RFC3830], see [I-D.mattsson-mikey-ticket].
That needs to be a normative reference.
Section 2.2 talks about IDr/i and Section 4.2.1 about IDRr/i. Are these the same
or different?
> Attacks on the cryptographic algorithms used in Identity Based
> Encryption are outside the scope of this document.
Some pointer(s) to the security considerations of the algorithms would still
seem useful, and have traditionally appeared in RFCs of this sort.
> It is assumed
> that any administrator will pay attention to the desired strengths of
> the relevant cryptographic algorithms based on an up to date
> understanding of the strength of these algorithms from published
> literature as well as known attacks.
According to http://www.ecrypt.eu.org/documents/D.SPA.13.pdf Section 12.2.1 key
length selection in these systems is still pretty unexplored for the
cryptographic community let alone a sysadmin; it would be useful for this
document to provide some guidance.
The document needs to define and expand terms that it uses, for instance there are many IMS related terms that are used without introduction (IMS, CSCF). > a huge burden I would just say "a burden", for better style in these types of documents > Moreover, since the keys are created and > distributed by the KMS, these servers are de-facto escrow points > leading to increased vulnerability and operational discomfort on the > part of end-users. I am the last person on this planet to argue in favor of legal interception, but I did find it odd that the document talks about public voice communication systems such as IMS that have government requirements for legal interception. And at the same time argues that somehow the specified solution is less vulnerable to escrow/interception. Either the specified system is capable of such interception as well, or it isn't. If the authors want to make a claim that there is no way to provide legal interception in their system then the argument seems fair, otherwise... I would just delete it.
I have a few small issues that I would like to Discuss before consenting to the
publiscaiton of this document.
idnits (http://tools.ietf.org/tools/idnits/) is a useful tool that
helps you catch issues that need to be fixed before the document can
proceed.
It gives the following pointers...
The KEMAC payload SHOULD be used only when the user needs to use
specific keys. Otherwise, this payload SHALL not be used.
s/SHALL not/SHALL NOT/
--
-- The document has a disclaimer for pre-RFC5378 work, but was first
submitted on or after 10 November 2008. Does it really need the
disclaimer?
--
== Unused Reference: 'RFC4120' is defined on line 1298, but no
explicit reference was found in the text
---
I don't see the IPR disclosure (1359) referenced during the IETF last
call.
---
Can someone please clarify for me why this is an Informational
specification? It has the look and feel of a standards track
specification since it defines the behavior of compliant
implementations, uses 2119 language, defines protocol elements, and has
a non-null IANA section.
There *are* possible good reasons for this; I would just like to know
which one applies, and to discuss how this should be recorded in the
document.
---
I am worried about the reference to draft-ietf-msec-mikey-ecc.
Taht document expired in June 2007 and it would appear that the WG
has given up on it.
---
The way that Section 6 uses draft-mattsson-mikey-ticket makes it
look like a Normative reference to me.
Agree with Russ that [I-D.cakulev-ibake] should be a Normative reference. --- Section 6.1.4 I would like to caution against both this document and draft-ietf-msec-mikey-ecc defining the same format. It is best to have just one definition, and let the other document make a normative reference.
The draft-cakulev-ibake-01 document needs to be a normative reference.
I haven't performed a very thorough review of this document, but I didn't find
answers to the following questions:
I don't see where the format of the timestamp (T) field is defined.
Does the protocol require time synchronization between the Initiator and the
Responder?
1) In Sec 6.1, the data type values (from Table 2), I think, are already
assigned by IANA (http://www.iana.org/assignments/mikey-payloads). I think they
#s need to start at 19 and go up.
2) In Sec 6.1, the next payload values are taken from unassigned #, but I'm
curious why the #s didn't come from 27 and higher? Was there a reason
mattsson-mikey-ticket-05 didn't come from 13-19?
1) Sec 4.2.1.1: r/Otherwise, this payload SHALL not be used./Otherwise, this payload SHALL NOT be used. ? 2) Sec 4.2.2.2: r/ If the received message is correctly parsed, the Responder shall use / If the received message is correctly parsed, the Responder SHALL use
draft-dzis-nwg-nttdm
I have no problem this being published as an RFC. However, I did notice that various classifications within the specification are somewhat arbitrary. For instance, why is there a relationship between bandwidth and core vs. access links in TT_SHORT_DESCRIPTION? And what should be put to TT_SHORT_DESCRIPTION when there is an IPv6 routing problem? "Routing Problem" or "IPv6"? The naming of various alternatives is also a bit inconsistent, e.g., some names in TT_SHORT_DESCRIPTION end with a "Fault", some with "Problem", some with nothing like that.
Can the ISE and the IANA confirm that Expert Review has been carried
out as required by the "The IETF XML Registry"?
Thank you for this document and for placing it on the Experimental Track. These Comments are for the authors to consider in discussion with the ISE. --- I would appreciate a few words in the document (perhaps section 1.5?) to describe what you hope will happen with this "experiment". For example, are you hoping for people to implement and try it out in a walled garden? Can experimentation safely be carried out in "the Internet"? Do you hope to gather feedback and return to put this on the Standards Track? --- I struggled a bit with the Abstract because of two trivial punctuation issues OLD Handling multiple sets of network trouble tickets (TTs) originating from different participants inter-connected network environments poses a series of challenges for the involved institutions, Grid is a good example of such multi-domain project. NEW Handling multiple sets of network trouble tickets (TTs) originating from different participants' inter-connected network environments poses a series of challenges for the involved institutions. Grid is a good example of such multi-domain project. END --- I found an assertion in the Abstract needs qualification. As a result, management of the daily workload by a central Network Operations Centre (NOC) is a challenge on its own. Normalization of TTs to a common format for presentation and storing at the central NOC is mandatory. I think that normalization is not "mandatory". It is mandatory if you want to achieve some specific function. Which function? --- I am sure the RFC Editor will discuss with you whether the references need to be split into normative and informational.