IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2014-02-06. These are not an official record of the meeting.
Narrative scribe: Susan Hares and John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Pete, Barry, John
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
Telechat:
2.3 Status Changes
2.3.1 New Items
Telechat:
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
3.2.2 Returning Items
3.3 Status Changes
3.3.1 New Items
3.3.2 Returning Items
3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items
3.4.2 Returning Items
3.4.3 For Action
Telechat:
1304 EST break two minutes
1306 EST back (no roll-call)
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
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
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Agenda Working Group News
1341 EST Entered Exectutive Session
(at 2014-02-06 07:30:04 PST)
draft-ietf-p2psip-rpr
- General: RELOAD is now an RFC and should be referred to as such. - 5.1: what is N? - 5.1 last para seems to contain a logical flaw, you say that RPR can be better or worse than SRR, depending on N, but you cannot conclude from that that which is better then does not depend on N, but only on other factors. I think the text makes that mistake. - 9: On what basis and for what are we saying that an RPR relay node "SHOULD be a trusted one"? (That's an odd phrase in itself.) I can see problems with getting a RELOAD client to really trust some IP address somewhere in the n/w for some unstated purpose. - 9: Presumably an RPR relay is a fine point of attack, esp if used by many devices. What problems can arise? I don't think you say but shouldn't you? (For example, if I wanted to know who's calling whom and can convince lots of folks that I'm a good RPR then happy days for me.) (Note the two last points above are near-discusses, but I'll leave them as comments for now since I don't recall if RELOAD covers those issues and haven't time right now to check. If I get a chance to check before the telechat I might make 'em DISCUSS points.)
I have no general objections to the publication of the draft but a few relative easy points to fix: Section 4.1., paragraph 2: > A requirement for RPR is for the source peer to convey their relay > peer (or peers) transport address in the request, so the destination > peer knows where the relay peer are and send the response to a relay > peer first. The request SHOULD include also the requesting peer > information enabling the relay peer to route the response back to the > right peer. Why is this SHOULD not a MUST? Or asked differently: How does the relay determine the requesting peer if the information of the requesting peer is ommited? A clarifying question: What is the 'information'? Does this have a name defined either in this document or somewhere else? Section 4.2., paragraph 3: > using RPR SHOULD be discouraged in the open Internet or if the Is "SHOULD be discouraged" actually meaning "SHOULD NOT be used in the open Internet"?
Section 4.1., paragraph 2: > A requirement for RPR is for the source peer to convey their relay > peer (or peers) transport address in the request, so the destination > peer knows where the relay peer are and send the response to a relay > peer first. The request SHOULD include also the requesting peer > information enabling the relay peer to route the response back to the > right peer. A clarifying question: What is the 'information'? Does this have a name defined either in this document or somewhere else? Section 4.2., paragraph 1: > RPR is not intended to replace SRR. It is better to use these two > modes together to adapt to each peer's specific situation. Note that > the informative suggestions on how to transition between SRR and RPR > are the same with that of DRR. Please refer to DRR document [I-D > .ietf-p2psip-drr] for more details. If a relay peer is provided by It would be really good to state where in the DRR draft the implementer should look for further information. Section 4.2., paragraph 2: > the service provider, peers MAY prefer RPR over SRR. Otherwise, This MAY is odd, as it does not describe an optional protocol element, but relates to operational advice. I would simply say that "peers should prefer RPR over SRR". For the whole of Section 5: This reads like something for the appendix of the document, as it is not mandatory and solely provides further information other than protocol specification. Section 6.4.1., paragraph 2: > If the routing mode is RPR, the destination peer MUST construct a > destination_list for the response with two entries. The first MUST > be set to the relay peer Node-ID from the option in the request and > the second MUST be the sending peer Node-ID from the option of the > request. Is the sending peer the requesting peer or the peer sending the response? Or is it the Destination peer? The terminology is far from being consistent and understandable. This will make it very hard to get implementations that get it right. Section 7., paragraph 1: > This document uses the new RELOAD overlay configuration element, > "route-mode", inside each "configuration" element, as defined in > Section 7 of the DRR document [I-D.ietf-p2psip-drr]. To what value "route-mode" must be set for RPR? Please clarify here. Section 10.1., paragraph 1: > A new RELOAD Forwarding Option type is added to the Forwarding Option > Registry defined in [I-D.ietf-p2psip-base]. Better say "to be added in RELOAD Forwarding Option Registry under REsource LOcation And Discovery (RELOAD).
In Section 2, it would be helpful to me, to include a description of DRR. I know that's described in another specification, but DDR is referenced throughout this one. In 3.2.2. Using bootstrap nodes as relay peers Bootstrap nodes are typically publicly reachable in a RELOAD architecture. As a result, one possible architecture would be to use the bootstrap nodes as relay peers for use with RPR. A relay peer SHOULD be publicly accessible and maintain a direct connection with its client. would a relay peer work if it's not publicly accessible? In 4.1. How RPR works A requirement for RPR is for the source peer to convey their relay peer (or peers) transport address in the request, so the destination peer knows where the relay peer are and send the response to a relay peer first. The request SHOULD include also the requesting peer information enabling the relay peer to route the response back to the right peer. would RPR work if you don't include the requesting peer information?
I support Martin's DISCUSS points.
On Sep 25, 2013, at 8:30 PM, Carlos Pignataro <cpignata@cisco.com> wrote: > Hi! > > As a member of the Operations Directorate I have reviewed the following draft which is in IETF last call for it's operational impact. > > This document specifies protocol extensions to RELOAD to allow for a shortcut in the return path. This in turn is advantageous to network administrators from a manageability perspective. > > Minor: > > The document references the "configuration file", which is defined in [I-D.ietf-p2psip-base]. [I-D.ietf-p2psip-base] is a Normative reference. As a suggestions, perhaps, it could help to clarify where the configuration file is defined (i.e., add a citation to the relevant section of p2psip-base). > > Also the document makes a distinction between a managed network versus an open network, but this is not precisely defined in this document. A small definition of what is a "closed" versus "open" network could help, from a manageability standpoint. > > Nits: > > It is not clear why there is a subsection 3.1.1, when it has the same heading as 3.1, and 3.1 is a single paragraph: > 3.1. RPR > 3.1.1. Relay Peer Routing (RPR) > > In some mobile deployments, using RPR may help reducing radio battery > usage and bandwidth by the intermediate peers. The service provider > may recommend using RPR based on his knowledge of the topology. > > "his or her knowledge", as the service provider can be a "he" or a "she". > > Hope these are clear and useful! > > Carlos.
draft-ietf-p2psip-drr
In section 1, last paragraph: networks. An extension to RELOAD to support DRR is proposed in Section 6. Some optional methods to check peer connectivity are I think you should say "defined" rather than "proposed", to avoid misunderstandings. This is consistent with the text in section 6. Why don't tables 1 and 2 also list performance for SRR+DTLS? Also, probably a naive question, with DTLS+DRR, is every message after the first sent directly from the sending peer to the destination peer? This seems obvious—if DRR succeeded, why not? But it's never mentioned in the document, so perhaps I am missing something?
- DRR involves sending the client IP address out to the network. Is that different from base RELOAD? If so, then that privacy-relevant difference should be noted, but I've not had time to check the base RELOAD (this would be a DISCUSS if I had time to check and figured that it is different). Is this a new consideration? - Could checking for DRR, but then falling back to SRR, involve sending out the client IP address in a way different from base RELOAD? (Same as above, no time to check, sorry;-) - The diff [1] between this and RPR is interesting. There are common bits of specification but its not clear to me which RFC will be normative, e.g. for the IGNORE-STATE-KEEPING flag. That doesn't seem like a good plan, but I'm not sure what'd be best to do about it. [1] http://tools.ietf.org/rfcdiff?url1=draft-ietf-p2psip-rpr-11&url2=draft-ietf-p2psip-drr-11.txt
I have no general objections to the publication of the draft but a few relative easy points to fix: First a procedural question about adding flags to the ForwardingOption: Apparently this draft adds a new value to the flags in the ForwardingOption header. However, there is no registry that keeps track of the flags in any coordinated way. Is this intentional? Second, which of the RPR or DRR draft is creating the new flag? Section 4.2., paragraph 2: > According to base draft [I-D.ietf-p2psip-base], SRR MUST be > supported. An overlay MAY be configured to use alternative routing > algorithms, and alternative routing algorithms MAY be selected on a > per-message basis. I.e., a node in an overlay which supports SRR and > some other routing algorithm, for example DRR, might use SRR some of > the time and DRR some of the time. A node joining the overlay should > get from the configuration file the preferred routing mode. If an > overlay runs within a private network and all peers in the system can > reach each other directly, peers MAY send most of the transactions > with DRR. On the contrary, using DRR SHOULD be discouraged in the Same point as for the RPR draft: Is "SHOULD be discouraged" actually meaning "SHOULD NOT be used in the open Internet"?
For the whole of Section 5: This reads like something for the appendix of the document, as it is not mandatory and solely provides further information other than protocol specification. Section 6.2.1., paragraph 1: > RELOAD allows intermediate peers to maintain state in order to > implement SRR, for example for implementing hop-by-hop > retransmission. If DRR is used, the response will not follow the > reverse path, and the state in the intermediate peers will not be > cleared until such state expires. In order to address this issue, we > propose a new flag, state-keeping flag, in the message header to > indicate whether the state keeping is required in the intermediate > peers. I assume your reference to the "message header" refers to "Forwarding Option"? Better to clarify it here. The terminology in 6.4., similar to the RPR draft, could be better explained/defined. I.e., what is the sending peer, requesting peer, etc. Section 9.1., paragraph 1: > A new RELOAD Forwarding Option type is added to the Forwarding Option > Registry defined in [I-D.ietf-p2psip-base]. Better say "to be added in RELOAD Forwarding Option Registry under REsource LOcation And Discovery (RELOAD).
I expect to ballot YES on this draft, but wanted to ask a question first ... I'm looking at http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-p2psip-rpr-11.txt&url2=http://tools.ietf.org/id/draft-ietf-p2psip-drr-11.txt and seeing a lot of duplication between these drafts. That could be OK, although some protocol machinery looks like it's defined in both drafts (for instance, 0x08 IGNORE-STATE-KEEPING), but what I hoped to see is some discussion of RPR versus DRR - when you implement RELOAD, does it make sense to pick either RPR or DDR, and then fall back to SSR, or would you expect anyone to implement both SRR and RPR, or even attempt both in succession before falling back to SSR? I would guess that attempting DDR (directly route the reply), then attempting RPR (route using a relay), and only then falling back to SSR would make sense. Is there any guidance you can give? You'll notice I'm a coauthor on http://tools.ietf.org/html/draft-ietf-p2psip-concepts-05, so if you tell me "there's no energy for new text", I'll believe you, but I wanted to ask ...
In Section 2, it would be helpful to me, to include a description of RPR. I know that's described in another specification, but RPR is referenced throughout this one.
draft-ietf-soc-overload-control
Section 11, last paragraph: To prevent such attacks, servers should monitor client behavior to determine whether they are complying with overload control policies. If a client is not conforming to such policies, then the server should treat it as a non-supporting client (see Section 5.10.2). This is probably just my failure of comprehension, but it is not at all clear to me how a server can monitor client behavior. How does the server distinguish between a situation where the client is not throttling, versus a situation where the client _is_ throttling, but load has increased proportionally to the amount of throttling requests, so that the observed load appears constant? Are you simply gambling that this will never happen, or did I misunderstand something?
Thanks for the good security considerations text on DoS! I think the changes proposed from the secdir review [1] look good and assume they'll be incorporated into a revision. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04521.html In addition, presumably a DDoS attack could cause an honest server to start signalling an overload condition. If such a server had a long oc-validity time, then that validity time might act as an accelerator for the DDoS attack. Even the 500ms default might mean that a botnet could use this perhaps. Is that worth an additional bit of security consideration text? I guess the attack pattern there would be that the botnet would pop up and try overload the server every oc-validity milliseconds or so and go quiet in the intervals. I've no idea if that could be confused with nominal reactions to a real overload though.
1:
- First paragraph:
In fact, overload may lead to
a situation in which the throughput drops down to a small fraction of
the original processing capacity. This is often called congestion
collapse.
I don't think that's right. My lower-layer comrades can correct me if I'm
wrong, but my understanding is that congestion collapse is when the congestion
control mechanism itself (for example, retransmission in the face of packet
loss) adds additional traffic to the network, eventually swamping the network
such that no (or exceedingly little) new traffic can get into the network. A
network at maximum capacity where traffic is slow because there's simply too
much traffic for that network to handle is not "collapsed", as far as I
understand the term. So long as everyone is holding back their traffic such
that the network is not being flooded with retransmissions or the like, that's
just overload, not collapse.
In any event, I don't think the use of the term adds anything to the
discussion, so I would simply (a) strike the last two sentences of the first
paragraph, (b) strike "and it cannot prevent congestion collapse" from the
fourth paragraph, and (c) change "avoiding congestion collapse and" to
"thereby" in the fifth paragraph.
- Please change "we only consider" to "this document only addresses".
- Please strike the last two sentences (the conformance sentences) of section
1. They add nothing to the document.
2, Last paragraph: I think normative language as described in this paragraph
adds nothing but confusion to the text and is unnecessary. I suggest striking
this paragraph and making the changes I note below to remove the unnecessary
normative language. My suggestions below do not change the meaning of the
protocol at all.
3: Please change "We now explain the" to "This section gives an" in the first
sentence.
4.1: Change "MUST add" in paragraphs 2 & 3 to "adds".
4.2:
- Change "MUST add" in paragraph 2 to "adds".
- In the last sentence of paragraph 3, I suggest changing "must not assume" to
"can not assume", to avoid confusion.
- In the fourth paragraph, change "it MUST choose one algorithm from the list
and return the single selected algorithm" to "it chooses one algorithm from the
list and MUST return the single selected algorithm".
4.3: Change "the client MUST behave as if overload control is not in effect
between it and" to "overload control is not in effect between the client and".
4.4: Change "MUST be inserted" to "is inserted" in the first sentence.
5: Change "MUST determine" to "determines" in the second paragraph.
5.1:
- Change "MUST insert" (x2) with "inserts" in the first paragraph.
- Change "MUST determine" to "determines and change "MUST follow" to "follows"
in the third paragraph.
5.2:
- Change "MAY" to "can" in the third paragraph.
- Change the last paragraph as follows:
This specification provides a good overload control mechanism that
can protect a SIP server from overload. However, if a SIP server
wanted to limit its overload control capability for privacy reasons,
it might decide to perform overload control only for...
5.5: Change "MUST determine" (x2) to "determines" in paragraph 3.
5.7:
- Change "MUST set" to "sets" in the second paragraph.
- In the last paragraph, change the second sentence as follows:
If the value of the "oc-validity" parameter is 0, this indicates to
the client that overload control of messages destined to the server
is no longer necessary and the traffic can flow without any
reduction.
7.1:
- Change "MUST appear" to "appears" in the first paragraph.
- Change the third sentence of the second paragraph as follows:
This value indicates to the client the percentage by which the client
is to reduce the number of requests being forwarded to the overloaded
server.
9: I suggest using the ABNF extension mechanism:
via-params =/ oc / oc-validity / oc-seq / oc-algo
Much simpler.
10: I think this section should be moved to an appendix.
These are all non-blocking, but I'd appreciate it if you'd consider them along
with any other comments you receive.
In 1. Introduction
As with any network element, a Session Initiation Protocol (SIP)
[RFC3261] server can suffer from overload when the number of SIP
messages it receives exceeds the number of messages it can process.
Overload can pose a serious problem for a network of SIP servers.
During periods of overload, the throughput of a network of SIP
servers can be significantly degraded. In fact, overload may lead to
a situation in which the throughput drops down to a small fraction of
the original processing capacity. This is often called congestion
collapse.
Overload is said to occur if a SIP server does not have sufficient
resources to process all incoming SIP messages. These resources may
include CPU processing capacity, memory, network bandwidth, input/
output, or disk resources.
I'm struggling with including "network bandwidth" here, with no qualifications.
That seems to conflate both SIP Overload and TSV congestion, thusly:
If UA A sends a request for UA B to a proxy:
UA A -----------> Proxy -----------> UA B
But there's not enough bandwidth between the proxy and UA B, so:
UA A -----------> Proxy ---->// UA B
I'd be OK with characterizing that as "network bandwidth" SIP overload covered
by this draft, but
if the problem of insufficient bandwidth is between UA A and the proxy:
UA A --->// Proxy UA B
the proxy never sees the request. That's not in scope for this draft, is it?
If not, is there an obvious way to tighten this up a bit? (maybe something like
"network bandwidth on the forwarding path"?)
In 2. Terminology
Unless otherwise specified, all SIP entities described in this
document are assumed to support this specification.
In 10.2. Backwards Compatibility, you lead me to think that if my path from
conforming UAC to conforming UAS traverses some proxies that do support this
specification and other proxies that do not, depending on where the
non-conforming proxies are and what proxies are overloaded, you wouldn't do
worse than today's behavior. It might be helpful to say that here.
In 5.10.1. Message prioritization at the hop before the overloaded server,
there are several items listed that a client SHOULD take into account when
deciding what requests to prioritize. Most of them make sense to me, but it's
not obvious that they are 2119 SHOULDs ("good advice, but not required for
interoperability").
In 7.1. Special parameter values for loss-based overload control
The SIP client may use any
algorithm that reduces the traffic it sends to the overloaded server
by the amount indicated. Such an algorithm SHOULD honor the message
prioritization discussion of Section 5.10.1.
since 5.10.1 is full of SHOULDs, this is saying that you SHOULD do what you
SHOULD do. I'm only pointing that out because it struck me as funny ...
In 11. Security Considerations
Attacks that indicate false overload control can be mitigated by
using TCP or Websockets [RFC6455], or better yet, TLS in conjunction
with applying BCP 38 [RFC2827].
If you're already pointing implementers to TCP for better resistance to
attacks, would it make sense to recommend TLS more strongly (in 2014!)? But
it's not obvious that on-path attackers that can modify traffic wouldn't just
drop anything they find inconvenient, I guess.
Also in 11. Security Considerations
A malicious SIP entity could gain an advantage by pretending to
support this specification but never reducing the amount of traffic
it forwards to the downstream neighbor. If its downstream neighbor
receives traffic from multiple sources which correctly implement
overload control, the malicious SIP entity would benefit since all
other sources to its downstream neighbor would reduce load.
The solution to this problem depends on the overload control
method. For rate-based and window-based overload control, it is
very easy for a downstream entity to monitor if the upstream
neighbor throttles traffic forwarded as directed. For percentage
throttling this is not always obvious since the load forwarded
depends on the load received by the upstream neighbor.
To prevent such attacks, servers should monitor client behavior to
determine whether they are complying with overload control policies.
If a client is not conforming to such policies, then the server
should treat it as a non-supporting client (see Section 5.10.2).
Is this text coming close to saying "malicious SIP entities can game this
specification, so you ought to monitor client behavior, but there are some
overload control methods you can't monitor reliably"? If so ... is the only
required overload control method one you can't monitor reliably?
In Appendix B. RFC5390 requirements
REQ 4: The mechanism must be capable of dealing with elements that do
not support it, so that a network can consist of a mix of elements
that do and don't support it. In other words, the mechanism should
not work only in environments where all elements support it. It is
reasonable to assume that it works better in such environments, of
course. Ideally, there should be incremental improvements in overall
network throughput as increasing numbers of elements in the network
support the mechanism.
Meeting REQ 4: Partially. The mechanism is designed to reduce
congestion when a pair of communicating entities support it. If a
downstream overloaded SIP server does not respond to a request in
time, a SIP client will attempt to reduce traffic destined towards
the non-responsive server as outlined in Section 5.9.
I'm not understanding how this is "partially". What did you miss?
REQ 5: The mechanism should not assume that it will only be deployed
in environments with completely trusted elements. It should seek to
operate as effectively as possible in environments where other
elements are malicious; this includes preventing malicious elements
from obtaining more than a fair share of service.
Meeting REQ 5: Partially. Since overload control information is
shared between a pair of communicating entities, a confidential and
authenticated channel can be used for this communication. However,
if such a channel is not available, then the security ramifications
outlined in Section 11 apply.
Does your point about not being able to monitor loss-based overload control
methods also apply here?
REQ 12: The mechanism should work between servers in different
domains.
Meeting REQ 12: Yes, there are no inherent limitations on using
overload control between domains.
I'm hearing a particular operator's voice saying "I'm not telling my
competitors _anything_ about the topology of my network OR the traffic within
my network". Perhaps it's worth mentioning that operators have to be willing to
expose at least a little information about their network to other operators, in
order for this mechanism to work well.
("Don't clear all the oc Via parameters at your SBCs and expect this to work
across your interconnect points!")
expect to see a 15 based on the secdir feedback proposal.
draft-ietf-xrblock-rtcp-xr-qoe
In section 4.2, third paragraph (not counting bullet items above it): Segment extensions, with their directions, MAY be signaled for an "inactive" stream. It is an error to use an extension direction incompatible with the stream direction (e.g., a "sendonly" attribute for a "recvonly" stream). How is this error handled? You an address this DISCUSS point by adding text that says how, or pointing out why it isn't a problem.
Page 6, first paragraph:
measurement techniques allows much large scale measurements to
This is obviously a typo; could be much larger scale measurements or much large
scale measurement. Might want to disambiguate before the copyedit happens to
avoid misunderstandings.
In this document, MOS Metrics MAY be reported for intervals or
for the duration of the media stream (cumulative) however it
is not recommended that sampled values are used.
Section 3.2, just above the Reserved heading:
In this document, MOS Metrics MAY be reported for intervals or
for the duration of the media stream (cumulative) however it
is not recommended that sampled values are used.
It might be better to forbid sampled values if they aren't useful, so that
implementations don't have to handle them. Just a suggestion—you know better
than I. No need to explain if you disagree.
Also seem comments below regarding the fixed point representation description.
But aside from that:
3.2.1 says:
A 1-5 MOS score is multiplied by 10 and then represented in the
8:8 format.
3.2.2 says:
The estimated MOS value is multiplied by 10 and expressed in
6:7 format.
That seems like a recipe for an implementation mistake. If the values are
limited to 1-5, why is the format not simply 3:13 in the 3.2.1 and 3:10 in
3.2.2? Or even better, but some padding in front of the one in 3.2.1 so that
they can both be 3:10. Asking the implementation to multiply by 10 seems like
something that will accidentally not get done by an implementation. Is this
really what you want? Is there some reason I don't understand that you want it
this way?
4.1:
xr-mos-block = "mos-metrics" ["=" extmap *("," calgextmap)]
extmap is undefined.
2.1: Is this text about numeric formats taken from somewhere else, and
therefore everyone already understands it? I found it very confusing and hard
to read. (For example, if I understand correctly, S does not indicate a
two's-complement representation; S simply indicates that the value is signed,
and its absence indicates that it is unsigned. Everything in this format is a
fixed-point two's-complement representation.) But in the document, this
representation is only used in two places, 3.2.1 and 3.2.2, and neither of them
is signed. Seems like you could simply describe the value much more clearly
(e.g., "an unsigned fixed-point twos-complement value, 8 bits of integer and 8
bits of fraction") in each section.
3.2.1:
If the measured value is over range, the value
0xFFFE MUST be reported. If the measurement is unavailable, the
value 0xFFFF MUST be reported.
I don't think those MUSTs are appropriate. Those are definitions. Instead:
A value of 0xFFFE is a flag indicating that the measured value is
out of range. A value of 0xFFFF is a flag indicating that the
measurement is unavailable.
Similarly in 3.2.2.
5.3: I still don't understand why we have individuals as contacts for IETF
standards track registered items. The IETF or IESG should be the registrant,
not an individual.
Be nice to expand MOS in the abstract.
The metric names in the registry are not specific enough: payload type, calculation identifier metric, segment type, and potentially MOS. I guess they should say something about RTP. Let me file this DISCUSS while I double-check with the performance metric directorate.
Pete has my comments covered.
draft-ietf-tls-applayerprotoneg
Seems reasonable to me. Nit: The ToC is missing page numbers.
These are pretty nitty comments mostly, but not quite entirely:-) - abstract: this is slightly wrong - the main use case here is HTTP/2.0 over port 443. That *is* the right port associated with HTTP. s/not associated/possibly not associated/ might be a good change. - Intro: "virtually the entire global" is marketing and could change quickly if middleboxes start snarfing ALPN - Intro: certificate selection at the host level can be done with SNI, I'd not mention that I think unless you want to add "in a more fine-grained manner than can be done with SNI [RFC6066]" or similar. - 3.1: The last para there is not very clear unless you have TLS stuff at the front of your brain. I'd suggest a sentence or two more to explain it might be useful and help developers do the right thing. For example, I think this means that you MUST re-do the ALPN dance on session resumption, but that is not clearly stated by just saying "only of the connection." - 3.2: Does the last sentence there mean that e.g. Tor will likely want to not conform to that "SHALL NOT"? I can well imagine them wanting to tell white lies about the protocol in use. Was that considered? (Note: I'm not asking to change the SHALL NOT.) - 4: The "typical design" phrase here contrasts with the "unlike many other" phrase in 3.1. Maybe consider a tweak? - 4: I think it'd be more clear and more correct to just say that encrypted ALPN was judged too big a change for TLS1.2 when TLS1.3 was being started since we plan to support encrypted ALPN in TLS1.3. - 5, 2nd para: suggest s/browsers/some browsers/ - 5: It could be worth saying that simple traffic analysis would in any case easily detect many protocols that encrypted ALPN would attempt to hide, e.g. HTTP/1.1's verbose binary cookie-laden requests vs. HTTP/2.0's binary stuff.
A nit (in multiple places): It is not "TCP/IP port number", but only "TCP port number".
I am afraid that some of the normative language in this document would require
you to make this an update to 5246, and I don't think that's what you mean to
do. Other normative language is just confusing. Without explaining bit-by-bit,
I suggest below some changes that I think clarify and do not change the meaning
at all. I am happy to explain if asked. There's a lot of text here, but really
most of it is only 8 minor textual changes. Other questions inline:
3.1
OLD
is defined and MAY be included by the client in its "ClientHello"
NEW
is defined and can be included by the client in its "ClientHello"
END
OLD
("application_layer_protocol_negotiation(16)") extension SHALL
contain a "ProtocolNameList" value.
NEW
("application_layer_protocol_negotiation(16)") extension contains a
"ProtocolNameList" value.
END
(I'm assuming you don't really mean the above as a restriction. Otherwise, you
would say: NEW
("application_layer_protocol_negotiation(16)") extension SHALL
NOT contain an unregistered "ProtocolNameList" value, as defined
below.
END
I don't think that's what you meant.)
OLD
Implementations
MUST ensure that an empty string is not included and that no byte
strings are truncated.
NEW
Empty strings MUST NOT be included and byte strings MUST NOT be
truncated.
END
(But actually, I don't understand the second part: What does it mean for a byte
string to be truncated in this context?)
OLD
Servers that receive a client hello containing the
"application_layer_protocol_negotiation" extension, MAY return a
suitable protocol selection response to the client. The server will
ignore any protocol name that it does not recognize. A new
ServerHello extension type
("application_layer_protocol_negotiation(16)") MAY be returned to the
client within the extended ServerHello message.
This one I'm actually not clear on. Are those really OPTIONAL? What else would
I do as a server? Shouldn't it be:
NEW
Servers that receive a client hello containing the
"application_layer_protocol_negotiation" extension will return a
suitable protocol selection response to the client. The server will
ignore any protocol name that it does not recognize. A new
ServerHello extension type
("application_layer_protocol_negotiation(16)") is returned to the
client within the extended ServerHello message.
END
OLD
field of the ("application_layer_protocol_negotiation(16)") extension
SHALL be structured the same as described above for the client
NEW
field of the ("application_layer_protocol_negotiation(16)") extension
is structured the same as described above for the client
END
3.2:
It is expected that a server will have a list of protocols that it
supports, in preference order, and will only select a protocol if the
client supports it.
Not having to do with the normative language: It took me a bit to figure out
the use case here. It might be nice to include, "For instance, a server might
support several different versions of SPDY, and will select the highest version
that the client supports."
OLD
In that case, the server SHOULD select the most
highly preferred protocol it supports which is also advertised by the
client.
NEW
The server selects the most highly preferred protocol it supports
which is also advertised by the client.
END
OLD
client advertises, then the server SHALL respond with a fatal
NEW
client advertises, then the server responds with a fatal
END
OLD
The "no_application_protocol" fatal alert is only defined for the
"application_layer_protocol_negotiation" extension and MUST NOT be
sent unless the server has received a ClientHello message containing
this extension.
This one really sounds like you're trying to constrain other protocols and *is*
an update to 5246. I think you should just strike this. What do you care if a
different protocol finds a good use for that alert?
OLD
ServerHello SHALL be definitive for the connection, until
renegotiated.
NEW
ServerHello is definitive for the connection, until renegotiated.
END
Finally, by managing protocol selection in the clear as part of the handshake, ALPN avoids introducing false confidence with respect to the ability to hide the negotiated protocol in advance of establishing the connection. If hiding the protocol is required, then renegotiation after connection establishment, which would provide true TLS security guarantees, would be a preferred methodology. I think the writeup actually adds a little missing color. The main point of controversy with this document was on encryption of the extension. The working group decided a cleartext extension with the future general facility to encrypt extensions in TLS 1.3 was preferable to an extension specific encryption mechanism for ALPN. which might be appropiate for the security considerations section.
draft-ietf-ancp-mc-extensions
I'm impressed with the quality and readability of this document. It would be interesting to hear the answer to Brian's 2nd point, but that interest in no way causes me to object to the publication of this document.
There were some changes agreed from the secdir review [1] but I'm not sure if they were (all) done. In particular, point (6) about AAA security seems not to be reflected in the current draft. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04539.html
As mentioned by Mehmet during his OPS DIR review: The document is well-written and thorough concerning the usual requirements for protocol extension specifications. I don't see any real issues from the operations and management pov. Though, it might be in general interesting for such protocol specifications to have a discussion on, e.g.: - configuration parameter and useful default values for buffering, timer values, etc. - protocol scalability and - whether the protocol extensions increase the traffic load, which can be an issue for multicast especially if dynamic sharing of bandwidth between unicast and multicast video traffic on each access line is done. The document has 1 nit comment: -- Possible downref: Non-RFC (?) normative reference: ref. 'PIMreg'
I have no objection to the publication of this document, but I do have questions that I would like to discuss... 1. Am I correct in assuming that the scenarios described in Section 3 are designed around the Home Gateway being a layer-2 bridge? It appears that this document assumes that the Home Gateway does not fit the Routing Gateway description in RFC 5851. 2. Is it possible for the Home Gateway (or a device behind the HG) to use PIM to signal interest in a multicast group to the AN? 3. In Section 5.12 it appears that the Unicast Source Address can only be a fully-specified unicast address. However, the group management protocols allow a requester to specify a set of source addresses for SSM flows (see the definition of Multicast Address Records in RFC 3810). Will this approach send one Multicast-flow TLV per multicast source address (i.e., multiple TLVs with the same multicast group address) ? The example in section 4.3 does not cover that scenario.
draft-ietf-stox-core
Oops, I put this in as a DISCUSS because I wanted to DISCUSS it, but it doesn't meet the DISCUSS criteria, so I've cleared. Sorry for the confusion. I'd still like you to address this, obviously. In the architectural diagram on page 5, it appears that the way the protocol flow goes is that romeo's server sends XMPP to juliet's server, and juliet's server responds with SIP. I don't think this is what you intended—I think that what you intended is that either romeo or juliet could initiate a connection; if romeo initiates, the communication will occur using XMPP, and if juliet initiates, it will occur using SIP.
Need to change affiliation for Peter Saint-Andre?
(Having now read stox-presence, I'm going to make this a DISCUSS point in order to make sure we do have a chat about this point.) - I wondered why you didn't just say that (D)TLS SHOULD be used/supported between gateways. Given that all the relevant bits of code are likely to support that, wouldn't it be a good thing?
- End of s4: "X2S gw" - on a small screen I nearly jumped when I thought that said "X25 gw" (I guess I really do need glasses, sigh:-) - Labelling the figures might be good. - Has anyone thought about confusability in the name mappings? I expected to see a bit of text in the security considerations but didn't see it. - It seems a shame to not be able to gateway when the To is a sips URI at all but I understand that some loss of security is inevitable for cases like this. Is there any work planned for an update that would allow gatewaying for such cases, e.g. if the 1st XMPP server is the one to which the user is connected and the user is connected using XMPP/TLS?
Section 4 is (nicely) clear on the document architecturally describing a gateway. However, traditionally a gateway is transparent to the entity that communicates with it: When we had SMTP-to-X.400 gateways, the gateway appeared as just another SMTP system that noticed special qualities of the address and then routed the messages appropriately. Section 5 describes something a bit different. It's not clear that what section 5 describes actually is part of the gateway, but rather sounds like a combined server which does failover between the protocols. I don't think this is a showstopper, but it might help implementers significantly if you described in section 5 *where* in the model this function occurs. Right now, it sounds like the server itself does the addressing failover, not the gateway.
I assume this is a typo re encrypted/protected: Because XMPP lacks a way to signal that all hops need to be encrypted, Https doesn't necessarily imply encryption it depends on the cipher suite chosen.
draft-ietf-stox-presence
If the protocol between the gateways is not protected via (D)TLS, then doesn't this (and probabaly all other gateway functions) act in a potentially privacy unfriendly manner? I would have thought that worth noting at least, e.g. say that if (D)TLS is not used when gatewaying then the user has lost whatever security they used to have for their presence. (See also my comment on stox-core wrt turning on or requiring implementation of (D)TLS beteen gateways.) Sorry - forgot to note the change resulting from the secdir review [1] just in case it gets forgotten in a rush of some sort. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04581.html
I'm worried that the following might be real interoperability problems. Hopefully quickly cleared: 4.2.2: It seems to me that you need to describe the case where the gateway attempts to do a periodic refresh and it *fails*. Should that mean that the gateway should send an "unsubscribe" to the XMPP user, or should it maintain the XMPP subscription and try again later? Does it depend on the nature of the failure? I'm not sure of the answer, but I think this section should address it. 4.3.1: In any case, if the XMPP-SIP gateway receives a presence stanza of type "subscribed" from the XMPP user, it SHOULD silently discard the stanza and not transform it into a SIP request. Doesn't the gateway need to turn that into a SIP OK in response to the SIP SUBSCRIBE? 4.3.2 and 4.3.3 seem to indicate (example 13) that upon SIP ending its presence session or the user canceling a subscription that both the 'to' and the 'from' subscription be unsubscribed. That seems wrong. Though I can see unsubscribing the 'from', I don't know why you would unsubscribe the 'to'. The XMPP user has not "ended their presence session".
draft-ietf-avtcore-clksrc
- s7: Your 2119 SHOULD statements seem a bit bogus as they don't really translate into what a coder can do but I'm ok with that. - s7: Would it be worthwhile saying that even if you do connect to a time source, you shouldn't use that to adjust your system clock (as opposed to using it to sync some RTP stuff), and if you did, then someone having a video call with you could e.g. cause you to accept a revoked public key certificate and other potential badness? I suppose many devices these days don't allow system clock changes without user interaction, but some e.g. TVs perhaps might not get that right if running on some home-grown operating system.
For a readable doc about NTP AND SDP ... you win the Internet for the day. I did have a couple of comments. Please consider them along with any other feedback you receive. It might or might not belong in an IETF spec, but if there was a pointer to how 4.3. Identifying PTP Reference Clocks Each IEEE 1588 clock is identified by a globally unique EUI-64 called a "ClockIdentity". "globally unique" is ensured, I would have been less curious ... In 7. Security Considerations Entities receiving and acting upon an SDP message SHOULD be aware that a session description cannot be trusted unless it has been obtained by an authenticated transport protocol from a known and trusted source. I'm thinking that's not an RFC 2119 SHOULD.
draft-ietf-idr-rfd-usable
False flap attack? Groan.
Thanks for this simple and sensible document. I'm an insufferable pedant :-( In Section 6 you say "The following changes are recommended" I don't think it matters whether these are changes or not. Maybe "The use of the following values is recommended."
See Barrry's DISCUSS for the latest proposed changes, as agreed during the IESG
telechat; This would solve my DISCUSS. Below is my initial DISCUSS text.
Default Configurable Parameters: In order not to break existing
operational configurations, BGP implementations SHOULD NOT change
the default values in Table 1.
Table 1 mentions
+-------------------------+----------+-------+---------+
| Parameter | Tunable? | Cisco | Juniper |
+-------------------------+----------+-------+---------+
| Withdrawal | No | 1000 | 1000 |
| Re-Advertisement | No | 0 | 1000 |
It's fine to say that Cisco and Juniper SHOULD NOT change their default values,
but you also have to say what another new vendor must be doing for the
Re-Advertisment parameter. The choices are:
1. 0 as default value
2. 1000 as default value
3. 0 or 1000 as default value
Let's not forget that this is a Standards Track document, to which all vendors
want to be compliant.
Proposal:
Default Configurable Parameters: In order not to break existing
operational configurations, BGP implementations SHOULD NOT change
the default values in Table 1. New implementations MUST select either 0
or 1000 for the Re-Advertisment parameter default value.
UPDATED after the IESG telechat:
In the telechat discussion, Joel's explanation and Adrian's analysis were
significant in clearing up what it was that I didn't understand, and in
figuring out how to resolve it. Section 3 looks like general recommendations
of default values, and Section 6 looks like it's telling everyone to use those
default values. The combination is confusing because it appears at the same
time to be specific to two vendors, and yet perhaps to tell other vendors what
values to use. And I'm not sure what to do if I'm a new vendor aiming to
support this.
Section 3 needs to make it clear what the purpose of the table is -- the text
that's there is too minimal for anyone to understand the intent. On the
telechat, we agreed that the following text is clear, and the RTG ADs thought
it correctly reflects what's intended:
OLD (version -03)
The following RFD parameters are common to all implementations. Some
may be tuned by the operator, some not.
NEW
This table shows key parameters for RFD implementations, and lists some
existing default settings for those parameters. Some may be tuned by the
operator, some not. There is currently no consensus on a single set of
default values.
END
The part of Section 6 that talks about default configurable parameters needs to
make it clear that it's not talking just to Cisco and Juniper, and that it's
not telling other vendors to use the specific values in Table 1 (and how could
it, as the values differ between the two vendors listed). On the telechat, we
agreed that the following text is clear, and the RTG ADs thought it correctly
reflects what's intended:
OLD (version -03)
Default Configurable Parameters: In order not to break existing
operational configurations, BGP implementations SHOULD NOT change
the default values in Table 1.
NEW
Default Configurable Parameters: In order not to break existing
operational configurations, deployed BGP implementations SHOULD
NOT change their default values for the parameters listed in Table 1.
END
Still No-Objection, but I support the Barry/Benoit Discusses. Looking back, I said that in previous e-mail on those Discusses but never added it to my ballot position - sorry.
Benoit and Barry agree on the text change, so I am looking using Barry's
proposed text.
As far as I can see the text used by the authors is semantically equivalent
and this is a matter of style, which is outside the DISCUSS criteria.
Because I am unable to see the difference I am unable to explain the
difference to the authors, and am therefore unwilling to force a text
change on them.
OLD (version -03)
The following RFD parameters are common to all implementations. Some
may be tuned by the operator, some not.
NEW
This table shows key parameters for RFD implementations, and lists some
existing default settings for those parameters. Some may be tuned by the
operator, some not. There is currently no consensus on a single set of
default values.
END
The text in -04 actually says:
"The following RFD parameters are common to all implementations. Some
may be tuned by the operator, some not. There is currently no
consensus on a single set of default values."
The title of Table 1 is "Default RFD Paramaters of Juniper and Cisco" which
were the implementations studied.
=======
OLD (version -03)
Default Configurable Parameters: In order not to break existing
operational configurations, BGP implementations SHOULD NOT change
the default values in Table 1.
NEW
Default Configurable Parameters: In order not to break existing
operational configurations, deployed BGP implementations SHOULD
NOT change their default values for the parameters listed in Table 1.
END
The text in -04 says:
"Default Configurable Parameters: In order not to break existing
operational configurations, existing BGP implementations
including, the examples in Table 1, SHOULD NOT change their
default values."
The only significant difference seems to be s/deployed/existing/ which
are semantically the same and i/including, the examples in Table 1/
which is a subset of the statement requested by the discuss holders.
riff on benoit's comment
Default Configurable Parameters: In order not to break existing
operational configurations, BGP implementations SHOULD NOT change
the default values in Table 1.
This is what I'd call the phenomena of least surprise. e.g. don't change
unspecifed (and therefore default values). I'd personally prefer that it say
something like:
Default Configurable Parameters: In order not to break existing
operational configurations, existing BGP implementations inclusive
of the examples in Table 1 SHOULD NOT change default values.
other than that I'm an un-equivocal yes to this.
draft-farrell-perpass-attack
I would really, really, really, prefer this document to go as Informational. I find that it takes a deal of wriggling to make this fit the 2026 description of a BCP (although I will grant that that wriggling can be done successfully). The bulk of the text is set up to provide information about what PM is and how it is considered an attack: only a tiny bit says what we will do about it. That last is the potential BCP bit, but the document really doesn't say enough about what we will do to warrant being a BCP. I am relatively sure that I heard one of the authors say he didn't much care whether it went as Informational. Being Informational ratheer than BCP will address a number of concerns from the community. While I heard many voices saying "make it Informational" I do not recall hearing positive voices for BCP (distinct from people saying you don't need to change it). I don't believe this is a Discussable point, but I think the authors and shepherding AD should thing about this a bit more. --- Each time I read the document I am bothered by the use of "Attack". The problem I have is exactly explained in e third paragraph of the document, but that is too late. The issue is that the term "attack" is being used in a specific context (that of security) in a document that has a wider readership and applicablity. The largest concern I have is evidenced by a number of comments received in reviews, and it is that this specialist usage of a word is not perceived by some readers who then get "upset" by the statement that this is a normal-English-language-meaning attack. The telling point for me is that the Abstract actually sensed this issue and used "technical attack" which is kind of helpful although it is a third term that is not used elsewhere in the document. I took the precaution of talking to a copy editor about how one normally handles this sort of issue, and the answer leads to some simple changes to the text. The general solution is to use "Security Attack" instead of "attack" thereby using a term that fits the paragraph 3 definition and clearly indicates that a specialist maning is being applied. So: - Document title s/Attack/Security Attack/ - Running header s/Attack/Security Attack/ - Abstract s/technical attack/Security Attack/ - Section 1 para 2 s/attack/Security Attack/ twice - and so on throughout the document I fully expect to hear back that this is a fiddling little change that is not worth the effort. I think it is worth the effort and makes a big difference and will happily make the edits. Again, this is not something that can be Discussable, but given that the readership of this document will be wide, it behoves us to get this tone correct. --- Section 1 para 2 PM is distinguished by being indiscriminate and very large-scale, rather than by introducing new types of technical compromise. Could clarification. suggest it belongs in para 1 not inbetween two sentences about the IETF's views. --- Section 1 para 4 The motivation for PM is not relevant for this document, but can range from non-targeted nation-state surveillance, to legal but privacy- unfriendly purposes by commercial enterprises, to illegal actions by criminals. The motivation is not relevant in this document, but we are going to talk about it anyway :-) Great to say it is not relevant. Then stop! But I suspect you wanted to say "We are not specifically targeting governments in this document" in which case, perhaps it *is* relevant for this document. Perhaps what you needed is... The motivation for PM can range from non-targeted nation-state surveillance, to legal but privacy-unfriendly purposes by commercial enterprises, to illegal actions by criminals. The same techniques to achieve PM can be used regardless of motivation. Thus, we cannot defend against the most nefarious actors while allowing monitoring by other actors no matter how benevolent some might consider them to be, since the actions required are indistinguishable from other attacks. The motivation for PM is, therefore, not relevant for how PM is mitigated in IETF protocols. --- The text in the main body carefully says It means that, if asked, there needs to be a good answer to the question "is pervasive monitoring relevant to this work and if so how has it been considered?" Yet other text says should be mitigated in the design of IETF protocols, where possible. The correction is probably s/where possible/where appropriate and possible/ --- Section 2 para 1 Protocols that mitigate PM will not prevent the attack, but can significantly change the threat. Don't agree that all mitigation is only partial. Thus s/will not/might not completely/ --- Section 2 para 2 But those generally do not consider PM Previous sentence has "standards", "mechanisms", and "guidelines". To which does "those" apply? Suggest "those <insert noun> generally" Is "generally" used because we haven't checked all the documents? --- Section 2 doesn't half ramble on. I lack the energy to suggest a reduced version at the moment, but surely it could have been said in a quarter of the number of words. --- Section 3 says: This document was initiated by both the IESG and IAB Perhaps I slept through that meeting. ==== Nits Section 1 para 1 "...can also be used..." I think that "also" is incorrect and should be struck. The previous sentence did not specify any mechanisms. --- Section 2 para 2 confidentiality of protocol meta-data, countering traffic analysis nor data minimisation. [RFC6973] In all cases, there will remain some privacy-relevant information that is inevitably disclosed by The positioning of the citation seems broken. Should come before period?
I'd really like to take a YES on this document (on my principle that you say YES when you'd stand up and sponsor the document yourself if the sponsoring AD got run over by a bus), but I've got the outstanding concern about whether we have consensus, in particular for the status. Jari asked me to review the IETF list archive for the Last Call comments (almost 400 messages). My problem is that, except for Lloyd Wood, there are a bunch of previous opponents of publication as BCP have not said anything since the publication of -04/-05. I'm not a big believer in "silence as assent", especially when it comes to individual submissions. Some of the louder folks (Crocker, Lear, Kent) seem to be OK with BCP at this point, but if I were shepherding this document, I'd be poking some of the folks who were initially opposed to BCP and see how they feel about -05. I'd *really* like to see this as a BCP. A consensus-Informational document is OK, but I don't think it's really where this document belongs. And I'm OK with the consensus being rough. (I think Lloyd's concerns have been sufficiently addressed to call him "in the rough"). But I'd like to get more (at least grudging) consent that the major worries were addressed before making the call.
My previous DISCUSS DISCUSS contained my own thoughts on the topic, was created to start the discussion within the IESG, and was not really actionable (hence the DISCUSS DISCUSS). This discussion took place during the informal telechat. This is an important document, specifically as it relates to network operations and management protocol developments. Not all PMs are attacks. Take IPFIX, take data leakage analysis (done on all traffic existing an enterprise network, IP SLA measurements done all branch offices or all Point of Presence (PoP), etc. These are not attacks. What makes a difference IMO is the notion of network operators managing their network versus the PM being used to gather information outside of the management domain. So adding this notion of "outside the management domain" to PM would make sense to me.
Now, I will try to convince myself that this document is more a statement of principles than an enforcement tool. THE only sentence that goes in this direction is: "An appropriate balance will emerge over time as real instances of this tension are considered." This is pretty light and goes against : The IETF community has expressed strong agreement that PM is an attack that needs to be mitigated where possible, via the design of protocols that make PM significantly more expensive or infeasible. Regardless of what the authors may say now, I have some concerns, as others have expressed during the IETF LC asking for more balance, that this document will be used as an enforcement tool. However, nothing really actionable at this point, except if the community would be ready to add: "this document is more a statement of principles than an enforcement tool." ================================================================== Below is some good feedback fromDan Romascanu (OPS DIR review): The principal impact that this document has on operations and management of the IETF protocol is included in the following paragraph in Section 2: While PM is an attack, other forms of monitoring can be beneficial and not part of any attack, e.g. network management functions monitor packets or flows and anti-spam mechanisms need to see mail message content. Some monitoring can even be part of the mitigation for PM, for example Certificate Transparency [RFC6962] involves monitoring Public Key Infrastructure in ways that could detect some PM attack techniques. There is though a clear potential for monitoring mechanisms to be abused for PM, so this tension needs careful consideration in protocol design. Making networks unmanageable to mitigate PM is not an acceptable outcome, but ignoring PM would go against the consensus documented here. An appropriate balance will emerge over time as real instances of this tension are considered. The text above was carefully crafted and debated during the various reviews I believe that it is OK as it is, but the OPS community should debate whether work is necessary in the area (maybe in the OPSEC WG) in order to look at the following aspects: - Issue recommendations that could help protect the tools (applications, protocols, data repositories) used by operators for the day to day tasks or running and managing the networks from being used for pervasive monitoring (in the words of the document – how can we make sure in practical terms that useful monitoring mechanisms are not abused for PM?) - Review the existing protocols designed in the OPS area which have broad deployment and make sure that they have been designed in such a manner that the threat of a pervasive monitoring attack can be mitigated. If necessary (gaps were found out) issue recommendations for ‘ruggedizing’ these protocols against PM attacks A few more observations: - In Section 2 the following sentence is IMO not clear enough: ‘It means that, if asked, there needs to be a good answer to the question "is pervasive monitoring relevant to this work and if so how has it been considered?"’ Who asks? Is this about the IESG reviews, or maybe about some kind of privacy assessment (done by whom?) - I found too little relation between this document and RFC6973. That Informational RFC provides actually a set of good recommendations on mitigation for privacy issues, many of them directly applicable against PM threats. It is also a very recent document, published only six months ago. It seems odd that the information[RFC6973] is mentioned only once and in an unclear way – the reference is just written in brackets between two sentences, not clear if it belongs to the sentence before or the sentence after.
Recognising that we could quibble about wording until the document is entirely
overtaken by events (such as the death of the known universe), I'll throw in a
couple of comments, which you're free to opt out of with no reply needed.
The term "attack" is used here in a technical sense that differs
somewhat from common English usage. In common English usage,
I would strike the second sentence ("In common English usage...") entirely, as
it only serves to bring the inapplicable sense to the reader's attention. Just
go straight from the first sentence right into, "The term is used here...."
We also use the term in the singular here, even though PM in reality
may require a multi-faceted set of coordinated attacks.
I'd say "consist of", rather than "require".
Thus we cannot defend against the most nefarious actors while
allowing monitoring by other actors no matter how benevolent some
might consider them to be, since the actions required are
indistinguishable from other attacks.
"the actions required" seems odd here. I think it refers to the actions
required for defense, but then it says they're indistinguishable from attacks.
I think the best fix is something like this:
NEW
Thus we cannot defend against the most nefarious actors while
allowing monitoring by other actors no matter how benevolent some
might consider them to be, since the various actors are
indistinguishable from each other in this regard.
END
This can significantly increase the cost of
attacking, force what was covert to be overt, or make the attack more
likely to be detected, possibly later.
Isn't making what was covert overt also making in detectable? This seems
repetitious.
I'm mostly OK with the text in -05, but in section 2, I'm concerned that the draft is accurately reflecting conflicting goals: - we need to mitigate PM - we need to allow limited-scope monitoring - we can't tell the difference in any technical way, so - I'm not sure we can do both at the same time Do we think we can figure that out? Without resorting to http://www.nancyclaxton.net/uploads/3/4/6/9/3469502/525284.jpg, of course.
This DISCUSS is a placeholder until we can determine the right status (BCP or Informational) for this document. No action is needed as the IESG will resolve this on the telechat.
Adrian in his comment of 2014-02-01 articulates extremely well points that have been giving me cause for concern since the first version of this text was put forward, and continue to give me concern. To pick the most important points it is my view that the unqualified use of the word "attack" in most places in the text, whilst sensational does a dis-service particularly in its wider operational context. Secondly I am concerned that PM, or techniques similar to PM have a valid law enforcement use, and that to make PM infeasible (section 1 para 2) would not be in the best long term interest of the IETF designed Internet. The text: "While PM is an attack, other forms of monitoring can be beneficial and not part of any attack, e.g. network management functions monitor packets or flows and anti-spam mechanisms need to see mail message content." can be construed to permit the use of PM or similar techniques in law enforcement but it would be better to explicitly note this. I am also concerned that the lack of explicit guidance on what is needed in IETF specifications will cause difficulties with future RFCs resulting in inconsistent application of the advice in published RFCs. I accept however that there is a strong desire by many in the IETF to submit text for publication before the London meeting, and therefore consider that I should abstain from further discussion.
Some monitoring can even be part of the mitigation for PM, for example Certificate Transparency [RFC6962] involves monitoring Public Key Infrastructure in ways that could detect some PM attack techniques. There is though a clear potential for monitoring mechanisms to be abused for PM, so this tension needs careful consideration in protocol design. In fact there are a number of activities that might fall under the rubrick of pervasive monitoring or in same cases pervasive counter-surveillance (certificate pinning comes to mind for the later) that seem necessary in order to detect more active forms of subversion. This tension with respect to exposure to monitoring also touches on the question of consent, the receiver of unsolicited requests may necessarily have rather different concerns than the sender and that may well result in inputs to protocol design/implementation/usage inconsistent with our concerns.
status-change-5343-5590-5591-6353-to-internet-standard
draft-ietf-rtgwg-cl-requirement
Updated after discussion with the Editor. --- I am not going to insist that section 3.2 is removed, but this section seems to me to be out of place in this document. I would be pleased to see it go, but am not exercised by its presence. The reasoning for removing it is that there is nothing here that describes the behaviour of AMGs per se. Instead the text is about how information about links is reported from one layer to another. --- It would be nice if the concise "Abstract Multipath" definition in the Abstract were copied to the Intro. --- Andy Malis may want to change his coordinates.
Non-blocking comments: please consider them, and chat with me if you like...
but no response is required.
-- Section 3.5 --
FR#22 Load balancing MAY be used during sustained low traffic periods
to reduce the number of active component links for the purpose of
power reduction.
I'm very suspicious of "MAY" in requirements -- what does it mean here? The
fact that load balancing is entirely optional doesn't seem like a "requirement".
The same is true of GR#4 in Section 4.
draft-ietf-insipid-session-id-reqts
(1) REQ4 is almost nice:-) However, I think you need to say something about correlation over time. For example, I assume it ought not be possible to know just from looking at session ids (even if the operator knows how they're generated in intimate detail) that they correspond to the same (sets of) user(s). I note that the WG charter has some similar language about correlation. (2): I assume that the solution draft will contain more privacy considerations related to the use and storage of these identifiers, however, you say here that they are to be usable days or weeks after a call, so don't you also need to say that a solution needs to describe the security and privacy issues related to storage of identifiers? (Since there is a real possibility that e.g. leakage of logs would expose who has been calling whom for how long.) (3) DISCUSS-DISCUSS, this is for the IESG, the authors needn't worry about it. IPR: There are 3 delcarations (two really I guess) on this *requirements* document, which I don't understand at all. But whatever, if the WG are ok with that, then its ok I guess. However, the sponsoring AD is one of the folks who declared IPR and is listed as an inventor on the referenced patent application. Is that kosher process-wise? I've not seen it before that I recall so just want to check. I think it would be cleaner if that were not the case.
3.1 - as-is, the term session is so ill-defined in this section that it could be considered to be ok for a session to last a year. It might be worth just saying here its meant for what a user would consider a call in most common cases. 3.1 - you confused me:-) 3rd para says "three parties" but earlier you said "exactly two." I think what you mean is that the term party might have different meanings in different protocols? (It becomes clear later though.) 4.3 - if a privacy enhancing B2BUA is present, then I don't think I buy the proposition that it won't mess with the session id. 4.4 - typo s/where/were/ 4.6 - first use of "restrictive" seems wrong. I think you mean lax or maybe expressive or permissive (as the secdir review suggested). 5 - REQ9 could contradict what I'd like to see in REQ4. (Just noting that.) 7 - saying you MUST NOT use MAC address etc is not right. You could use those, so long as they cannot be derived from the session ID, e.g. "AES(k,MAC||random)" could be used for a k known only the the initiator perhaps. I'm not saying you should do that, but that the MUST NOT seems OTT. 7 - I don't get how the integrity requirements stated can be independent of the n/w infrastructure etc. To me, that reads like text added to just sound good, so I must be missing something about it - can you explain the last paragraph a bit more?
So, I really want a session ID (and I have since before I co-chaired SIPCLF,
which needed such a thing), and I really want to ballot "yes", but I'm
confused. Could you clue me in?
I'm looking at this text:
3.1. What does the Session Identifier Identify?
How the endpoints determine which signaling messages share a given
identifier (that is, what constitutes a single invocation of a
communication application) is intentionally left loosely defined.
The requirements in this document put some constraints on what an
endpoint will consider the same, or a different, invocation of a
communication session. They also ensure that related sessions (as
this document is using the term) can be correlated using only the
session identifiers for each session. Again, what constitutes a
"related" session is intentionally left loosely defined.
as saying pretty much "a session is whatever I say it is", and I'm looking at
this text:
3.2. Communication Session
The following are examples of acceptable communication sessions as
described in Section 3.1 and are by not exhaustive:
^^ typo? but that's not my point
o A call directly between two user agents
o A call between two user agents with one or more SIP middleboxes
in the signaling path
o A call between two user agents that was initiated using third-
party call control (3PCC) [7]
o A call between two user agents (e.g., between Alice and Carol)
that results from a different communication session (e.g., Alice
and Bob) wherein one of those user agents (Alice) is transferred
to another user agent (Carol) using a REFER request or a re-
INVITE request
The following are not considered communication sessions:
o A call between any two user agents wherein two or more user
agents are engaged in a conference call via a conference focus:
o each call between the user agent and the conference focus
would be a communication session, and
o each of these is a distinct communication session.
o A call between three user agents (e.g., Alice, Bob, and Carol)
wherein the first user agent (Alice) ad hoc conferences the
other two user agents (Bob and Carol)
o The call between Alice and Bob would be one communication
session.
o The call between Alice and Carol would be a different
communication session.
which gives *examples* of what is, and is not, a session, but I'm not seeing a
clear description that would let me figure out whether a call that doesn't fit
one of these categories is a session, and the text says the examples aren't
exhaustive.
Are these two lists of examples, taken together, just saying "any call with
exactly two endpoints can be a session, and a call with any other number of
endpoints can't be a session"? Is there any other requirement?
Am I missing something?
In 3.3. End-to-End The term "end-to-end" in this document means the communication session from the point of origin, passing through any number of intermediaries, to the ultimate point of termination. It is recognized that legacy devices may not support the end-to-end session identifier, though an identifier might be created by an intermediary when it is absent from the session signaling. is the last sentence talking about an intermediary that supports this specification creating an identifier if a legacy endpoint hasn't created one? I'm guessing so, based on REQ5: It must be possible to identity SIP traffic with an end-to-end session identifier from and to end devices that do not support this new identifier, such as by allowing an intermediary to inject an identifier into the session signaling. but I'm guessing. In 4.2. Protocol Interworking It is expected that the ITU-T will define protocol elements for H.323 to make the end-to-end signaling possible. I'm sensitive to Stewart's comment - perhaps it's more diplomatic to say something like "if ITU-T defines the corresponding protocol elements for H.323, end-to-end signaling will be possible in the presence of protocol interworking".
It is expected that the ITU-T will define protocol elements for H.323 to make the end-to-end signaling possible. This looks like the IETF making a demand on the ITU. Perhaps "It is anticipated..."? Are there any privacy considerations associated with this identifier?
draft-ietf-clue-telepresence-requirements
No big deal, but... REQMT-1c: Seems to allow locations to be a bit too global and overly-precise, at least potentially. I mean this'd allow for a fine-precision global lat, long, alt to be used, rather than some relative/local dimensions. If this were a protocol that proposed such gloabl fine-grained location be used I'd DISUCSS that, but since this is probably just a little loose and could be implemented without such problems, this is just a nit really. (Similar comment for all REQMTs that say "identify in 3d" or similar.)
It would be helpful to expand "CLUE" at some point.
draft-crocker-id-adoption
""" In formal terms, a working group raises and discusses each item of document content. For difficult topics and/or difficult working group dynamics, this is the required mode. """ This requirement is both inappropriate for an informational document and false in practice. The first sentence of the Introduction and the Security Considerations sentence are both awkward grammatically.
general: The title is too broad, it only covers adoption, and not e.g. WGLC. I'd say s/Handing/Handling Adoption/ in the title would be better. (Apologies in advance that this piles on from the secdir review;-) 1.1 - "with advancement for publication as an RFC requiring rough consensus in the working group" might confuse a new IETF WG participant into thinking that IETF LC is not needed for advancement as an RFC. Maybe add a bit about IETF LC? 1.1 - I wonder would "In contrast, individual submissions..." be clearer in the 3rd para just to help the reader know we're done describing things usually named draft-ietf-wgname? 1.2 - The WG having "final authority" again sounds like it ignores IETF LC. I think you mean that the WG and not the authors/editors have control but as written it could be read to imply more, which seems a pity. 4 - "Absent charter restrictions, a working group is free to create new documents." That seems a bit broad, would it be better to say "that sensibly fit withing the overall scope of the WG's charter" or some such? 4 - "well-deployed market" I think you mean that the technology is well-deployed, but you don't need any commercial products to exist really. I'd say rephrasing to not say "market" would be easy and better. 5.2 - "released to them" is odd - do you need to say that? Maybe better to just say that if a WG drop a draft then anyone can pick it up as an individual submission, subject to the boilerplate copyright stuff.
Section 4: I'd like to see somewhere (perhaps in the "For example" paragraph) something like: Conversely, even a deployed technology with a solid base may be inappropriate to deploy at Internet scale, and while a document specifying such a technology might serve as a good starting point on which to base a new specification, undermining of the deployed base might be completely appropriate. It will all depend on the constraints of the charter and the analysis of the working group. The current text seems to concentrate on one side of the issue.
OLD:
Authors serve at the
pleasure of the working group chairs, and are subject to
replacement for a variety of reasons.
NEW:
Editors serve at the
pleasure of the working group chairs, and are subject to
replacement for a variety of reasons.
The authors are based on contributions.
Section 2.2
OLD:
* Is the topic of the I-D within scope for the working group?
NEW:
* If there is no charter milestone but the topic falls within the scope
of the charter?
The charter is key, not the working group.
Section 2.2 REMINDER.
This is specifically important to note when an author bring his own (company)
proprietary protocol as a WG document.
My "yes" isn't an opinion about Benoit's Discuss (I'm assuming we'll discuss
it).
I can't express my admiration enough for Adrian and Dave taking this on. And
I'm really trying to behave.
I haven't tried to compare this non-normative guidance to the non-normative
guidance in the current WG Leadership tutorial. If no one else has, is it worth
asking someone to do that?
I can't put my finger on why, but I'm more comfortable with "common" than with
"typical". "Common" seems to be used most of the time in this draft, and feels
even less normative.
In 1.1. What is a Working Group Draft?
Documents under development in the IETF community are distributed as
Internet Drafts (I-D) [RFC2026], [ID-Info]. Working groups use this
mechanism for producing their official output, per Section 7.2 of
[RFC2418] and Section 6.3 of [Tao]. The common convention for
identifying an I-D formally under the ownership of a working group is
by the inclusion of "ietf" in the second field of the I-D filename
and the working group name in the third field, per Section 7 of
[ID-Guidelines]. That is:
draft-ietf-<wgname>-...
In contrast, individual submissions are drafts being created and
pursued outside of a working group, although a working group might
choose to adopt the draft later, as discussed below. Anyone is free
to create an individual submission at any time. Such documents are
typically distinguished through the use of the author's last name, in
the style of:
draft-<lastname>-...
This discussion is accurate, but I wish it went one step farther, and pointed
out that it's common for people to assume that draft-<lastname>-... drafts
aren't working group drafts and pay less attention to them (it always broke
Steve Coya's heart when we pointed out that people don't always look at the
working group charter page to figure out which drafts are working group drafts).
This discussion doesn't include the draft-<lastname>-<wgname>... convention
mentioned in Section 5.1, and I encounter a bunch of folks who based what
drafts they look at on that convention. That might also be worth mentioning.
Similarly, in 5.2. WG Drafts Can become Individual Drafts
A working group is not obligated to retain documents it has adopted.
Sometimes working group efforts conclude that a draft is no longer
appropriate for working group effort. If a working group drops a
draft then anyone is permitted to pursue it as an Individual or
Independent Submission, subject to the document's existing copyright
constraints.
it might also be worth mentioning that there's no requirement to change the
draft filename back to the draft-<lastname>-... format if you pursue it, but
people are likely to assume it's still a working group draft.
The discussion in 3. Authors/Editors is about right. It might be helpful to
observe that even this loose distinction between authors and editors has
evolved over time.
A few comments: "Other than for selection of document authors/editors, as discussed in Section 3, working group decision-making about document management is subject to normal IETF process rules. " Surely the selection of chairs is "subject to normal IETF process rules"? I think you mean to distinguish between the decision making of the WG vs the decision making of the chairs on a document, but both are subject to IETF rules, including appeals. === "Is there a charter milestone that explicitly calls for such a document? "Is the topic of the I-D within scope for the working group?" Isn't the former a subset of the latter? === Although the selection of authors/editors is the remit of the chairs it might be worth noting that a wise chair will give regard to the consensus of the WG on their suitability for the task.
1) General: Is it also worth mentioning that upon adoption, the chair/author should send in a replaced by email so that folks can track the progression of the draft from individual -> wg -> RFC. This is especially important if there's IPR on the individual draft. 2) s2.1: Step 1: I think that we need a bit more on this topic. The times I've dealt with giving over change control it's been a bit more formal - authors submit an individual draft explicitly stating they're giving change control. That draft gets published as informational and then the WG takes over. My point is reminding the authors might not be enough. 3) s2.1: I think the first typical step you've missed is that it's not normally the chairs who just come up with the idea that a draft should be adopted - they get lobbied by authors to actually make that call. There's usually two ways this can be done - privately through an email to the WG chairs or publicly by just blasting it off to the list. I think a lot of folks don't know this and different WGs prefer one or other or don't care. This seems like an important step to note in s2.1. 4) s2.2: Are the 1st two bullets kind of the same thing? 5) s2.2: I guess I don't understand this one: Does the document provide an acceptable platform for continued effort by the working group? 6) s3: Worth mentioning that if the individual draft's authors aren't selected it would be nice if they were at a minimum list in the acknowledgements section or in the contributors section? 7) s5.1: I assume the following is code for the individual draft can be WGLCed without being submitted as a WG draft: Such documents can be handled according to normal, internal working group process management. If so I'd be better to make that clear. If not, I think we need to make it clear that there's no requirement that when a WG adopt the draft that it MUST be resubmitted named as a WG draft.
conflict-review-saintandre-jabberid