IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2012-03-01. These are not an official record of the meeting.
Narrative scribe: Susan Hares and John Leslie (The scribe was sometimes uncertain who was speaking.)
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Client Server | req | |------------------------>| | error response | | X<------------------| | req | |----------->X | | req | |------------------------>| | error response | | ----------|| Big delay in network between | req / || client and server here |------------c--. || | / \ || |<--------- `------>| | success response | | X<--------------| | | | |
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
3.3.2 Returning Items
1254 EST break
1300 EST back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
7. Agenda Working Group News
1425 EST Adjourned
(at 2012-03-01 04:25:43 PST)
Also concerned about the IPR situation, but Stephen holds the DISCUSS
I have one very minor editorial comment. The document uses "packet" throughout, sometimes without qualification and sometimes with qualification; e.g., "ALC/LCT packet." For the most part, the type of packet can be deduced from the context. However, in section 3.3, it wasn't clear to me if "packet" referred to ALC, transport or IP packet: If an FDT Instance is longer than one packet payload in length, it is RECOMMENDED that an FEC code that provides protection against loss be used for delivering this FDT Instance. There may be one or two other instances of "packet," e.g., in section 7, discussing "per-packet" security, that are similarly unclear. This use of "packet" seemed a little confusing (although the meaning is probably clear): FLUTE is compatible with both IPv4 or IPv6 as no part of the packet is IP version specific.
I have no objection to the publication of this document. Thank you for the substantial description of the changes since RFC 3926 which made review considerably easier. I think you might find the need to consolidate the description of the changes which is currently incrementl such tat when more than one change was made to a section over time, it appears in the log more than once. This means that it is currently necessary to read the whole log before understanding what has changed. --- Seciton 9 ends a little suddenly :-)
#1 The IPR situation here appears complex. This obsoletes the experimental 3296 which has no IPR declarations. A common author for this and 3926 is an inventor of IPR declared in 2006 on this document. Could I get a pointer to where the WG was informed of and/or considered this? (Had a quick look, didn't find it.) Is it (still) the case that 3926 is not considered to require an IPR declaration but this document does? Reading section 11, I don't see much change here so as a result, I'm unclear as to whether the meta-data for these documents is consistent and considered so by the WG. So this may be more of a tools issue perhaps - if the new declaration supercedes the old then maybe the tools page for the RFC forgets the old IPR declaration or something. I'll keep the discuss so's we can figure that out. http://datatracker.ietf.org/ipr/731/ is a declaration on RFC 3926 as it turns out. #2 p20 - why Content-MD5? What's that used for? Is there alg agility? If not, why not (in a standard). If this isn't really needed or useful then why not just deprecate it for the PS version of FLUTE or replace it with something else? Section 7 is quite good btw, but if you do keep Content-MD5 then don't you need to consider a bad (or spoofed) sender that sends different folks different (chunks of) files that are MD5 collisions? #3 7.5 calls for IPsec in transport mode as the main security measure and also automated key management which basically means IKE - am I reading that right? Does that actually match the use-cases for FLUTE? Where's the unidirectional aspect gone? If this doesn't match any reasonable FLUTE use-case then don't we end up with no security in practice? I'm not sure what, if any, change might be needed, but I'd first like to understand the reality.
- What was the experiment for 3926 that has now concluded indicating that this document should be on the standards track? I'd like to have known. (A reference to something or short paragraph would have been fine.) - The introductory material isn't very clear to this reader. I'd suggest adding text like the intro from  and/or adding references to that or similar papers that introduce the protocol. ( was just the first thing that I found that seemed to have that, I'm sure there are many others, and maybe better ones, but its intro helped me.)  http://mad.cs.tut.fi/doc/Analysis_of_the_FLUTE_Data_Carousel_presentation.pdf - 1.1.3 - "works with all types of networks" - academic training tells me to always question all absolute statements like that all the time:-) Is it really true? How do you know? Would acoustic underwater networks or 6lowpans be counterexamples? (Section 3.4 implies a requirement for UDP as well.) I think you need references or an argument, or (most likely) to weaken the claim, e.g. via s/all/many/ - p10 - is it clear (enough) what's meant by a temporary IP address? Not a big deal but not sure its the right term. - p15: I don't get what this means really: "If the receiver does not understand the FEC Encoding ID in a FDT Instance, the receiver MUST NOT decode the associated FDT." It sounds like decoding and not decoding all at once. - s3.3: I've not parsed this out fully but the 2119 lanaguage here seems a tad loose - if this section were to avoid 2119 language and just be an intro, would that be better? (That might be a lot of work though, so just consider this a suggestion.) - why is this the case in 3.4.1? "Sender behavior when all the FDT Instance IDs are used by non expired FEC Instances is outside the scope of this specification and left to individual implementations of FLUTE." Seems like that'd create interop problems - why not? Similarly, the receiver behaviour being out of scope also seems wrong. - 7.3.4 RECOMMENDS that receivers identify themselves in case they mess up congestion control. Is that reasonable? It doesn't seem so since this doesn't define how to do that. I'd say weaken that and say that if receivers are known then you might be able to catch them messing up the CC scheme. - Is section 11 intended to remain in the RFC?
Is there any companion document that explains the operational model and the manageability aspects related to the deployment of this protocol? If such a document exists it would be worth at least to include a reference to it in this document, in the absence of a operational and manageability considerations section.
Other reviewers have expressed many of the concerns I had. Here are a few additional topics I'd like to chat about. 1. Apparently the application/fdt+xml media type was not reviewed on the ietf- types list, per RFC 4288. At least I see no request for a review in the archives at http://www.ietf.org/mail-archive/web/ietf-types/current/maillist.html 2. The IANA Considerations section is missing a registration of the "urn:ietf:params:xml:ns:fdt" namespace.
1. Why does the "Expires" attribute have a datatype of "xs:string"? Given that it is the UTF-8 decimal representation of a 32 bit unsigned integer, "xs:unsignedInt" might be more appropriate. 2. Did you consider assigning a default value for the "Complete" attribute? Presumably it defaults to FALSE, but it would be good to make that clear. (You might also consider mentioning that there are two lexical representations for boolean in W3C XML Schema, '1' or 'true' for TRUE and '0' or 'false' for FALSE.) 3. The terms "MIME field name" and "MIME field body" are never defined. Perhaps a reference to RFC 2045 is in order? 4. Please change "MIME type" and "MIME media type" to "media type". 5. In Section 3.5, you have "due to unexpected network conditions, packets for the FDT Instances MAY be interleaved" -- I think you mean "might", not "MAY". 6. The lack of a mandatory-to-implement integrity protection mechanism in Section 7.2.2 might harm interoperability. The same is true of Section 7.3.3 and Section 7.3.4. It is not completely clear to me whether Section 7.5 fills that gap. 7. Citing RFC 3470 might be appropriate in the security considerations.
In 3.4.2, Content-Location MUST be assigned a valid URI. What does "valid" mean in this context. Does it mean anything more than well-formed? In particular, if the URI is in a scheme that has GET semantics, does "valid" mean you can get the document that way? What does an implementation do if it sees a scheme it doesn't understand? (URI comparison is scheme-specific - it would be dangerous to an implementation to assume two URIs meant different things if it doesn't understand the scheme). If all you need is a unique identifier, what's the advantage of allowing arbitrary schemes to provide it? In the discussion of handling time wraparound, "can determine" seems problematic. How do you have interoperability unless both the receiver and the sender interpret this the same way? The XML Schema registration (section 8.1) should provide a URI. The document needs clearer discussion around the reuse of FDT Instance IDs. I hope I've misunderstood a fundamental idea and a simple clarification will address the following questions. * Is the intent that IDs increment by one again after wraparound? Or once wraparound happens, do you always select the next ID using "the smallest FDT Instance value" (you mean ID value, yes?) "assigned to an expired FDT Instance". If the later, then both the receiver and the sender will have to keep an explicit ordering based on when reassignments were received - in the extreme it would be possible to construct a degenerate case where the ordering ended up completely reversed (...,5,4,3,2,1) by using a set of decreasing expiration times as the ID space is traversed the first time. I realize a sender wouldn't really do that, but it's enough that it only have a couple of elements in the sequence that aren't in increasing order. That should be made clearer, particularly where you talk about the ordering being used (such as when describing the semantics for any two "File" elements declaring the same "Content-Location" but differing "TOI"). It would also help to summarize where the ordering is actually used by the protocol. * How would a receiver that joined after the sender started reusing IDs know that had happened? If it can't, the consequence is that all receivers have to keep track of what order they received FDTs in from whenever they join. * Since it's possible for a receiver to miss FDT instances, once wraparound starts it looks like its possible for two different receivers to have a different idea of what's "newer". Does that break anything? * Currently, receipt of an instance that reuses the id from a non-expired instance SHOULD be considered an error. When would the reciever _NOT_ consider this an error? Why is the document leaving receiver behavior out of scope? This seems to invite interoperability failure in deployed systems.
The last paragraph of 3.4.2 says it is RECOMMENDED that new attributes are defined in 2616 or a well-known specification. RECOMMENDED is a synonym for SHOULD. It would help to describe why this isn't REQUIRED in the document. In the last paragraph of section 3.3 (which talks about using out-of-band mechanisms for communicating attributes associated with files), consider reinforcing that using such an out-of-band mechanism does not make sending FDT instances in the session optional. The section on Intended Environments claims FLUTE is applicable for non-Internet systems, providing an example, but no support for the claim. Consider editing this to say something less subjective, like "FLUTE has also been adapted for use in other network architectures, such as..." and if possible, provide a reference. The document never explicitly says when the application/fdt+xml media type gets used. I'm a little surprised there's not a registry around that already assigns codepoints to encoding (particularly compressing encoiding) algorithms. The closest I could find is <http://www.iana.org/assignments/http-parameters/http- parameters.xml> which doesn't establish codepoints. Please consider reconciling with that registry. NIT: Section 3.1 has a list of rules. Several of the bullets in the list are not actually rules. Consider moving those to an introductory paragraph before the actual rules.
1. I think there is some confusion about the "R" flag. The caption for Figure 2 (and other Figures) includes: where R and U are the flags defined in Section 9.1 and 9.2. but I don't see any definition of an "R" flag in section 9.1. In my opinion, the "R" flag is unneeded if the LRI and LRA messages each have a separate header type code. 2. I don't see any text that describes how an LMA cancels local forwarding service, as implied in this text in section 4: For instance, the LMA may send a LRI message with a request to cancel an existing local forwarding service. 3. In section 5, what happens if, for some reason, one of the MAGs (e.g., MAG1) responds with a non-zero status code in its LRA to the LMA? Does MAG2 need to be notified, perhaps because it has some state that must be taken down? This text should be extended to allow for error cases: When the MAG IP Address option is present, each MAG MUST create a local forwarding entry such that the packets for the MN attached to the remote MAG are sent over a tunnel associated with that remote MAG. The only mention of error cases in section 5 seems to be: Barring the error cases, all subsequent packets are routed between the MAGs locally, without traversing the LMA. 4. In section 5: It will hence initiate LR at nMAG1 and update the LR state of MAG2 to use nMAG1 instead of MAG1. how does the LMA perform the state update and doesn't it also have to update some state in MAG1? 5. The text in section 6.1 is completely lacking any description of what the various participants should do in the case where an MN moves to a new MAG. 6. I'm not sure section 7 gives enough detail into the various ways in which an established LR situation must be torn down. For example, in the A11 case, does the LMA or the MAG determine that one of the MNs has moved and the participants are now in A22? 7. In section 9, I can't find definitions for LRA_WAIT_TIME and LRI_RETRIES.
1. In section 4, what does it mean for a MAG to "statically initiate LR"? 2. Also in section 4, does: It then verifies if the EnableMAGLocalRouting flag is set to 1. refer to the EnableMAGLocalRouting flag for MAG? 3. Editorial nit: because there is only one MAG in the scenario in section 4, the identifier MAG1 is probably unnecessary in Figure 2 and the related text. 4. In section 4.1, does "LR state of the MAG" refer to the state in the LMA? Also, is pMAG == MAG? 5. This text from section 6 seems awkward and the RFC 2119 language seems unnecessary: Only after it receives both the LRA messages each with Status value set to zero (success) from the two different LMAs, the MAG MUST conclude that it can provide local forwarding support for the two Mobile Nodes. 6. In section 10.1, "for now" is unnecessary. Why is the alignment requirement mentioned here and not for the definitions in section 9, and what does "8n+4" mean?
Updated Discuss and Comment to make it clearer which points I want to see addressed, and which are just "desirable". The issues come from the Routing Directorate review by Les Ginsberg on 2/27/12. You can engage with Les direct at email@example.com for clarification, but the Discuss issues are mine. - - - - - Why are you not using the "MN-CN" terminology from RFC 6279? The fact that you use "MN-MN" makes me think that you are only addressing cases where both endpoints are MNs. Is this the case? If so, this should be explicitly stated. If not, it would seem to be better to use the RFC 6279 terminology. --- Section 5 I assume the lack of requirement for synchronization works because the LMA will always forward packets regardless of whether it has sent an LRI/received an LRA? This implies that MNs and MAGs may receive duplicate packets at times - which presumably should be no problem. I am wondering if it would be useful to discuss these points? Similarly, in Section 6.1 it is assumed that LMAs always forward inter-MN packets regardless of the state of LR?
Nits: A number of acronyms are used without definition. For example, in Section 4 page 7 "HNP" "BUL" "BCE" are all undefined. This does not represent a complete list. Can you please scrub the document for all such occurences?
- LR with two MAGs implies that MAG1 knows that MAG2 is the CN's location at the granularity of the MAG (MAG2) with which the CN is associated.. Since there is a way for a MAG to initiate this then a bad or compromised MAG could attempt to track any CN for which LR is enabled who's address the bad MAG knows. That is a privacy problem for the CN's. I noted this about the DIME WG equivalent draft and the authors of tha suggested that text as per the above would be better in this document. I'm not sure there's a mitigation here really but I'd say its worth noting at least. - Figures 1 and 2 have no real caption and aren't referred to from the text so are less useful than they could be.
The Gen-ART Review by Mary Barnes on 24-Feb-2012 includes many issues, and the authors have agreed to make fixes. The revised document has not been posted yet.
minor nit - TLVs is plural of "Type-Length-Value" not "Type-Length-Value structure" and expansion is NOT REQUIRED It's a bit confusing putting a mini-IANA section in the Intro. Section 13 after "This specification requests" a number of the terms defined are not used in the document.
I have a number of discuss points here. Maybe some of this is just that I don't have the right context but I find it hard to see how this is really baked as-is. I guess I'm wondering if it would perhaps be better to wait until someone actually does an implementation? (The write-up says there are none known.) #1 I don't understand why this does not define any actual algorithms. Is there another document going to do that? If not, then what's the point of this being on the standards track with no algorithms and no automated key management? I don't see any MANET WG documents that will obviously provide those nor any relevant milestones. (Mind you, all the milestones are dated 2007;-) #2 Does this allow or preclude MACs such as HMAC-SHA1? If the former then you need to change terminology as those are not signatures. (I'd suggest integrity check value instead.) If the latter, then why do you want to prevent that? While I don't care too much about the specific terminology, (others do though), you definitely need to be clear if you really mean only digital signatures or not. #3 I don't understand why an 8-bit key index is sufficient for a large network. (And key index is not really a good term, I think key identifier would be much better.) With key rollovers and some form of key derivation for different directions (to prevent reflection attacks) and maybe two different key usages for different kinds of message or something like that, that would mean only supporting 32 unique keys values for a given purpose in the entire network which just seems too small. I'd suggest changing that to a key identifier length-value field or at least providing some way to identify key number 257 and beyond. #4 Are "badly formed" and "insecure" assumed to be the same? (Section 4 implies they are.) If so, that would seem to preclude any MANET routing scheme where a node might forward cryptographic fields but not act upon a routing message that it understands but cannot verify. Was that considered by the WG and was it rejected? Rejecting that seems to imply that all nodes need to be kept up to date with all keying material all the time which seems brittle and would also seem to make it very hard to introduce a new algorithm except as a flag-day or by having all nodes add fields for all algorithms. (Which in turn implies MANETs will remain tiny so that this will be practical or that large MANETs won't be able to use security.) #5 I don't understand why you don't define at least one timestamp precisely. Why would you want 250 varieties of timestamp anyway? #6 Having separate hash and cryptographic function registries might not be the best plan since not all combinations will make sense. Is that really a good idea? Why not make use of some other registries that already exist? (That is, is there a particular reason why you need new registries or have you looked but not found one that'd work?)
- Title seems misleading reading the abstract. Suggest adding mention of timestamps in title and fixing signature term as per discuss point 1. - Using the term "unsigned timestamp" in 13.2 seems like a bad choice given that a you're using signature all over the place. I'd suggest qualifying that.
I concur with Stephen Farrell's thorough analysis.
Section 10.2 says "If both a TIMESTAMP TLV and a SIGNATURE TLV are associated with an address, the TIMESTAMP TLV <value> SHOULD be considered when calculating the value of the signature". "be considered" is vague - can it be made more precise? Is this trying to say the signature should cover the timestamp? If so, how is this interoperable as a SHOULD instead of a MUST?
(1) In Section 13.1.3, when discussing responses to unsolicited multicasted ANNOUNCE messages, there seems to be potential for a large number of packets to be generated all at once. There should be some guidance here about whether the responses need to be dithered or paced in some way. This was raised as part of Pasi Sarolahti's TSVDIR review. (2) It seems that there isn't a good way to unambiguously match a response up to the request that generated it; especially when there have been (perhaps multiple) retransmissions. Is this really the case? If so, it seems that it should either be remedied or the impact needs to be discussed. (3) In Section 7.1, note that the guideline from RFC 5405 for retransmission is one datagram per RTT or in absence of an RTT measurement, one datagram every 3 seconds. The 2-3 seconds in section 7.1 is slightly more aggressive than this. I think timers on the order of seconds may be horribly long though compared to the expected RTT between the client and server. Would it be possible to cache an RTT if it could be measured during some request-response pair, and use that rather than the 2-3 second rule? (note this would require unambiguous relation of responses to requests, as in the prior DISCUSS point).
Note to responsible AD. This document requests the creation of regsistries that use the "specification required" allocation policy. That means you will need designated experts. --- Please consider addressing the minor points and questions raised by Loa Anderson in his Routing Directorate review especially the question about Section 15. Additionally, I have some comments as follows. There are quite a few and some of them are relatively significant. None of them merits a Discuss, but I do hope you will take them seriously. --- Section 6.3 It is the responsibility of the PCP client to ensure the server has sufficient room to reply without exceeding the 1024-byte size limit. This is the first mention of the "1024-byte size limit" (I think you mean the 1024=byte message size limit") and it would be helpful to explain why that limit applies. --- Section 7 Every PCP request generates at least one response, so PCP does not need to run over a reliable transport protocol. Now, I can see how this would be made to work by a protocol spec that implements a timer waiting for a response and a retransmission (as described in Section 7.1), and a "more responses to follow mechanism" (as possibly hinted at in Section 7.3), but your statement is too bold as it stands. Perhaps you could rewrite as: Every PCP request generates at least one response, amd PCP is responsible for retrying requests and correlating responses, so PCP does not need to run over a reliable transport protocol. It would also be good (maybe in 7.3) to clarify the processing when there are multiple responses to a request. How does the client actually know that it has received all of the responses? --- Section 7.1 Prior to sending its first PCP message, the PCP client determines which server to use. The PCP client performs the following steps to determine its PCP server: 1. if a PCP server is configured (e.g., in a configuration file or via DHCP), that single configuration source is used as the list of PCP Server(s), else; 2. the default router list (for IPv4 and IPv6) is used as the list of PCP Server(s). For the purposes of this document, only a single PCP server address is supported. Should future specifications define configuration methods that provide a list of PCP server addresses, those specifications will define how clients select one or more addresses from that list. It seems to me that the second option listed here is exactly a case of a configuration method where there is a list of PCP server addresses. So don't you need to define the method of selection (probably, first in the list is selected)? Furthermore, a couple of paragraphs later you have: When attempting to contact a PCP server, the PCP client sends a PCP message to the first server in its list of PCP servers, which seems to be exactly the specification of how to select a server from a list. --- Section 7.1 As with all UDP or TCP client software on any operating system, when several independent PCP clients exist on the same host, each uses a distinct source port number to disambiguate their requests and replies. The PCP client's source port SHOULD be randomly generated [RFC6056]. I suggest you don't need/want to mention TCP here. While what you say is true, it is not relevant to this spec. --- Unless I missed it, you have not described the fact that a client can receive an apparently unsolicited response from a server. This could happen after client restart. --- Section 10.1 There is some fluff in the terminology where (e.g.) the figure is described as showing the packet format where it actually shows the opcode-specific data. Same issue in Section 11.1 and Sections 12.1, 12.2 etc. --- Sections 17.2, 17.3, and 17.4 It seems entirely perverse to me to have just one code point available in each registry (and three in one of the registries) for future Standards Action, but many for specification required and private use.
The Gen-ART Review by Richard Barnes on 27-Feb-2012 raised a few concerns. Please respond to at least these concerns: (1) Several people, including Richard, think that implementation would be simplified if a transaction identifier were used. An identifier can simplify response processing, clarify the meaning of lifetime parameters, and provide some protection against address spoofing. (2) Add explanation of consequences from spoofed packets. (Or better, make it easier to detect and discard them.) An off-path attacker might be able to break synchronization in state between clients and servers, for example, by sending gratuitous responses. Richard offers this example flow as a way for an off-path attacker to steal traffic: > > 1. Attacker obtains mapping from address:port=A:P on PCP controlled > device to one of its ports B:Q > 2. Attacker convinces client that it has a mapping from A:P to its > port C:R > 3. Attacker acts as a man in the middle: remote -> A:P -> B:Q -> C:R (3) It seems the ANNOUNCE method provides an opportunity for an attacker capable of spoofing to cause an arbitrary number clients to flood the server with requests. Please add explanation of consequences if an attacker mounts this attack. (Or better, make it more difficult for an attacker to do so.)
The Gen-ART Review by Richard Barnes on 27-Feb-2012 raised a few concerns. Please consider these points: (a) The document says that v4-mapped addresses are not used as source or destination addresses for real IPv6 packets. Richard is aware of some work on IPv6 traceroute scanning where numerous routers will respond from v4-mapped addresses. It probably would be accurate to say that these addresses would never appear in a mapping. (b) In Section 6.4, the first paragraph says that each error is "long" or "short", but they're not all marked. Is there a default? It also seems like some of these errors are effectively permanent, such as UNSUPP_VERSION; the PCP NAT isn't going to support a new version of the protocol half an hour from now. (c) In Section 7.1, you first say that "only a single PCP server address is supported", but then in a couple of other places mention a "list of PCP servers". Which is it? (d) In Section 7.1, it seems like it would be pretty unusual for the PCP server to be the first-hop router, at least outside of the CPE case. Would it be better to use an anycast address to find the server? (e) I did not find that the code samples in Section 9 added any information. The one case where one would have been helpful (9.4), there was none.
[Note: I'm on vacation this week and therefore my RTT will be exceedingly long. I've only just gotten through the beginning of section 7 and already I have a slew of comments. Some of the ones in the COMMENT section might move up to DISCUSS, but I haven't had time to sort through all of it yet. The two that are currently labeled DISCUSS are definitely in that category. Either way, I asked Jari and he said to send you what I've got so far. More to come soon.] Section 6.3: The handling of an Option by the PCP client and PCP server MUST be specified in an appropriate document, which MUST state whether the PCP Option can appear in a request and/or response, whether it can appear more than once, and indicate what sort of Option data it conveys. This does not belong here. This sounds like an IANA Consideration, that you are requiring a document for registration, and you are specifying what goes in that document. If so, then put this (without the MUST) into the IANA Considerations section with appropriate language. Otherwise, I don't understand what protocol force this documentation requirement has. Option definitions MUST include the information below: Again, that looks like IANA considerations. Section 7: PCP is idempotent That's a fine thing, but I believe there's a missing bit of functionality in this protocol to pull it off: Let's say I send a request that results in an error condition, and the error response is sent back but it is delayed. I'm an aggressive client, so I send another request. That one succeeds. Now I get back the error response. Or I get the success response first, and then finally the error response comes back. How do I know which request succeeded and which one failed? Do I have to check the Epoch Time to put them in order and assume that none of the responses were lost? A serial or sequence number in the request that is turned around in the response would solve this problem. Am I missing something?
I find all of the references to the "interworking function" from UPnP to be inappropriate in this document and should be removed. This is specific implementation advice for a specific environment, not protocol and not required for interoperability. I think it weakens the protocol specification and could have bad effects down the road. (Cf. IMAP, where specific accomodation of implmentation semantics led to all sorts of interoperability failures.) I think having a separate document with specifics of how to do PCP for UPnP is fine, but it shouldn't be in this document. The notion of "subscriber" is unnecessary for this protocol and should be removed. It is sufficient to talk about per-host limits and quotas to explain the concepts that are there and then the document will not have to talk about the mapping of a business model onto the protocol. All of the forward references in this document make it somewhat confusing, and I suspect longer than it needs to be. I don't see why sections 10-12 can't be moved earlier in the document. Section 3: PCP Client definition. I don't find the parenthetical bit about several web browsers useful; readers will confuse multiple instances of the same browser with multiple browsers and the message will be muddied. Not only that, anyone who will be coding this is well aware that multiple applications can run on a single host. I found myself wondering what the note was trying to get at. I also found the reference to UPnP not terribly helpful. I would strike it and simplify this description. PCP Server definition is circular. Better would be: "A PCP software instance that resides on the NAT or Firewall that receives PCP requests from the PCP Client and sets up the appropriate state in response to that request." * Explicit dynamic mappings are created as a result of explicit PCP MAP and PEER requests. MAP and PEER are not defined yet. You could define the actions of mapping and peering and then use the verbs instead of the OPCODEs here. Section 6.1: Version: This document specifies protocol version 1. This value MUST be 1 when sending, and MUST be 1 when receiving. I'll begrudingly allow that it "MUST be 1 when sending", but I find this to be a silly use of 2119 anyway; it MUST be 1 iff you are implementing this version of the protocol, which seems stupidily redundant. I think such language also encourages receivers to do stupid things if the version is not 1. ("Well, the protocol says that it MUST be 1, so I don't have to do any error checking.") So, I would drop that bit. But it is simply not true that it "MUST be 1 when receiving." It very well might not be, which is why there's an error code for wrong version. Requested Lifetime: An unsigned 32-bit integer, in seconds, ranging from 0 to 2^32-1 seconds. This is used by the MAP and PEER Opcodes defined in this document for their requested lifetime. Future Opcodes which don't need this field MUST set the field to zero on transmission and ignored on reception. So, it seems to me (given the last sentence) that this should have been opcode specific and appeared in that part of the header. I assume that ship has sailed. But I still don't understand the last sentence: Why should future opcodes be required to have that field filled with zero if it's not being used? If I use it, I fill it in with what I think it means. If it's not used, neither side will use it and the opcode will specify that. I don't see what use it is to make the admonishment here. (Same issue in 6.2.) And again, MAP and PEER are used before being defined. (I'll not mention this problem again, but MAP and PEER are mentioned several times before section 9 rolls around.) Section 6.3: It is the responsibility of the PCP client to ensure the server has sufficient room to reply without exceeding the 1024-byte size limit. What 1024-byte size limit? This is the first mention in the document. An Option MAY appear more than once in a request or in a response, if permitted by the definition of the Option. If the Option's definition allows the Option to appear only once but it appears more than once in a request, and the Option is understood by the PCP server, the PCP server MUST respond with the MALFORMED_OPTION result code; if this occurs in a response, the PCP client processes the first occurrence and MAY log an error. What's this error logging business? Is the server (for some interoperability reason) not allowed to log an error but the client is? This doesn't sound like protocol to me; sounds like implementation advice, and boring implementation advice at that. Strike the "and MAY log an error." A client doesn't need your permission to do so. PCP clients are free to ignore any or all Options included in responses, although naturally if a client explicitly requests an Option where correct execution of that Option requires processing the Option data in the response, that client is expected to implement code to do that. I cannot figure out what the above is trying to accomplish that is non-obvious. Is there some case where this makes some sort of interoperability difference? How could you tell if the client actually ignored it or processed it? Section 7: PCP messages MUST be sent over UDP [RFC0768]. It seems to me that ICMP might be the correct choice instead of UDP, but I understand I may be blowing into the wind. Section 8: 1. If a client or server supports more than one version it SHOULD support a contiguous range of versions -- i.e., a lowest version and a highest version and all versions in between. Why is it useful (let alone an interoperability RECOMMENDation) to do that? I can see a stinker of a version potentially come out and the implementer decide that it's not worth implementing that version. What's the downside? Section 9: Some applications will break if mappings are created on different IP addresses, so applications should carefully consider the implications of using this capability. What applications are those? And what is the nature of that breakage? I don't understand what this sentence means. Static mappings for that Internal Address (e.g., those created by a command-line interface on the PCP server or PCP-controlled device) SHOULD also be assigned to the same External Address. Why? What breaks if they are assigned to different External addresses? (I'm also not sure why static mappings are discussed in this document at all; there is no protocol involved in static mappings.) Also, what happens if the client requests two different explicit mappings? What should the server do then? Section 10.2: If the client wants all protocols mapped it uses Protocol 0 (zero) and Internal Port 0 (zero). I don't understand how this will work. If I am a client that says "Protocol 0, Internal Port 0", haven't I just taken over the entire external address from the NAT, and therefore nobody else connected to that NAT can use PCP?
Other reviewers have provided significant input. I have a few additional comments. In Section 7.5, is the recommendation about 6.25% clock skew based on empirical evidence? In Section 8 (bullet 6), why would the client expect that the server might support its old version after 30 minutes?
1) Section 7 paragraph 2 asserts the protocol is idempotent, but then shows an example where it isn't. If you allow a retransmitted request to produce a different response, the protocol is not idempotent. Given that you allow this, not changing any bits in the request when you retransmit it allows the client and server to end up with different views of the request's success. Example: View in a fixed-width font: Client Server | req | |------------------------>| | error response | | X<------------------| | req | |----------->X | | req | |------------------------>| | error response | | ----------|| Big delay in network between | req / || client and server here |------------c--. || | / \ || |<--------- `------>| | success response | | X<--------------| | | | | Note that epoch time doesn't help with this, but might with the below variants: variant 1 - the success response actually delivers, after the client is no longer looking for a response variant 2 - the success response delivered first, followed by the delayed error response Adding a transaction identifier would only help if it was allowed to change with retransmission, and then the client would have to keep retransmitting until it got a response matching its most recent transmission before assuming it and the server were in agreement about the state at the server. Alternatively, you could require the server to actually be idempotent and never respond differently to the same request. (But you would need to put a finite limit on how long a client should retry before giving up on getting a response so that the server wouldn't have to remember the request and what response it sent forever). 2) Having text written for having a list of servers, and other text that says "for this document, the list can only have one element in it" is very confusing, and will likely lead to implementation mistakes. Would it be too hard to rewrite the text to say "the server" instead of "the first server in its list", and add a section warning implementers to anticipate handling lists when the protocol is extended? 3) I'm not seeing a discussion of the consequences of someone being able to spoof an unsolicited ANNOUNCE response - that seems like an attractive target for someone wanting to DoS a large scale server. Related - if you are operating a CGN-sized server, what keeps sending such an ANNOUNCE response from effectively resulting in an avalanche-restart style flood of traffic from all the clients using that server?
The statement "Of course, this sort of behavior is common to all UDP-based protocols" just before section 7.1 is not true.
I would have thought that the ability to mis-direct traffic would be enhanced with the addition of wildcards and that that might be worth a mention in the security considerations. That is, while there may be no new threat, nor any new countermeasure needed, the potential impact of an existing threat would seem to be increased by this.
I support Russ and PSA's DISCUSS points
I presume that Section 6 needs to be updated as this document goes through the publication process. I think you should provide instructions to the RFC Editor on what should be done to this section. A way to do this would be to supply an RFC Editor note that fixes the section consistent with the actual IANA allocations, but will not show in the document until published as an RFC.
Section 4 says you MUST support signing "and/or" validation with both lengths. I think that is not quite clear enough as the requirement differs for different players in the DNSSEC game. Aside from basic clarity, which is the most important thing, there is also an IPR declaration here that distinguishes between things that are needed and things that are optional so I think expressing it in a way that makes clear that there are no optional-to-implement bits for anyone would be an improvement. I'd say that it'd be better to spell it out that implementations that create DNSSEC values to put into the DNS MUST implement signing and verification for both lengths, and that DNSSEC clients MUST implement verification for both lengths. (Or whatever is the right way to say thing.) Will the examples be re-done after IANA have allocated codes? Be more than nice if that were to be the case. An informational pointer to RFC 6090 might be no harm here (and everywhere that uses ECC).
Thank you for addressing the issues raised by Bill Mills in his AppsDir review.
Please confirm that the issue raised by IANA on 28/Feb has been addressed.
Default Free Zone (DFZ) should have a reference, if only a forward ref to section 2 when you first use it in section 1 ==== Asymmetry is a problem with certain types of application, NTP for example. It would be useful if there was some discussion on the relative degree of asymmetry imposed by these LISP solutions vs the degree of asymmetry in the existing Internet, and a note made about the impact of asymmetry on applications
I only have a minor Discussion point (do I hear the authors sighing?) Section 4.2 says Non-LISP sites today use BGP to, among other things, enable ingress traffic engineering. Relaxing this requirement is another primary design goal of LISP. I went back to look for the description of this design goal in the LISP spec and I couldn't find it. Might be my search was a bit random. Might be the design goal wasn't stated in the base spec and so shouldn't be claimed here.
Thank you for the paragraph at the end of the Introduction. --- This document would be made significantly more useful by the addition of a figure showing the architectural components. --- Please s/draft/document/ throughout. --- Section 2 For traffic not to be dropped, either some mechanism to make this destination EID routable must be in place. Typo "either", or missing "or". --- Section 5.2 Are there any consequences of the assymetry of PITR use that we should investigate? Yes, I know that the Internet is not always symmetric, but in general it often is.
- Its not clear to me that the mapping system can reliably know that all non-LISP IP addresses are in fact not EIDs. But I'm willing to suspend disbelief for the experiment:-)
I have no objection to the publication of this document, but I have a number of small issues I hope you will attend to before publication. --- Section 2 is unnecessary and should be removed (deosn't idnits give a warning about this?) --- In Section 3, it would help the reader if you did not use the passive voice. Following is a point by point analysis of the problems. Issues listed in [RFC4966] are classified into three categories: Is the classification yours or does it come from RFC 4966? It is a bit of a nuisance to have to read RFC 4966 to discover the answer? In view of this, I found the category "impossible to solve" to be an "interesting" categorisation! Where is the proof? --- Section 3.3 Analysis: This issue has mitigated severity as the DNS is separated from the NAT functionality. Using a past participle as an adjective is all very well, but here is has confused the meaning! It reads as though the issue has done the mitigation. Better to say: The severity of this issue has been mitigated... And then it is normal to treat mitigation as transitive. So, what did the mitigation? The severity of this issue has been mitigated by the separation of the DNS from the NAT functionality. --- Section 3.3, item 3 This item suggests that you need a fourth category: viz. issues that do not apply to this problem space. --- Section 6 would be enhanced by pointing at the issues within the document that are related to security. --- I'm slightly suspiscious that the reference to [I-D.haddad-mext-nat64-mobility-harmful] in Section 3.1 may be normative. I am pretty sure that [I-D.ietf-pcp-base] is normative in item 4 of Section 3.3. [I-D.ietf-behave-lsn-requirements] in item 6 of Section 3.3 may be normative.
The Gen-ART Review by David Black on 28-Feb-2012 raises one major concern that needs to be addressed. David offers alternative text, but the authors have not said whether they agree with it as yet. The review form David can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07228.html
Section 3.2.3 I cannot reconcile the text in option (1) that says: with the conclusion of the section that says: Option (1) seems to be the most viable and efficient solution. If it is the intention of the PCN working group to be "PCN for IP-only networks" then I do think this could be s[elled out. OTOH, if MPLS is in scope, then surely option (1) is impractical. Note that draft-ietf-pcn-3-in-1-encoding makes a specific statement about applicability only to IP. --- What does "Primarily" mean in this context? I would like you to replace the passive voice in Section 4.5 so I can tell who made the decision! Additionally, I would like to understand why there are other PCN working group documents for other encodings (draft-ietf-pcn-3-state-encoding, draft-ietf-pcn-psdm-encoding) if this section represent a full statement of the WG's decisions. --- I'm afraid I found the conclusion in Section 5 particularly impenetrable. Could you: - Break out "what we did in this document" as a separate paragraph. - Make a definitive statement about what the WG has concluded. - Place the summary of the reasons for the conclusion as a third paragraph.
In Section 1 This requires at least three different codepoints for not-marked PCN traffic, PCN traffic re-marked by the threshold-marker, and PCN traffic re-marked by the excess-traffic-marker. Please insert a colon after "codepoints" in order to fix the meaning. --- In Section 1 This document summarizes these issues for historical purposes. Do you want to publish this as a Historic RFC? --- Section 3 The Differentiated Services (DS) field is chosen for the encoding of PCN marks. This use of the passive voice is not helpful! - Has the choice already been made? If so give a reference. - Does this document document the choice being made? If so give a forward pointer or explanation. - Or is this just commentary? :-) --- I think Section 3.1 makes [RFC0793], [RFC2474], and [RFC3168] into normative references. 3.3.1 reinfotces that for [RFC3168]. Section 3.3 and 3.3.2 appear to make [RFC4774] normative. --- Section 184.108.40.206 uses "CU" before it is explained in Seciton 4 and defined in Section 4.3 --- Section 4 Figure 7 summarizes these PCN encodings. as summarized in Figure 7. :-)
I am balloting No Objection on the assumption that this has been thoroughly reviewed by the INT ADs and the Security Directorate.
So while this seems to be quite a good idea, I've a couple of things I want to understand...(oops - added #3 below, forgot that) #1 Has the security of the auth protocol in 5.8 been studied much? If so, where is that described? I'm surprised there's nothing directional to prevent reflection attacks or cross-protocol attacks, e.g. by including MN and HAC-specific strings in the HMAC input. As-is, it also looks like messages 2 and 3 could maybe be reflected. It also looks like messges can be replayed since the tls-server-end-point CB-octets are fixed per-hac. Since CB-octets are essentially public, guesses of the MN's PSK are also possible, if that is somehow human-memorable. This all looks like a problem to me that needs to be looked at even for an experimental spec, or maybe I'm misreading something. (I guess similar concerns might exist for the eap method in 5.9 as well.) #2 If MN authentication is done above TLS then you might need to ensure that TLS implementations are not vulnerable to the TLS re-negotiation bug. (See RFC 5746.) Did you think that thgrough? Might be worth noting in the security considerations even though the MN<->HAC authentiction scheme uses channel-bindings, just in case. (Actually since the CB-octets are not session-specific this might be a gotcha too.) #3 The draft seems to be missing information on how to match TLS certificates to identities for HAC authentication.
- I don't see why MN authentication has to be done outside the TLS session setup (handshake). TLS supports client authentication and its not clear why that couldn't be used here instead of the scheme in 5.8/5.9. - Isn't there already a way to do EAP over TLS? Why invent a new one? I think you should say why, if its justified. (e.g. RFC 5281.) - 4.2: I guess you also need mutual authentication between non-colocated HAC and HA instances? (That might seem like nit-picking, but there are ways to get integ. & confid. without knowing for sure from whom stuff is coming.) - I'm a bit surprised that you don't want to use RFC5705 to extract some key material from TLS sessions. Worth considering and/or noting as a possible future improvement? - 5.6 seems a bit brittle - if TLS changes the set of preferred ciphersuites that could in principle result in a mismatch between the TLS preferred ciphersuites and what's doable between MN and HA. - In 5.8 you don't seem to have algorithm agility for your "auth" algorithm - can it be other than HMAC-SHA256? Maybe ok for an experimental RFC though but worth noting. - In 5.8 after figure 4, step 2, what is msg-octets when none of the optional fields are included? The description in the last two paragraphs seems a bit broken too. (2nd last para should be about step 2 I thought) - As commonly used, TLS doesn't quite give the same level of security as IPsec as commonly used. IPsec has perfect forward secrecy due to its use of D-H, whereas TLS with RSA key transport does not. That means that a later exposure of a server RSA private key (e.g. if de-commissioned h/w isn't properly scrubbed) potentially allows anyone to recover TLS pre-master keys from any recorded TLS sessions. That's worth noting so that if someone does deploy this, they know to not just sell old server h/w that used to store RSA private keys on disk. - TLS with RSA key transport also relies on the entropy provided by the client for security. That has been a source of known problems over the years (including very recently) and so is also worth noting since the client here is a mobile node that might just have been turned on and so not have lots of entropy. - While TLS protects against replays, if somehow I get the auth protocol messages then I can replay those in a new TLS session with the HAC so the text in the security considerations on this point might need to change depending on the discuss pionts above. - There're some points worth noting in the secdir review as well. http://www.ietf.org/mail-archive/web/secdir/current/msg03131.html
Please see the comments in the Gen-ART Review by Ben Campbell on 28-Feb-2012. The comment that causes me the greatest concern is covered by the (updated) DISCUSS position from Stephen Farrell. Please consider all of Ben's review comments: http://www.ietf.org/mail-archive/web/gen-art/current/msg07232.html
Section 9.2 states that "Server-side certificate based authentication MUST be performed using TLS 1.2 [RFC5246]" but that "The client-side authentication may depend on the specific deployment and is therefore not mandated." However, you don't say anything about the basis for authentication or identity checking. What identifiers need to be in the certificates? How are those identifiers checked? What are the rules? We can't just wave our hands here, else interoperability will be impossible (as will real security). Profiling RFC 6125 might make sense, if the identifiers are domain names. If the identifiers are IP addresses, then life is simpler, but we would still need to say something about identity checking.
I have no objection to the publication of this document. It discusses a problem that is very close to the problem that we have chartered the ARMD to address and I am wondering whether there needs to be a reference to that work.
I have no objeciton to the publication of this document, but I noticed a few small points I hope you will look at before publication. --- While appreciating the desire to use RFCs to force vendors to provide specific function to the operators, I don't think that the use of RFC 2119 language in this Informational document adds very much (the language is intended to add clarity to protocol specifiations, and is sometimes used to make requirements documents clearer). In fact, I cold only find two uses of such language (both are "SHOULD") in this document so I suggest you change them to normal lower case, and drop the boilerplate from Section 1. --- Section 4 During testing it was concluded that 4 simultaneous nmap sessions from a low-end computer was sufficient to make a router's neighbor discovery process unusable and therefore forwarding became unavailable to the destination subnets. Without casting aspertions on the authors, is it possible to provide some qualification of this statement? For example, a reference to the test description and results, or a simple note as to by whom the testing was carried out. Similarly... The failure to maintain proper NDP behavior whilst under attack has been observed across multiple platforms and implementations, including the largest modern router platforms available (at the inception of work on this document). ... would benefit from a reference. --- Section 6 s/stipulated/suggested/ or s/stipulated/stated/ --- Section 7 might benefit from more detail on the management interfaces that operators would like to see provided by vendors both for the control of the optional mechanisms discussed in this document and for the notification about and analysis of attacks. --- It might have been nice to add a note about the interaction with mobility (such as of VMs in a data center).
This document sure feels like a standards-track Applicability Statement to me. Did the WG consider requesting a status of Proposed Standard? Please consider citing RFC 4732 at the first use of the term Denial of Service.
I have no objection to the publicaiton of this document. I think that the Introduction could have been more extensive - a good place for citations and explanations.
1. I didn't really get what's meant by " When an at:deleted-entry element appears in a Feed document other than it's source Feed or when an at:deleted-entry element that has a source Feed document is used in the context of a Deleted Entry Document, it MUST contain an atom:source element." But I guess Atom developers probably do so that's ok. 2. Last para of section 6: I guess that if someone did MAC and then symmetrically encrypt one of these (is that as unlikely as I think?) then it might be useful to tell them not to use the same key for both. 3. Digital signatures by themselves do not provide non-repudiation. Please delete that term.
This is a solid document. Before moving to Yes, I would like to ask if publishing it as Proposed Standard rather than Informational was considered? I don't object to publishing it as Informational, but suggest that Proposed Standard is a better track for it.