IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2013-04-25. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Benoit
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=NBGD | I | resv. | block length = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold | Packets Discarded in Bursts |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Packets expected in bursts | Reserved. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
2.3 Status Changes
2.3.1 New Items
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
3.1.2 Returning Items
Telechat:
3.2 Individual Submissions Via AD
3.2.1 New Items
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
Telechat:
3.4.2 Returning Items
1203 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
4.2.2 Proposed for Approval
Telechat::
1230 EDT break
1234 EDT back
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Agenda Working Group News
JohnL: question of scribe coverage for retreat
Jari: Sue was planning to, but iffy
Russ: may be time to ask for more scribes
1312 EDT Adjourned
(at 2013-04-25 07:30:17 PDT)
draft-ietf-mpls-tp-ethernet-addressing
"You might want to review your RFC 2119 usage before passing this to the RFC Editor."
- section 2, 2nd last para on p3: I'm not clear whether an implementation MUST process frames sent to 01-00-5e-90-00-00 if the implementation doesn't know that the link is point-to-point or knows that the link is not point-to-point. You could also maybe be clearer about what "MUST process" means, not sure if that's obvious or not (maybe it is), but if I send a huge chunk of garbage bytes to that MAC address, would all be well? Maybe such fuzzing would also be worth a security consideration? (Not sure, maybe that's covered elsewhere or ought be covered elsewhere.) - section 4, is "maximum frame size octets" a typo? Maybe "in octets" was meant? - section 4, MFS == 2^32-1 seems very big. Is there a potential DoS vector there? Maybe a bad node could set this huge to try get the peer to buffer too much stuff or something? Ought implementatations also have their own max-max value or generate an alert or something if a too-big MFS is received? You already mention a too-small MFS in the security considerations, so maybe this is also worth a mention? - section 6: I'm not sure of the real use-cases for this, but are there cases where you really really ought to be turning on the authentication defined in mpls-gach-adv? If there are, wouldn't it be good to describe those a bit and say that they do really need to use the crypto stuff?
(Updated to a comment, based on feedback.) A new Gen-ART review recently arrived on this document. Can the authors, shepherds, or sponsoring ADs take a look and see if there is something that you think should be addressed? The review is at http://www.ietf.org/mail-archive/web/gen-art/current/msg08439.html and also copied below. Also, regarding the S7.3 comment, we do often use IANA policies of the form "<policy> or IESG Approval", because it allows an IESG approval for the eventual special case. I would consider this model for this document as well. ------- Martin Thomson's Gen-ART review: Summary: This document is almost ready for publication as proposed standard. There are some minor issues Major issues: None Minor issues: The structure of the document is odd. The individual pieces of explanation are good, it's just that different bits are revealed in a strange order. If the intent is to describe a method of selecting an Ethernet address to attach to MPLS-TP packets, I would have thought that structuring the document to correspond to the prioritization of methods would make sense. That is, from what I can infer: If unicast, use a unicast address (MUST for multipoint attachment, SHOULD for others) 1. from G-ACh, if available 2. from static configuration, if operationally feasible otherwise, for point-to-point links you can use 3. the IANA-assigned special address 4. FF-FF-FF-FF-FF-FF Reordering might help with understanding the process. If multicast/broadcast LSPs, there doesn't seem to be any actual recommendations or advice in the document. There is only an admonition to use encapsulation, which is probably necessary for other reasons anyhow. So it's not clear how Section 3, paragraph 1 is relevant to this document. It doesn't offer any guidance on how one might select an appropriate Ethernet address for those frames. Presumably these could be unicast, multicast or broadcast depending on routing requirements for the LSP, in which case maybe there is no good advice to give. If there really is no good advice to give, or there is no intent to provide advice for multicast/broadcast LSPs, a statement to that effect would be helpful. Section 3, Paragraph 2 just reiterates parts of Section 2, it could be removed. S5: I can't reconcile "The advertised information SHOULD be persistent across restarts." with "Received advertisements MUST be discarded across restarts." S4, pp5: Why force a mapping to EUI-64? Is canonicalization important for some reason? S4, pp5: The paragraph beginning with "In the event a GAP message is not received within the previously received associated Lifetime, ..." is a little confusing (and I'm familiar with G-ACh already). This could be clearer. Maybe: "A node could cease transmission of G-ACh advertisements, or cease to include a Source MAC Address TLV in advertisements, either of which cause the TLV lifetime to elapse. After the Source MAC Address TLV lifetime has elapsed, this value SHOULD no longer be used to select a MAC address; the node SHOULD return to selecting MAC addresses as though no advertisements were received." S7.3: IETF review is a pretty high bar. (Sadly, I missed this on G-ACh, or I would have made the same comment.) Did you consider allowing IESG Approval as an alternative? Nits/editorial comments: There are a couple of lowercase instances of RFC2119 keywords that could be confusing. The very last line of S4, the second last sentence of S2. Consider alternative wordings for these statements. S2, pp3: s/i.e. /i.e., /
No objection to the publication of this document, but please address the two points below. Note: I discussed those points with Stewart, and we agreed that the text needs to be improved. 1. There are 2 SHOULD in the following paragraphs: ... If existing mechanisms are available in an MPLS-TP network to determine the destination unicast MAC addresses of peer nodes -- for example, if the network also happens to be an IP/MPLS network, or if Link Layer Discovery Protocol (LLDP) [LLDP] is in use, or if it implements the procedures in Section 4 of this document -- such mechanisms SHOULD be used. The remainder of this section discusses the available options when this is not the case. ... In view of the above considerations, the approach which SHOULD be used, is therefore to configure both nodes to use the method described in this document which uses, as a destination MAC address, an Ethernet multicast address reserved for MPLS-TP for use over point-to-point links. If I have ARP or LLDP, the first SHOULD apply. However, there is also a SHOULD for the new mechanism in this document. So which method should I use as a default? Discussing with Stewart, the authors should make it clear that 1. If ARP/LLDP is/are available, they are the preferred methods 2. If ARP/LLDP is/are not available, rather than using the hand configured unicast or the broadcast address mechanisms, use the 01-00-5E-90-00-00 mechanism 2. Manageability Considerations Because this mechanism proposed in this document relies on point-to-point interfaces only, you're missing that the interface type, whether point-to-point or multi-point, must be clearly labeled, and this information must be available to the network operator. Any changes of interface type must be notified to the network operator. See my next email to the OPS-DIR on this topic.
Just a couple of editorial nit-picks... 1. I don't think I have ever heard of "Ethernet Address Resolution Protocol (ARP)". Since ARP works on links other than Ethernet, I would suggest dropping reference to Ethernet. This standardizes the description of ARP in the same way NDP is described. 2. The references [EUI-64] and [LLDP] have all sorts of extraneous punctuation that can be cleaned up.
I would observe that you should never use garp or ndp messages for 01-00-5E-90-00-00 to update an L2 next hop which gets back to the question of what is or isn't point to point. I don't know that, that observation needs to make it into the text so no objection.
draft-ietf-ospf-ospfv3-iid-registry-update
The introduction doesn't really lead into Section 2 with any explanation. We just have a statement of a problem that exists in the introduction, and then a statement about a change to the registry in section 2, with no text at all stating how this solves the problem. What I was no doubt naively wondering was why this wasn't being handled through more specific allocations, rather than a private allocation with no rules. I assume it's because you don't want to reserve iids for all time for transition technology, but it would be good if that were stated explicitly. I don't have a strong objection to this document, but it would be awfully nice if there were an additional glue paragraph in there somewhere explaining the leap from problem to registry update.
Thanks for this document. It would be nice if the Abstract included a second paragraph... This document updates RFC 5838 that includes the base definintion for the modified registry. --- Section 1 As this document will (presumably) be published as an RFC and cause the registry to be updated, the text in Section 1 will become confusing: The following table lists the value ranges as currently allocated. How about... The following table lists the value ranges as allocated for RFC 5838. --- You could either delete the change log, or add a note to the RFC editor that they can remove it upon publication.
I'd like to thank Ben Campbell for the Gen-ART review.
The abstract is completely unhelpful. It should say what sort of modification is being made. Suggested: """ This document modifies the "Unassigned" number space in the IANA "OSPFv3 Instance ID Address Family Values" registry. The current "Unassigned" space is divided into two halves, one half "Unassigned" but managed via Standards Action, and one half reserved for private use. """
No objection to the publication of this document, but please improve the following, which confused me. For example, [I-D.ietf-ospf-ipv4-embedded-ipv6-routing] describes an application in which IPv4-embedded IPv6 addresses are used to transport IPv4 packets over an IPv6 network. While the IPv4-embedded IPv6 addresses do in fact represent IPv6 destinations, it would be operationally benefitial to be able to easily identify the the specific application by having a separate space to do so. My first impression was: it doesn't make sense to embed a protocol hierarchy (as we call it in the DPI world) into an OSPF instance, so you surely want the "private use" range. On top of that "unassigned - Standard Action" was already available in the registry. After thinking so more about it, I'm not sure any longer that you intend "private use", and http://tools.ietf.org/html/draft-ietf-ospf-ipv4-embedded-ipv6-routing-11#section-13 doesn't help. Regardless of whether it's right or wrong to embed a protocol hierarchy into the OSPF instance (this will be a discussion for raft-ietf-ospf-ipv4-embedded-ipv6-routing), since you use this example as a justification for this document, express if the example is supposed to use "private use" or "reserved". In other words, why "unassigned" doesn't work
I agree with adrian that it would be convenient for the reader if the document specified what it was updating in the abstract.
draft-ietf-xrblock-rtcp-xr-burst-gap-discard
There are a couple of things, esp. [DISCARD] that appear like they ought be normative references here, or am I wrong? If I'm not wrong, then making [DISCARD] normative will sort this discuss. Otherwise, I'm concerned that [DISCARD] could change in ways that break code after we've approved this one, causing a bit of a mess. For example, see my comment on 2.1 below, where a change to [DISCARD] could cause the numbers reported by an implementation of this to be wrong if that implementation was based on [DISCARD] vesion -12. (The other things that ought be normative are an RFC and a draft in the RFC editor queue so aren't a discuss-level problem for me.)
- 1.1, I don't get why [DISCARD] isn't a normative reference if this extends that. (I think something ought be a normative reference if I need to read it to implement this.) - 1.4, I wondered if "contain jitter buffers" would be clear enough for all readers. Since this is the bit where you say when this is applicable, maybe its worth being extra-clear here? (E.g. I'm not entirely sure I know exactly what a "jitter buffer" might be.) - 2.1, definition of Discarded: you seem to be saying that a packet is only counted as discarded if it arrives early or late, but what if it arrives on-time, but contains crap? Maybe that ought be fixed in xr-discard as well as or instead of here? (I'm also a little surprised that we have this on the telechat before [DISCARD] which this extends. Is that a good idea?) - section 3, isn't RFC 6776 also a normative reference? - 3.1, why do you define what I=01 means, but then say it MUST NOT be sent and MUST be discarded? That seems odd. - 3.3 looks to me like [SUMSTAT] is also a normative reference based on the last sentence here. - There were a couple of nits found in the secdir review [1] where the authors seemed to want to tweak things. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03914.html
No problem with the publication of this document.
However, before doing so, I have 2 points I want to address: I'm missing
something, and I don't know what.
1.
In this sentence, I wonder which jitter calculation you were speaking about:
The new block type
supports the reporting of the proportion of packets discarded by the
receiver due to jitter. The discards during discard bursts are
reported, together with the number of bursts. This block is intended
to be used in conjunction with [DISCARD] which provides the total
packets discarded, and on which this block therefore depends.
However the metric in [DISCARD] may be used independently of the
metrics in this block.
I know of the two methods [RFC 5481]
4.1. IPDV: Inter-Packet Delay Variation ........................11
4.2. PDV: Packet Delay Variation ...............................11
Or maybe the results are independent of the jitter calculation method, in which
case you want to clearly mention it. Maybe it's explained with this sentence,
but I don't know how to interpret it:
To accommodate the range of jitter buffer
algorithms and packet discard logic that may be used by implementors,
the method used to distinguish between bursts and gaps may be an
equivalent method to that defined in[RFC3611].
So it "may be an equivalent method to that defined in[RFC3611]."
What if it's not the case?
2.
You define "Discarded" as:
A packet that arrives within
this time window but is too early or late to be played out or
thrown away before playout due to packet duplication or redundancy
shall be regarded as discarded.
I wonder: what's the point to include the discarded duplicated packet. Those
don't affect the quality. On top of that, it's inconsistent with "Discard"
definition of RFC 3611. You wrote in the draft:
The definitions of Burst, Gap, Loss and Discard are consistent with
definitions in [RFC3611].
And RFC 3611 Discard mentions:
discard rate: 8 bits
The fraction of RTP data packets from the source that have been
discarded since the beginning of reception, due to late or
early arrival, under-run or overflow at the receiving jitter
buffer. This value is expressed as a fixed point number with
the binary point at the left edge of the field. It is
calculated by dividing the total number of packets discarded
(excluding duplicate packet discards) by the total number of
packets expected, multiplying the result of the division by
256, limiting the maximum value to 255 (to avoid overflow), and
taking the integer part.
So you want to report the "Packets discarded in bursts", i.e. "The total number
of packets discarded during discard bursts."
EDITORIAL
-
This block provides information on transient IP problems. Burst/Gap
metrics are typically used in Cumulative reports, however they also
may be used in Interval reports.
Cumulative -> cumulative
Interval -> interval
Unless those are definitions ... in which case they need a reference.
Reading further, I understand that you refer to:
I=10: Interval Duration - the reported value applies to the
most recent measurement interval duration between successive
metrics reports.
I=11: Cumulative Duration - the reported value applies to the
accumulation period characteristic of cumulative measurements.
You need a reference
OLD:
This block provides information on transient IP problems. Burst/Gap
metrics are typically used in Cumulative reports, however they also
may be used in Interval reports.
NEW:
This block provides information on transient IP problems. Burst/Gap
metrics are typically used in Cumulative Duration reports, however they also
may be used in Interval Duration reports (see the Interval Metric flag in
section 3.2).
Note: there are many instances of capitalized words, for which I'm not too sure
if we deal with a definition, or if it's just a bad habit to capitalize term in
this industry. Example
If Voice Activity Detection is used, the Burst and Gap Duration shall
be determined as if silence packets had been sent, i.e. a period of
silence in excess of Gmin packets will terminate a burst condition.
The recommended value for the threshold Gmin in [RFC3611] results in
a Burst being a period of time during which the call quality is
degraded to a similar extent to a typical Pulse-Code Modulation(PCM)
Severely Errored Second.
Please be consistent.
-
"The definitions of Burst, Gap, Loss and Discard are consistent with
definitions in [RFC3611]." This sentence should be in the terminology section,
and not section 1.1
-
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=NBGD | I | resv. | block length = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold | Packets Discarded in Bursts |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Packets expected in bursts | Reserved. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bursts and burst in the same picture. Pick one.
- To finish on the positive note, thanks for the RFC6390 template.
draft-ietf-idr-as-private-reservation
It would be nice if the operational considerations gave stronger advice about the use of AS_PATH filtering to mitigate the leakage of these private use ASNs onto the internet. I suppose people reading the document probably already know what to do, though, so I'm not insisting on this change--I'd just like to point out that the advice is perhaps more gentle than is warranted.
Good work, thanks. Would be nice if section 7 supplemented what it says with a pointer to where the security considerations for private use AS numbers are to be found.
The value 94,967,295 appears odd to me, I expected a power of 2, but maybe that's just my binary-bias and I'm not decimal-diverse enough;-)
I support Joel's DISCUSS
Private use IPv4 addresses resulted in the AS112 project (RFC 6304). Is something similar needed for private AS #s that are leaked to the internet? On Adrian's point, I went and looked in RFC 1930 and it doesn't really say what bad things can happen. The contents of that security consideration section are as follows: There are few security concerns regarding the selection of ASes. AS number to owner mappings are public knowledge (in WHOIS), and attempting to change that would serve only to confuse those people attempting to route IP traffic on the Internet. Whatever bad thing can happen is mitigated by the MUST NOT be advertised, but maybe some words about what bad things can happen if they are leaked would be warranted - especially now that you're reserving so many more #s.
The operational considerations section does not discuss the interaction between 4 byte private ASNs and 2 bytes speakers that only see AS_TRANS. While 4 byte capable participants/networks will readily be able to distinguish private ASNs via simple policy filters. Two byte bgp speakers are blind to them If I recall. The could result in either unintentional or deliberate mischef. I do not believe that the must in the first sentence can be enforeced by a two byte speaker. If Private Use ASNs are used and prefixes are originated from these ASNs, which are destined to the Internet, Private Use ASNs MUST be removed from the AS_PATH before being advertised to the global Internet.
While I recognize the 4 byte asn is some 4 billion ASNs the notion that the reservation should be 94 million ASNs seems a bit excessive. I also realize that has been discussed in some detail in the process of getting to this point.
draft-ietf-dnsext-dnssec-algo-signal
1. The combination algorithm for recursive resolvers seems backwards; it results in a list of algorithms such that at least one of the stub and recursive resolvers can validate. It seems like you would want to know how many clients there are out there for which you MUST use a given algorithm. Since either the stub or recursive resolver can fail the resolution on validation failure, you would thus want the intersection of the two lists, not the union.
Why is there a need for separate DHU and N3U options? It seems like if an implementation has a hash, then it has the has. Are there real implementations for which these differ?
- abstract: the draft does stuff, it doesn't "set out to" do stuff, at least not anymore - section 4: not sure if the write-up is a bit out of date, but personally I prefer the text in -10 of the draft to using "[RFC525-422]" as given in the write-up - section 7 or earlier: it'd be nice to point at the IANA registries if those had stable URLs. I can never remember if they do or not;-) - section 8: I think you maybe ought add another security consideration something like: 'If a client continues to support a "broken" algorithm that would allow an attacker to prepare bogus but cryptographically valid DNS responses then advertising that fact via this extension could make it easier for the attacker to exploit such a vulnerability. The solution for such clients is to remove support for such "broken" algorithms as soon as possible.' - The secdir review [1] mentioned a possible DoS. I don't see the threat myself, but it'd be good if the authors responded to that, just in case. (Sorry if you've done that already and I missed it.) [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03919.html
Overall issue: I do not understand the requirement that a client MUST NOT send DAU, DHU and/or N3U if DO is not set and MUST set DO if DAU, DHU and/or N3U are sent. I do not see any harm in saying that I normally support such-and-so DNSSEC algorithms even if on a particular query I don't want the DNSSEC RRs back. Indeed, 3.1.1 says that sometimes validating resolvers don't set the DO bit. It might still be useful for the DAU, DHU and/or N3U to be sent. Unless there's an important reason to keep this requirement, which appears throughout sections 3 and 5 (and is included in the RFC Editor note for section 5), I suggest you just drop it. If there *is* a reason to keep the requirement, please explain in the document. MUSTs and MUST NOTs that don't explain what harm they are trying to prevent are double-plus bad.
Section 5, paragraph 2: s/DNSSEC-OK (OK)/DNSSEC-OK (DO)
This seems more like an Experimental document, but I will not stand in the way of the WG's view of its status.
There seemed to be a lot of UOFU TLAs and FLAs, hopefully these are all RFC Ed SEs.
Stephen's idea for text about an attacker exploiting client's that continue to use weak algorithms is a good idea.
draft-ietf-pcp-upnp-igd-interworking
I am balloting No Objection on this document on the strength of the sponsoring
AD's review and the document's apparent non-impact on the routing system.
---
From the shepherd write-up:
The PCP WG has a policy to not send a document until the WG
has consensus and there are at least 5 people who have reviewed
and ok'ed the document. Many others were involved in reviews
of earlier versions, but the WGLC oks came from:
Xiaohong Deng <dxhbupt@gmail.com>
Dave Thaler <dthaler@microsoft.com>
Reinaldo Penno <repenno@cisco.com>
Tiru Reddy <tireddy@cisco.com>
Paul Selkirk <pselkirk@isc.org>
Noting that one of the five is an author :-)
- I support Sean's discuss. (And thought that the secdir review was a really good one.) - uPnP seems to cause a lot of folks security concerns so I was surprised that there was such a short security considerations section. However, since I know almost nothing about uPnP and only a little about PCP and have not had a chance to properly go into this, I don't have a valid discuss to ballot (unless I find time in the next two hours to read more about it;-)
Thank you for addressing my concerns so far and we are converging (based on draft version -09): 1) Ok, fixed. 2) Ok, fixed. 3) Ok, fixed. 4) Ok, fixed. 5) Section 5.3., paragraph 1: > The IGD-PCP IWF MUST store locally all the mappings instantiated by > internal UPnP Control Points in the PCP Server. All mappings SHOULD > be stored in permanent storage. Are there timeouts specified for each table entry? I have not seen any information about it, despite the fact that IGD and PCP have timeouts. How are those timeouts handled? Section 5.9 describes how the protocol is used to emulate finite and infinite lifetimes, but there is no linking between what's in Section 5.9 and the Port Mapping Table in Section 5.3. Probably, only a bit of text in Section 5.3 is missing on what timers are kept per table entry and also to make the linking to Section 5.9. 6) Ok, fixed 7) Section 5.6.2.: > 1. If a short lifetime error is returned, the IGD-PCP IWF MAY resend > the same request to the PCP Server after 30 seconds without > relaying the error to the UPnP Control Point. The IGD-PCP IWF > MAY repeat this process until a positive answer is received or > some maximum retry limit is reached. When the maximum retry > limit is reached, the IGD-PCP IWF relays a negative message to > the UPnP Control Point with ConflictInMappingEntry as the error > code. What is the maximum retry limit? Is it specified, implementation specific or what? I can understand that this is implementation specific for a stand-alone PCP client, but those parameters are the key of IWF, if they are expected to have predictable behavior. No information about the maximum retry limit is leaving the implementer alone and I would give some useful recommendation to that limit. For instance, a UPnP control point might resend its AddPortMapping() request after some time and the IWF should give a reply (postive or negative) before the UPnP entity is resending its request. I.e., there can be a relationship between the retry limit and when UPnP implementations are re-sending requests. 8) Section 5.7., paragraph 3: > Upon receipt of GetSpecificPortMappingEntry() from a UPnP Control > Point, the IGD-PCP IWF MUST check first if the external port number > is used by the requesting UPnP Control Point. If the external port > is already in use by the requesting UPnP Control Point, the IGD-PCP > IWF MUST send back a positive answer. If not, the IGD-PCP IWF MUST What is this 'positive answer' in UPnP terms? Can you replace the 'positive answer' by 'sending back the mapping entry matching...'? 9) Section 5.7., paragraph 4: > relay to the PCP Server a MAP request, with short lifetime (e.g., 60 > seconds), including a PREFER_FAILURE Option. If the requested > external port is in use, a PCP error message will be sent by the PCP > Server to the IGD-PCP IWF indicating CANNOT_PROVIDE_EXTERNAL as the > error cause. Then, the IGD-PCP IWF relays a negative message to the > UPnP Control Point. If the port is not in use, the mapping will be > created by the PCP Server and a positive response will be sent back > to the IGD-PCP IWF. Once received by the IGD-PCP IWF, it MUST relay > a negative message to the UPnP Control Point indicating > NoSuchEntryInArray as the error code so that the UPnP control point > knows the queried mapping doesn't exist. What happens to the established binding at the PCP server? It is requested for a short time, though 60s might not be considered short, and is still around even though it is not needed anymore. Isn't this a potential security issue, as a UPnP Control Point can issue a large number of ' GetSpecificPortMappingEntry()' requests that cause the PCP server to potentially maintain a lot of bindings for 60s or so? I've understand why and how this works, but my point is that a UPnP control point can issue a lot of etSpecificPortMappingEntry() requests in a shorter time frame that will create a lot of state of the PCP server. My recommendation is to document this as a potential security issue. 10) Ok, fixed. 11) Ok, fixed. 12) Section 5.8., paragraph 10: > The IWF MAY send a positive answer to the requesting UPnP Control > Point without waiting to receive all the answers from the PCP > Server. It is unlikely to encounter a problem in the PCP leg > because the IWF has verified authorization rights and also the > presence of the mapping in the local table. 'It is unlikely...' is not a proper statement for Standards Tracks. What is the expected behavior if the PCP leg is not doing what it is expected. It is correct that there shouldn't be an error if all authorization rights are correct, but why is the text saying 'it is unlikely' if this cannot happen? The phase 'it is unlikely' hints to the fact that something can go wrong. I would clarify that this step assumes that authorization is checked and ok and that justifies sending the reply already, unless there is some pitfall that isn't documented here. 13) Section 5.10., paragraph 2: > Upon change of the external IP address of the IWF, the IWF MAY renew > the mappings it maintained. This can be achieved only if a full > state table is maintained by the IWF. If the port quota is not > exceeded in the PCP server, the IWF will receive a new external IP > address and port numbers. The IWF has no means to notify the change > of the external IP address and port to internal UPnP Control Points. > Stale mappings will be maintained by the PCP Server until their > lifetime expires. This change of the external IP address has a number of side effects and the text looks 'easy' in doing this, but in realty this becomes very difficult. For instance, a change of the external IP address at the IGD will terminate all ongoing TCP connections between IGD/NAT1 and the CGN. It is at least worth documenting that this is effort on the PCP side but can have nonetheless very negative impact on the data path. Probably it would be the best to document this in some sort of operational considerations. Or at least a statement that says something along these lines: "Even though the IWF might be able to maintain the external mappings at the PCP server and the NAT of the IGD, the data plane between the PCP server's NAT and the NAT of the IGD might experience severe issues, such as TCP connections that will be reset."
Thanks, this looks like a very clearly written document. The flow diagrams help a lot. One minor thing: It would be helpful for terminology to be consistent between Figures 2/3/4. For example, Client vs. Local Host, and Host vs. Peer. Also, the "PREFER_FAILURE" option makes me laugh :)
The changes proposed in response to Martin's DISCUSS resolve my concerns with the document.
I am puzzled about the inconsistency between the terminology on slide 2, and that in slide 3 & 4. Why has a Client become a Local Host and a Host become a Remote Host? Note 'Host' is defined in the text as a remote peer reachable in the Internet.
Most of these are based on the secdir review from Vincent: 0) Are there any additional recommendations this document should be making wrt devices not implementing the default security policy recommended by [IGD2]? There's this text in IGD2 that makes me a little happier: The InternetGatewayDevice MUST support IGD Specific security as defined in section 2.3, but MAY implement stricter security policy. But then, there's this bit in s2.3 that seems to be a bit contradictory: This document RECOMMENDS the default access level to be applied for each action of the legacy services (version 1 and version 2). In other words, this document does NOT REQUIRE that a vendor MUST implement the access level defined in this document for each action of his InternetGatewayDevice:2 implementation. As a result, vendors are allowed to implement different access control policies than defined in this document. For example, a vendor can decide to set a Public access level for opening port mappings with ports lower than or equal to 1023 instead of a Basic access level. 1) My assumption is that your models are the 3-box models because you want access control applied based on the SHOULD [IGD2]. But, I really can't tell. 2) I think the bit about: Means to prevent a malicious user from creating mappings on behalf of a third party must be enabled as discussed in Section 13.1 of [I-D.ietf-pcp-base]. The reason IGD2 is the SHOULD because then you've got ACLs - right? But, in reality is the LAN trusted almost all of the time? 3) In s7, please elaborate on why it's SHOULD NOT: When only IGD:1 is available, operation on the behalf of a third party SHOULD NOT be allowed because there's no authorization supported in IGD:1. That's my suggestion, but doesn't the desire to have IGD2 because of it's authorization model mean that maybe this protocol isn't applicable to IGD1?
0) I found the authorization framework and authentication options in other documents referenced by [IGD2], but I did find them so I'm thinking it's probably okay to not add more references. (no action required) 1) If the UPnP control point is the IGD control point, can we use the same term in all the figures? 2) Why not reference: [DeviceProtection] – UPnP DeviceProtection:1, version 1.0, UPnP Forum, February 24, 2011. Available at: http://upnp.org/specs/gw/UPnP-gw-DeviceProtection-v1-Service.pdf.
draft-ietf-manet-olsrv2-metrics-rationale
- intro, "legacy OLSRv2 routers" is an odd phrase, I think I know what you mean but maybe try clarify. What I think you mean is "routers that implement OLSRv2 without the putative link-metrics extension" - section 4, last para: I hope that some other doc also says that link metrics should change slower than that update rate. If not, then this is being a bit more than just background informational stuff. (Just checking in case it got lost or something.) - 5.5, "unless link quality indicates otherwise" seems odd. You're explaining link metrics via "link quality"? If that's not another well known OLSR term, maybe better to just say "unless the implementation decides otherwise" or something? - 6.1, s/produce produce/produce/ - section 8: I'm a bit surprised there's nothing to say since I would have thought that telling lies about metric values provides another way in which an OLSR router can do bad things, such as ensure traffic is sent the way the bad router wants. If that's the case then maybe saying so and how it doesn't make things worse really would be good. If that's not the case, the saying why would be good. - section 8: Just a query: has there been any (good) work on using routing metrics as a countermeasure? E.g., gossiping about node reputations? If there were something good along those lines, here might be a fine place to note that (even if it wasn't part of the WG discussion).
I like this type of rationale document. This is something that the IETF
generally doesn't do, with the consequence that resolved issues are revisited
on regular basis. I wish I had this document at the time of reviewing
draft-ietf-manet-olsrv2. It could have been an appendix in
draft-ietf-manet-olsrv2 btw.
-
There is no "manageability considerations section".
http://tools.ietf.org/html/rfc5706#appendix-A for a list of questions.
Specifically regarding the metrics, the following question comes to mind: what
about connecting different MANET networks together, if the metric convention
(for a lack of a better word) is not the same. For example: delay, hop count.
Note that this metric "convention" is only the operator head AFAIK.
In a well-designed network, all routers will use the same metric
type. It will not produce good routes if, for example, some link
metrics are based on data rate and some on path loss (except to the
extent that these may be correlated). How to achieve this is an
administrative matter, outside the scope of OLSRv2.
Yes, there is the above sentence, but that's all there is in terms of
manageability and operations. Topics such as merging network, potential
notification or polling) for metric mismatch (*), etc.. Maybe that's fine
because it's a rational document, that's something that should be solved in the
manageability draft http://tools.ietf.org/html/draft-nguyen-manet-management-00
?
(*)
Note that, using directional metrics, if router A defines the metric
of the link from router B to router A, then router B must use router
A's definition of that metric on that link in that direction.
(Router B could, if appropriate, use a bad mismatch between
directional metrics as a reason to discontinue use of this link,
using the link quality mechanism in [RFC6130].)
- terminology
All terms introduced in [RFC5444], including "message" and "TLV", are
to be interpreted as described there.
All terms introduced in [RFC6130], including "MANET interface",
"HELLO message", "heard", "link", "symmetric link", "1-hop neighbor",
"symmetric 1-hop neighbor", "2-hop neighbor", "symmetric 2-hop
neighbor", and "symmetric 2-hop neighborhood", are to be interpreted
as described there.
All terms introduced in [OLSRv2], including "router", "OLSRv2
interface", "willingness", "MultiPoint Relay (MPR)", "MPR selector",
and "MPR flooding" are to be interpreted as described there.
This is a typical example where not using capitalized terms (when specified in
the terminology section), is a problem. Specifically because of the common
terms such as heard, link, message, willingness, etc... Let's take the 3
"heard" instances in the paragraph below. Which one(s) is/are a definition
coming from RFC 6130?
When a router reports a 1-hop neighbor in a HELLO message, it may do
so for the first time with link status HEARD. As the router is
responsible for defining and reporting incoming link metrics, it must
evaluate that metric, and attach that link metric to the appropriate
address (which will have link status HEARD) in the next HELLO message
reporting that address on that OLSRv2 interface. There will, at this
time, be no outgoing link metric available to report, but a router
must be able to immediately decide on an incoming link metric once it
has heard a 1-hop neighbor on an OLSRv2 interface for the first time.
-
A couple of acronyms must be expanded on the first occurrence: TC message, MPR.
Potentially others
It would have been useful to the reader if MPR had been defined, or at least expanded in the draft.
draft-ietf-ospf-ipv4-embedded-ipv6-routing
I'm probably missing something here, but the document doesn't mention the possibility of an MTU issue when a maximally large IPv4 packet is translated into an IPv6 packet: the larger IPv6 header would bump the packet over the MTU size. Has this been addressed, and I just missed it?
1.1, pedantic nit: OPEX might not be understood by some readers 1.2, slightly less pedantic nit: "The P routers" isn't a common term. While it is defined in 5565 it might be no harm to also say here you mean the internal routers. (I had to go look.) 11, 3rd para, is that "must" meant as a 2119 MUST? It looks like it ought be. 11, 4th para, s/currently// 11, why no mention of RFC 6506? Seems like its as relevant as IPsec maybe.
Thank you for this work, and thanks to Ben Campbell for the Gen-ART review. > AFXLBR (Address Family Translation Border Router) is defined in this document. Nice acronym! Are there any pronunciation guidelines? :-)
The document writeup says:
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in
the title page header?
Informational
Aside from the simple fact that the shepherd didn't fully answer the question,
I'd really like to understand why this is not a standards track document.
Please explain.
I do not understand why any of the MUSTs in section 3.1 are not simply "will". The MUSTs make no sense to me.
- Maintaining a separate routing table for IPv4-embedded IPv6 routes
optimizes IPv4 packets forwarding.
Can you expand on why?
-
In an IPv6 network, in order to maintain a separate IPv6 routing
table that contains routes for IPv4-embedded IPv6 destinations only,
OSPFv3 needs to use the mechanism defined either in [RFC5838] or in
[I-D.ietf-ospf-mt-ospfv3] with the required configuration, as
described in Section 3.3 and Section 3.4, respectively.
It looks to me that [I-D.ietf-ospf-mt-ospfv3] should be normative, like RFC 5838
See another sentence:
and
if the default OSPFv3 instance is used instead, configuration is
accomplished according to [I-D.ietf-ospf-mt-ospfv3], as described in
Section 3.4.
However, [I-D.ietf-ospf-mt-ospfv3] last updated is 2007
Is there an issue with this draft?
-
It is assumed that the IPv6 network that is inter-connected with IPv4
networks in this document is under one administration and as such, an
OSPFv3 instance ID (IID) is allocated locally and used for OSPFv3
operation dedicated to unicast IPv4-embedded IPv6 routing in an IPv6
network. This IID is configured on OSPFv3 router interfaces that
participate in the IPv4-embedded IPv6 topology.
Instance ID is per interface, if I'm not mistaken.
So which interface have this interface ID configured: IPv4 facing and/or IPv6
facing?
-
4. IP Packets Translation
When transporting IPv4 packets across an IPv6 network with the
mechanism described above
There are 2 mechanisms: 3.3 and 3.4
So I guess:
When transporting IPv4 packets across an IPv6 network with one of the two
mechanisms described above (section 3.3 and 3.4)
-
OLD
1. On an AFXLBR, if an IPv4 packet that is received on an interface
connecting to an IPv4 client network with a destination IPv4
address belonging to another IPv4 client network, the header of
the packet is translated to the corresponding IPv6 header as
described in Section 4, and the packet is then forwarded to the
destination AFXLBR that advertised the IPv4-embedded IPv6 address
into the IPv6 network.
NEW
1. On an AFXLBR, if an IPv4 packet that is received on an interface
connecting to an IPv4 segregated client network with a destination IPv4
address belonging to another IPv4 client network, the header of
the packet is translated to the corresponding IPv6 header as
described in Section 4, and the packet is then forwarded to the
destination AFXLBR that advertised the IPv4-embedded IPv6 address
into the IPv6 network.
I have only a couple of non-blocking editorial comments: I honestly had a hard time parsing the abstract. May I suggest replacing the abstract with what is basically the first paragraph of the Introduction?: OLD This document describes routing packets destined to IPv4-embedded IPv6 addresses across an IPv6 core using OSPFv3 with a separate routing table. NEW This document describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on RFCs 6145 and 6052, along with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in the IPv6 network. END -- Section 1.1 -- This document focuses on an engineering technique which aims to separate the routing table dedicated to IPv4-embedded IPv6 destinations from native IPv6 ones. The "from native IPv6 ones" lacks a reasonable antecedent. I think you mean this, yes?: NEW This document specifies an engineering technique that separates the routing table dedicated to IPv4-embedded IPv6 destinations from the routing table used for native IPv6 destinations. END
Stephen beat me to it. I thought the whole point of RFC 6506 was that nobody did IPsec for OSPF.
draft-ietf-rmt-fcast
Many thanks for addressing my discuss and comment points. I didn't check all the check all the changes you made against the comments, but the digest thing looks fine. I'm happy to check how you handled any of the comments if you want, just let me know.
I am in a no-objection position for this document. Earlier Russ was holding a
discuss (copied below) based on not having gotten a response to a Gen-ART
review. According to my records, on February 13th Vincent Roca responded. We
have yet to see a document revision, but I do not think the issues are serious
enough to warrant me to hold a discuss on submitting the edits that Vincent
indicate had already happened on their copy. Sponsor AD, please ensure that
once you approve this, there is a new version.
---
Original Discuss from Russ Housley:
The Gen-ART Review by Roni Even on 15-Jan-2013 did not receive a
response. I think that the two minor issues raised in the review
need a response. They are repeated below.
Minor issues:
1. I had some problem when reading the document about what is
mandatory to support. The distinction between what is required
to be supported and used is mentioned in section 5. Also
section 3.3 discusses what compliant implementation is, but
section 5 provides the full information. I think that it will be
better to move section 5 before or at the beginning of section 3
or as part of 3.3. no need to have the information twice.
2. In section 3.3 “The support of GZIP encoding, or any other
solution, remains optional.” I think that support is mandatory.
Please also consider the editorial comments in the review.
To the authors: Most of my comments are already covered. I support the DISCUSS positions by Pete, Russ, and Stephen. To the IESG: I also note that there's a downref to RFC 1952 (GZIP file format specification), which was not called out in the last call notice. We should NOT re-run last call for this -- given earlier downrefs to 1952, we should just add 1952 to the downref registry now.
I agree with Russ' DISCUSS point that sections 3.3 and 5 should be combined.
I support Stephen's discuss concerning MD5 and was asking myself the same question. Indeed why does the protocol not include algorithm agility?
1) I support Stephen's discuss. 2) Also please consider Chris Lonvick secdir review comments: https://www.ietf.org/mail-archive/web/secdir/current/msg03716.html
conflict-review-touch-tcp-ao-nat
I wondered if it'd be worth adding some security consideration text about possible attacks that might be enabled by this if e.g. there's a load balancer on the NAT'd end with different devices behind the NAT having the same master key - presumably a bad actor might be able to re-direct or replay some traffic even if there's a low probability that that'd not be detected unless a large amount of traffic is re-directed or replayed. Not sure if the attack is practical though, I guess it'd need a sequence number collision.
No objection to the draft, but I am curious whether the clients will know they're behind a NAT or whether all clients will end up setting this all the time.