IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2010-03-11. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Dan, Russ
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
2.2 Individual Submissions
2.2.1 New Items
Telechat:
Telechat:
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
Telechat:
3.3 Independent Submissions Via RFC Editor
3.3.1 New Items
3.3.2 Returning Items
1243 EST break
1249 EST back
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
5. IAB News We can use
6. Management Issues
Telechat:
7. Agenda Working Group News
1434 EST Executive Session started for details of IDNAbis appeal, Ross excused himself.
(at 2010-03-11 08:00:05 PST)
draft-ietf-dnsext-axfr-clarify
Abstract: The Domain Name System standard mechanisms for maintaining coherent servers for a zone consist of three elements. One mechanism is the Authoritative Transfer (AXFR) defined in RFC 1034 and RFC 1035. a. s/consist/consisting ? b. "three elements" in first sentence, then "one mechanism". Please align terms.
draft-ietf-ecrit-specifying-holes
Halfway serious question: can a hole have a hole? I think I can infer that the answer is "no" from the syntax; for clarity, it might be good to include an explicit statement that these polygons are either "exterior" or "interior" and an interior polygon cannot contain another interior polygon. Does this sentence from sectino 3 apply: Similarly, a polygon containing a hole with an island must be represented as two polygons mapping to the same service. Editorial nit: it's likely an obvious inference but it might be good to include an explicit description about which service to return, related to this sentence at the end of section 6: A location falls within the area described by a polygon if it is within the exterior boundary and not within any interior boundary. I.e., if the location falls within an interior boundary, map it to the interior service; if it falls within the exterior boundary and not within any interior boundary, map it to the exterior service.
Section 3., paragraph 1: > Holes related to an exterior boundary polygon MUST adhere to the > following rules: (...) Section 6., paragraph 0: > Interior parts are specified in clockwise direction, such that the > upward normal is opposite to the upward normal of the exterior part. DISCUSS: A quick glance at the GML spec seems to indicate that there is no requirement that interior rings can't overlap with themselves or the exterior in other ways than on a single point. There apparently also no requirement that interior rings need to specified in clockwise order. (And that exterior rings would need to be specified in counterclockwise order, if that's what's implied here.) Have I missed something in the GML spec? Or are we more restrictive than GML itself? If so, why?
Section 3., paragraph 5: > Figure 2: Incorrect Hole Specification with Boundary Sharing Nit: Suggest s/Incorrect/Correct/ similar to the captions of Figures 3 and 4. Section 3., paragraph 11: > 1 Polgon with a 2 Polygons that map Nit: s/Polgon/Polygon/
Ralph's question seems perfectly sound. In particular, the case where the hole in a hole yields the same destination as the polygon itself. It would be worth adding clarifying text for these cases. --- Nit: Section 1 s/that's/thats/ But note that "whose" is acceptable even though the protocol in inanimate.
Section 1 says: > > This document describes how holes SHOULD be specified in service > boundaries defined using a GML encoding for the polygons and their > internal elements (holes). > I think the following would be a better way to state the purpose of this document: > > This document describes the RECOMMENDED approach to specifying holes > in service boundaries defined using a GML encoding for the polygons > and their internal elements (holes). Section 7 says there are no security considerations. However, there seem to be some if these recommendations are not followed. Can we capture the most important ones in section 7?
AD to check LC comments
Figure 4 is labeled inconsistently, and may result in some confusion. I suggest adding the words "Incorrect" and "Correct", as in Figures 2 and 3, to the left and right polygons respectively. In this case, one needs to review the body text carefully to see that the left polygon is an incorrect specification.
Section 5 says that "Interior parts are specified in clockwise direction, such that the upward normal is opposite to the upward normal of the exterior part." but there seems to be no statement that the vertices of the exterior part are to be listed in counterclockwise direction. (That may be inherited from the GML specification.)
The working group did explicitly discuss recommending holes over dividing such regions into multiple polygons, but that discussion is not captured here. I suggest adding something like the following to note that discussion took place: The working group considered that the types of regions described in this memo could be represented in various ways as multiple polygons without holes, but concluded on the recommendations here to avoid potential problems with the arbitrary division of regions and to align with existing geospatial system practices. I also had to ask again about the island case and encourage making it easier to not miss that discussion.
draft-ietf-sip-domain-certs
I have reviewed draft-ietf-sip-domain-certs-05 and have couple of small concerns that I'd like to discuss before recommending approval of the document: - The document uses "AUS" as a synonym for the host (domain) part of the SIP URI. However, it looks like in RFC 3263 the AUS is actually the whole SIP URI. If that's the case, small clarifications (mostly of form "AUS"-> "domain/host part of the AUS") are needed. - Section 5 says: > Thus, in the certificate Proxy-A receives from Proxy-B, Proxy-A > looks for the host name ("Proxy-B.example.net") or an identity > consisting of a SIP URI ("sip:example.net") that asserts Proxy-B's > authority over the example.net domain. This is a bit confusing; according to the rest of the document, Proxy-A does NOT look for "Proxy-B.example.net" in the certificate, right? (only only "sip:example.net" or "example.net")
This is a Discussion point for the rest of the IESG and does not impact this document per se. The authors should not worry about it, and the Discuss will be cleared during the IESG telechat. I would like to use this document as an example to understand what sort of overlap is reasonable between IESG review and IETF Last Call. In this case the LC does not end for 8 days after IESG review. Where do we stand if the comments recieved during LC result in changes of substance to the document? Do we rely on the responsible AD holding a Discuss? What happens if the responsible AD thinks the changes are OK, but the rest of the IESG might not be so happy?
AD to check LC comments.
This looks like a fine document and I will vote No Objections after the call. But I would like to discuss a couple of things during the IESG telechat, as they also affect draft-saintandre-tls-server-id-check. 1) Recommendation to use EKU. 2) Use of URIs versa SRVName - advantages/disadvantages.
The first sentence of the introduction may have been accurate when this work started years ago. The phrase "has started to appear" is dated now, and should be updated.
draft-ietf-tsvwg-port-randomization
This is a good and much needed document, thanks for writing it. I did have one issue, however. Perhaps I'm missing something but the document first says: Port numbers that are currently in use by a TCP in the LISTEN state should not be allowed for use as ephemeral ports. but then later the algorithms say: if(resulting five-tuple is unique) return next_ephemeral; This does not appear to be sufficient to prevent the use of a port in the LISTEN state. The if statement simply checks whether there's an open connection between this host and some other specific host. It does NOT check whether there could in the future be a connection between this host and the specific host. If we are opening a connection for application X between hosts A and B, you cannot choose a port that another application Y is already listening on host A. Even if A and B at the moment are not having an open connection for application Y between them.
The document says: As mentioned in Section 2.1, the dynamic ports consist of the range 49152-65535. However, ephemeral port selection algorithms should use the whole range 1024-49151. Since this range includes ports numbers assigned by IANA, this may not always be possible, though. A possible workaround for this potential problem would be to maintain a local list of the port numbers that should not be allocated as ephemeral ports. Thus, before allocating a port number, the ephemeral port selection function would check this list, avoiding the allocation of ports that may be needed for specific applications. Ephemeral port selection algorithms SHOULD use the largest possible port range, since this improves obfuscation. First, what does the document actually recommend as the default policy? The use of the entire range, or the entire range minus locally configured list? Second, I think the comment about IANA isn't quite right above. The issue is not the IANA allocation, its the possibility that some application would be running on a port. You already discussed avoiding ports that are in the listen state. So this appears to leave only the case where the application is not yet running but will later run and want to use its well known port. Please be more specific about what the problem actually is.
I support Tim's discuss regarding port range selection.
I think there needs to be some text between this text in section 2.1: The dynamic port range defined by IANA consists of the 49152-65535 range, and is meant for the selection of ephemeral ports. and this text in section 3.1: It is important to note that a number of applications rely on binding specific port numbers that may be within the ephemeral ports range. If such an application was run while the corresponding port number was in use, the application would fail. Therefore, ephemeral port selection algorithms avoid using those port numbers. that explains the (as far as I can tell) unstated assumption that ephemeral ports could be selected from the IANA "registered" port range, 1024-49151. Reading on, it seems the issue is addressed here: 3.2. Ephemeral port number range As mentioned in Section 2.1, the dynamic ports consist of the range 49152-65535. However, ephemeral port selection algorithms should use the whole range 1024-49151. I suggest clarifying to: 3.2. Ephemeral port number range As mentioned in Section 2.1, the dynamic ports consist of the range 49152-65535. However, ephemeral port selection algorithms should also use available ports in the range of registered ports, 1024-49151. Therefore, the port selection algorithm should be applied to the whole range 1024-65535.
I have reviewed draft-ietf-tsvwg-port-randomization-06, and have couple of small concern that I'd like to discuss before recommending approval of the document: - Section 3.3.1 says '"random()" is a function that returns a pseudo-random unsigned interger number in the range 0-65535'. The document is not very clear on exactly what the requirements for this function are. If I recall right, the output of typical implementations of POSIX random() may look random to simple statistical tests, but it is not unpredictable (seeing couple of values allows you to fully predict future outputs). While this use probably doesn't need a cryptographically secure strong random number generator, it looks like some degree of unpredictability would be needed? - Section 3.4 suggests use of a 32 bit key, which has exploitable security problems -- to make the sequence unpredictable (even after seeing couple of values), more is needed (and since bits here are cheap, so there's no real reason to use less than 128).
Charlie Kaufman's SecDir review identified a number of minor clarifications/editorial nits that should be addressed; it seems the authors are already addressing those.
It is interesting that Algorithms 1, 3, and 4 statistically favor port numbers one greater than allocated port numbers. But probably not worth noting.
Since we are trying to replace the TCP MD5 signature option [RFC2385] with TCP AO, it seems like a bad idea to reference it in the document as a security solution. As pointed out in the Gen-ART Review by Avshalom Houri on 2010-03-03, the first portion of the document (up to and including Section 3.2) is lengthy and repeating while it is lacking some background. When and how are the techniques described in the document to be used? Is this texpected to be used in every transport protocol implementation in every environment? The Gen-ART Review by Avshalom Houri also makes many suggestions for improving the document. Please consider them.
One other issues that got raised was would it be possible to give advice about getting initial randomness. Perhaps pointers to other RFC. The problem is partially hard for a small residential NAT that has just booted. Saying there should be some randomness does not really help implementers without a way to do that. This is a very long discuss and many of the appoints in are purely asking we certain attacks considered. It's perfectly reasonable to resolve theses with a "Yes" and pointer to the list. RFC3605 is not commonly implemented for RTP and I find it very concerning that this would break RTP. The recommendation here violate the recombination in Req-4 of BCP 127. It would be very easy to define the algorithm here such that they preserved port parity. Why not do that? If one does not, some RTP receivers when told to send RTP to port x, will deice the parity is wrong and actually send it to x-1. This is not good. Breaking port+1 continuity breaks RTCP but that has not turned out to be as critical as breaking RTP. However, it would nice to see an this draft support that unless there was a reason it was not possible. Regardless of how we resolve this, I believe this draft needs to be changed so it is consistent with BCP 127, or we need to change BCP 127 before this can be published. We should not be publishing a draft that violates an existing BCP. I only find two normative statements. The first Ephemeral port selection algorithms SHOULD use the largest possible port range, since this improves obfuscation. This relies on the suggestion that somehow one would maintain a local list of port numbers that should not be allocated as ephemeral ports. How is a OS such as Linux supposed to actually implement this? Is there a list IANA is providing with real time updates? When IANA allocated a new port to a protocol, how long before they could reliably use that across existing computers. I don't find this to be implementable. I would like the draft updated such that it has advice that is clear to implementers what they need to do. I worry the current advice will result in ports such as 5060 being allocated and then servers tripping to run on that port not being able to get it for no reasons that is parent to the end user who will see it as an intermittent problem that goes away when they reboot. That not a design I would consider good for a BCP. The second normative statement is one SHOULD obfuscate the allocation of their ephemeral ports. It then goes on to describe a series of possible algorithm to do this which all seem to lack any crypto analysis. The problem of having a algorithm that generates a number that is hard to predict by an attacker that has seen the previous sequence of numbers the algorithm produced is pretty well understood so I expected to see pointers to concrete analysis here. Alg 1. If the attacker knows that port x in in use, they know that port x+1 is twice as likely to be chosen as the next port as say x-1. I'm not a crypto person but this sort of property always makes me pretty uncomfortable about deciding what the security properties of this are. Did crypto people look at it? Can we describe the security properties of this. Alg 2: You have count = num_ephemeral but I have a hard time imagining anyone would set it this high. It still won't guarantee 100% port usage as you point out in the note. It seem from the text below figure 3 you are saying that count = 2 would be fine. Same issue in some of the other ALGs. Alg 3: I'm fairly skeptical of the advice on choosing the key sizes. I'm not a crypto person but I'd love to see some analysis of this. Let's consider some different keys sizes (yes, I realize the draft recommends 32 or 64, I'll get to that). If the key size was 16, and the attacker could see what port was used for a single connection, they could brute force the key space and have the key, or at least a small number of possible entries for the key if there were collisions in the MD5 space. Now lets consider a 32 bit key. Again if the attacker could see two connections, they could brute force the space (the machine I am on right now looks like it would do that in about 5 seconds) on the first connection which would get them to about 2^16 possible keys, but on the second connection, they could filter these keys and get down to a very small number. Now I realize the draft says to use 64 bits it attackers can probe for ports but do we have any crypto analysis of any of this? If 64 bits enough? 32 bits clearly is not. If I could probe for several ports and had and FPGA card in my computer, could I easily figure out 64 bits? Is there discussion on this you can point me at? I suspect I would be much more conformable with something that had been looked at lots, like AES counter mode. Again, I'm not even qualified to suggest anything here but I'm looking for evidence the crypto stuff was seriously looked at. Alg 5: The idea that an end user should configure N does not seem practical. How would they figure out what to do. Most the implementors I know would choose 500 for the default because it was in the RFC and the RFC was golden and you MUST do exactly what it says, unless of course it is a SHOULD in which case they don't even bother to read it much less do it but I degrees. The 500 is going to have a wrap around after a mere 256 ports while at the same time only proving a 8 bits of security which seems like it would be inadequate for many cases. This is harmful in that it passes an impossible hard problem of choosing a good value of N to the end user which will not provide security while at the same time providing the illusion of being more useful than it probably is. If this algorithm is not a good choice, remove it from the BCP. If it is only a good choice for certain cases, make it clear which cases this should be used instead of the other ones. Section 3.5 provides some ideas about pros and cons of various algorithms but no real advice one which ones to use and when. Would if be possible to pick one algorithm and just recommend that? If the view is we need to develop experience to find out which one of these is the best for a general OS, then this should be experimental not BCP. I find this far from what I would expect in a BCP on such an important topic. I think it could be vastly improved by having the security folks define an algorithm, working with the Apps, RAI, and behave folks to make sure that it does no more harm than necessary to existing applications. And overall make it be a tight specification where it is clear what an implementation MUST do to be compliant. A draft where vendors can have very poor implementation and still claim to be compliant is not good.
For the IESG more than the authors .... My current understanding of BCP would imply this should be a PS that update TCP, UPD, DCCP, and SCTP but I don't really understand why it is a BCP. Though ephemeral pot sounds of some relevance to my discuss, I suspect you want a s/ephemeral pot/ephemeral port/ Having made a nearly infinite number of typos in my life, I did like this one.
There are a couple of issues I would like to discuss before moving to No Object for this document... (1) Section 3.2 states that "ephemeral port selection algorithms should use the whole range 1024-49151." [As noted in the comment section, I believe that 49151 should be 65535.] I get the concept of using the largest possible range, but this seems to violate the spirit of RFC 4340, among others. The following paragraph notes that this range includes assigned ports so "this may not be possible". Upon review, a very significant number of ports in the range 1024-49151 have been assigned. I would like to understand how to determine which of the set of IANA registered ports should be made available for ephemeral port selection. (2) There are issues with the computation of next_ephemeral in Algorithm #1 which will skew the selected. While the impact of this issue in isolation is relatively minor, the fix is very straightforward. (See follow up email.) (3) Depending upon which IANA registered ports are available for ephemeral port selection, issues 1 and 2 in combination with algorithm #1 can create a situation where certain ports in the range 1024-49151 are significantly more likely to be selected. (See follow up email.)
section 3.1, final paragraph s/DCCP is not affected is not affected/DCCP is not affected/ Section 3.2 states: As mentioned in Section 2.1, the dynamic ports consist of the range 49152-65535. However, ephemeral port selection algorithms should use the whole range 1024-49151. Shouldn't the whole range be "1024-65535"?
I support the issues raised by Pasi, Robert and Tim in their DISCUSSes
Before suggesting that NATs follow the recommendations in this document, there should be more discussion of the impact of the recommendations on deployed systems using symmetric RTP/RTCP that expect sequential binding.
The text should acknowledge that applications using RTP are really at the mercy of what their underlying UDP implementation (for the current majority of RTP users anyway) chooses to do with this recommendation.
Section 4. If this document is supposed to make recommendations on NAT behavior I think it needs to discuss when it makes sense in the context of the terminology of the NAT behavior documents, like RFC 4787 and 5382 that do discuss port assignment in the NAT. As I see the NAT behavior around port obfuscation is dependent on at least three things. The nat's port assignment rule, if it is preserving. Secondly what it does when it fails to preserve and if it has port parity preservation. So I find the text under specified, but still gives recommendations that do go against the current BCPs. Thus we must also consider if this document actually updates theses BCPs.
draft-ietf-geopriv-loc-filters
This is a good document and I was ready to ballot Yes. However, like other reviewers I had trouble with the normative requirements. In my case Section 3.3 said: An implementation MUST support the functionality as shown in Figure 3 with <ns-bindings> replacing the prefix. No other variant is supported. I do not understand what to implement based on this. In particular, Section 3.3 has also Figure 4 that shows another variant. Is only the first one required to be supported? What exactly does "MUST support this example snippet of XML" mean?
Section 9.1., paragraph 2: > [I-D.ietf-geopriv-arch] > Barnes, R., Lepinski, M., Cooper, A., Morris, J., > Tschofenig, H., and H. Schulzrinne, "An Architecture for > Location and Location Privacy in Internet Applications", > draft-ietf-geopriv-arch-01 (work in progress), > October 2009. DISCUSS: Downref: Normative reference to an Informational draft: draft-ietf-geopriv-arch (ref. 'I-D.ietf-geopriv-arch'). Didn't see it called out in the IETF LC.
Non-blocking comments: Section 3.1., paragraph 1: > The <moved> element MUST contain a value in meters indicates the > minimum distance that the resource must have moved from the location > of the resource since the last notification was sent in order to > trigger this event. Note that the condition could be met by a change > in any axis including altitude. But surely not only by change along a single axis, right? (I think what you mean is that the length of the vector between the two points is longer than <moved>.) Section 5.2.3, paragraph 1: > If the Target was previously outside the region, the notifier sends a > notification when the Target's location is within the region with at > least 50% confidence. Similarly, when a Target starts within the > region, a notification is sent when the Target's location moves > outside the region with at least 50% confidence. Why 50%? Why not 30 or 70%? (Magic number.) Section 5.2.3, paragraph 2: > Note that having 50% confidence that the Target is inside the area > does not correspond to 50% outside. The confidence that the location > is within the region, plus the confidence that the location is > outside the region is limited to the confidence of the location. The > total confidence depends on the confidence in the location, which is > always less than 100% (95% is recommended in [RFC5491]). The benefit > of this is that notifications are naturally limited: small movements > at the borders of the region do not trigger notifications. Whether the last sentence is true depends entirely on how accurate the positioning is compared to the movement. Section 9., paragraph 0: > 9. References idnits reports several unused references, including normative ones. Section 3.3., paragraph 5: > In times where it is desireable to know if any one element of a list Nit: s/desireable/desirable/
I found the second paragraph of Section 1 hard to parse The frequency of notifications necessary for various geographic location applications varies dramatically. The subscriber should be able to get asynchronous notifications with appropriate frequency and granularity, without having to issue a large number of notifications that are not important to the application. The second sentence appears to mix "getting" notifications with "issuing" notifications. Are you attempting to distinguish asynchronous notifictations from requst/response transactions? --- Nit of the smallest type Section 1 s/that allows the number/that allow the number/
The Gen-ART Review by Ben Campbell on 9 March 2010 raised some concerns that ought to be addressed before this document is approved, and I have summarized them below. (1) Section 3.6 seems to create a profile of the rate-control document, but minor modifications to the normative requirements are made. Can you motivate why rate-control does not work as-is? If not, perhaps the two documents should be harmonized. (2) The empty notify language in the 2nd paragraph of Section 3.6 seems to conflict with the MUST statements in rate-control document: > > ... depending on the event package and subscriber > preferences indicated in the SUBSCRIBE request, the NOTIFY request > MUST contain either the current full state or the partial state > showing the difference between the current state and the last > successfully communicated state. > This also indicates that the two documents should be harmonized. (3) In Section 3.2, first paragraph after figure 2, the text effectively declares the example as normative, but fails to offer normative text. Also, the "No other variant" language is confusing; it is not clear what restriction in the example is constrains <ns-binding>. Please make the examples informative and provide normative text.
The Gen-ART Review by Ben Campbell on 9 March 2010 raised some concerns that are not included in my DISCUSS position. Please consider them.
AD needs to review LC comments
3.3. Element Value Changes Figure 3 shows an example where a notification is sent when the civic address tokens A1, A2, A3, or PC change (all 4 must change in order to let the <trigger> element evaluate to TRUE). In times where it is desireable to know if any one individual of a list of CAtypes change, then they have to be put into separate <changes> filters to ensure you are notified when any of the element values change. In the last sentence: do you mean something like: <filter id="123" uri="sip:presentity@example.com"> <trigger> <changed>//ca:A1</changed> </trigger> <trigger> <changed>//ca:A2</changed> </trigger> <trigger> <changed>//ca:A3</changed> </trigger> <trigger> <changed>//ca:PC</changed> </trigger> </filter> instead of: <filter id="123" uri="sip:presentity@example.com"> <trigger> <changed>//ca:A1</changed> <changed>//ca:A2</changed> <changed>//ca:A3</changed> <changed>//ca:PC</changed> </trigger> </filter> ? 3.5. Location Type: <?xml version="1.0" encoding="UTF-8"?> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter" xmlns:lf="urn:ietf:params:xml:ns:location-filter"> <filter id="123" uri="sip:presentity@example.com"> <what> <lf:locationType exact="true"> geodetic Are leading spaces insignificant in this case? </lf:locationType> </what> </filter> </filter-set>
The DISCUSS and COMMENT issues are based on input from Dale Worley. The following items are problematic as they point to ambiuities in the specification: 1. Section 3.3, element value changes: In the example, changes in the subordinate civic address components "A1", "A2", etc. will cause a trigger, but changes in "country" will not. This is probably unrealistic; in a realistic application, a trigger on one civic address component would be or'ed with triggers on each higher-level civic address component. 2. Section 3.3, element value changes: The statement "An implementation MUST support the functionality as shown in Figure 3 with <ns-bindings> replacing the prefix. No other variant is supported." is nowhere near clear enough to be a specification. In particular, the uses in figures 4 and 5 are clearly distinguishable from the use in figure 3 (based on the number of <trigger> and <changed> elements).
1. The draft could use a careful editing for English usage. Some problems are simple statement structure (e.g., "This document defines a new event filters and describes others using existing mechanisms that may be relevant to a subscriber in the context of location filtering:" does not grammatically connect to the following list). Other problems leave out information (e.g., the text of section 3.1 does not state that the <moved> element is a child of the <trigger> element, although the example makes that clear). 2. Section 3.2, speed changes: The statement "An implementation MUST support the functionality as shown in Figure 2 with <ns-bindings> replacing the prefix. No other variant is supported." is nowhere near clear enough to be a specification. 3. Section 3.6, rate control: It might be useful to provide a more extended example than figure 9, one that shows the initial SUBSCRIBE and NOTIFY, and the subsequent SUBSCRIBE that lengthens the max-interval value.
Section 3.6 should be more clear on whether it is restricting the use of all the mechanics in event-rate-control, or only noting which of those mechanics need to be used to achieve the purpose addressed in this draft. In particular, I suggest changing "The implementation of only these two attributes" to "The use of only these two attributes". Ben Campbell's genart review comments are related.
These are very small nits: 2nd paragraph of 3.3 would read more correctly if you said A1, A2, A3 _and_ PC change. <changes> is a typo The labels for figure 3 and 4 are wrong - should say Element Value Change Example
draft-ietf-6man-ipv6-subnet-model
I concur with Ralph's DISCUSS. There is very little new in this document. Maybe the issues is best handled with an errata to the document that it updates.
Regrettably, I'm having some trouble with access to the datatracker today, and my original DISCUSS text was lost. Retyping... I'm raising a discuss-discuss. Do we need a full document to achieve the goals? Can the changes to RFC 4861 be accomplished with an Errata? Much of the document is a restatement of other RFCS and I worry that the RFC 2119 requirements may be confusing or subtly in conflict with other RFCs. How often has the behavior in section 4 been observed; I'm aware of one mis-implementation that was corrected some time ago. From list item 3 of section 2: Neither of these tests are acceptable definitions for an address to be considered as on-link as defined above, and this document deprecates and removes both of them from the formal definition of on-link. Why are these test not acceptable definitions for on-link?
This document needs a terminology section to define or point to the intended definition of "subnet" and various terms from RFC 4291, et al. such as Prefix List. Pointers to some of the terms are given in the body of the doc, not always on first reference, and a terminology section would be helpful. --- "The original Neighbor Discovery (ND) specification [RFC4861]": s/original//; RFC4861 is the current ND specification. --- From bullet 2 of section 2: Redirect Messages do not contain sufficient information to signal that an address is off-link. Redirect messages give no indication either way about on- or off-link; perhaps reword as: Redirect Messages do not contain any information about whether an address is on- or off-link. ---
Section 4., paragraph 0: > 4. Implementations compliant with [RFC4861] MUST adhere to the DISCUSS: The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords.
The Gen-ART Review by Pete McCann on 2010-03-09 included some editorial comments. Please consider them if an update to this document is needed for any reason.
This is a DISCUSS DISCUSS, which I believe needs clarification before I can approve this document. Some of the requirements in sections 3 and 4 modify the hosts behavior defined in RFC 4861 that this document updates. RFC 4861 is however a Draft Standard, so would not approving these changes modify the interoperability conditions on which base the advancement of 4861 from PS to Draft was approved?
I support Lars' DISCUSS about the need to include mandatory 2119 boilerplate.
draft-ietf-mext-binary-ts
Section 3.1 The alignment requirement for this sub-option is: 4n if A, B, C, D, E, or F is set 2n if G, H, I, or J is set n if K, L, M, N is set Is there a missing "or" in the last line? If J and K are set, is the alignment 2n or n? What does it mean to have an alignment requirement of 4n? --- I agree with Cullen that reviewing this before draft-ietf-mext-flow- binding seems rash. Isn't it possible that review comments on that other document might require changes of substance here. I suggest that the responsible AD should hold a Discuss until the other document is completed.
1. This is a discuss question that I do want to have answered before endorsing publication of this document. As it is not clear what the purpose of these traffic selectors are. Do you need to have a traffic selector for the DCCP Service Code? Considering that you included other special fields I think this needs to be considered. However, that would only separate out the initial connection establishment for DCCP. Not that it may not be unimportant as DCCP do allow for multiple services to share a port. And if one needs to separate traffic for one of these services and then update with more specific filtering rules after having detected the first packet? 2. Section 3.1, (K)Start DS - Differential Services: For the purpose of this specification the DS field is 8 bits long, were the 6 most significant bits indicating the DS field to be matched and the 2 least significant bits MUST be set to 0 by the sender and ignored by the receiver. To me it appears to be the wrong specification of how to treat the ECN bits. It is very important that anyone trying to match a DS start value against an actual packet flow must not include the two least significant bits in this octet that are used for ECN. Otherwise you select packets from the flow in a very strange mannor. This also applies to Section 3.2 field M specification
draft-ietf-dnsext-dnssec-alg-allocation
INTRODUCTION, paragraph 2: > Updates: 2535, 3755, 4034 (if approved) It's a bit odd to update RFCs that have already been obsoleted (2535, 3755).
In section 2, the document says: > > ..., the IETF SHOULD re-evaluate the requirements for entry into > this registry when approximately 120 of the registry entries have > been assigned. > RFC 2119 does not apply to this statement: s/SHOULD/should/ If it did, then a reference to RFC 2119 would be needed. Section 4 reserves values 123 through 250 in the IANA registry: http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml It should reserve through 251.
DISCUSS DISCUSS. I'd like to ask the AD to have a look at Sam Weilers, comments from Jan 9 and resulting threads. My read of the list is that there was consensus that non Standards Track RFC could not specify a MANDATORY algorithm and I'd like to understand if I misreading the consensus here. If there is consensus for this, the I think this draft needs to reflect that consensus and would agree with Sam Weiler's email of March 2 that was sent to IESG and secdir list.
IANA Considerations - 'IANA is requested to mark values 123 through 250 as "Reserved".' As the 'Resrved lable is applied only in order to trigger a review of the policy of administration of this registry in case entries are consumed at a higher rate than expected, I think that a comment should be made that the reservation is made per RFC XXXX (where XXXX is the number of this RFC when approved) so then when this event happens future IANA and users generation will have an easy pointer to where this came from.
I agree with Russ' DISCUSS comment - the range of Reserved should extend to include 251.
draft-ietf-tcpm-tcp-auth-opt
Section 2.1, third para: s/TCP-AO not/TCP-AO is not/
I have reviewed draft-ietf-tcpm-tcp-auth-opt-10, and have one concern that I'd like to discuss before recommending approval of the document: It seems TCP-AO is mainly useful for places where TCP-MD5 is used today (i.e., routers), and most hosts on the Internet would never need it. Given this, "TCP implementations MUST support TCP-AO" does not sound reasonable to me.
Thanks for this document. General sigh of "at last" :-) A few small wrinklettes... ISN is used in Section 1 without expansion. (although it is subsequently expanded multiple times) --- Section 4.2 >> The Length value MUST be consistent with the TCP header length; this is a consistency check and avoids overrun/underrun abuse. When the Length value is invalid, TCP MUST discard the segment. "MUST be consistent" is a little vague. I can only assume that you mean that the length must not imply that the option extends beyond the end of the header as specified by the header length. --- MKT is used in Section 4.2 without expansion or reference. Add a forward pointer to 5.1? --- Semantic tautology. I think the phrase "TCP-AO option" may include some redundancy. Cf. the header to Section 4.2. --- Section 9.1 s/implmentation/implementation/
The Gen-ART Review by Wassim Haddad on 2010-03-09 raised two minor issues: - Page 13, Figure 3: traffic keys derived show two "Send_Other_key" in all 3 boxes. Shouldn't be Rcv_Other_key? - Page 37: sub-section 2: a) Privacy: "TCP exposes "only" the MKT IDs, MAC, and overall option. Question: is "only" really needed? I think the first one ought to be corrected. Please consider the second one as well.
The Gen-ART Review by Wassim Haddad on 2010-03-09 included some editorial comments. Please consider them if an update to this document is needed for any reason.
The drafts says TCP implementations MUST support TCP-AO. This would require this draft to be an "update" to the base TCP spec. Given that this does not work with NATs, I think it is too much to expect all implementations to support it. Many devices are nearly 100% deployed behind NATs and have close to no need for the security this provides. Is there some discussion on some list I should go read about this to get an idea of the Consensus for this?
Give this disables much of ICMP, particularly destination unreachable, would it be worth mentioning in the applicability statement of situations when it was not appropriate to use it or timing consideration changes that needed to be made to applications using it?
This is a good document. I have one probably pedantic and trivial to address comment, but I would like to fully understand the implication of the following text before recommending approval of this document: 10. Obsoleting TCP MD5 and Legacy Interactions TCP-AO obsoletes TCP MD5. As we have noted earlier: >> TCP implementations MUST support TCP-AO. Does this mean that the document should include the appropriate "Updates: <TCP spec>" field at the top?
4.2. The TCP-AO Option o RNextKeyID: An unsigned 1-byte field indicating the MKT that the sender is ready use to receive authenticated segments, i.e., the "ready use to receive"? desired 'receive next' keyID. 14. IANA Considerations [NOTE: This section be removed prior to publication as an RFC] I don't think this note is correct, the section is non empty.
I support the discuss positions regarding the conformance language ("MUST support") for implementations of TCP.
draft-ietf-yam-rfc1652bis
Section 4., paragraph 1: > The following dialogue illustrates the use of the 8bit-MIMEtransport > service extension: Suggest to use RFC2606 example domains in this example.
This is a process question for the IESG and not meant for authors of WG. So given the text of LC was clear the downref was for all of RFC 2045, RFC 2046, RFC 5321 and RFC 5322 (all Draft Standards), I think those just all got moved to Full Standard at same time. Will the IESG announce they have been move to Full Standard to as part of this announcement?
draft-ietf-tcpm-tcp-ao-crypto
I have reviewed draft-ietf-tcpm-tcp-ao-crypto-02, and have couple of small concerns that I'd like to discuss before recommending approval of the document: - In other contexts where manually configured pre-shared keys are used, it has been found useful to specify some minimum requirements for management interfaces -- i.e. how the human-readable/entered input is converted to the octet string. For example, here's what draft-ietf-bfd-base said about this: For interoperability, the management interface by which the password is configured MUST accept ASCII strings, and SHOULD also allow for the configuration of any arbitrary binary string in hexadecimal form. Other configuration methods MAY be supported. Something similar would be needed here, IMHO (and BTW, I don't think mandating support for UTF-8 or SASLprep is needed in this context). - It looks like many of the informative references need to be normative. At the very least, RFC 4493 (or NIST-SP800-38B, depending on which you prefer) and RFC 2104; and normative references to AES (FIPS 197) and SHA-1 (FIPS 180-3) are needed, too. - Section 3.1.1, "based on PRF-HMAC-SHA1 [RFC2404]": the pointer to RFC2404 here doesn't sound quite right (2404 doesn't define any PRFs; it's just one protocol that happens to use HMAC-SHA1). Perhaps just "based on HMAC-SHA1 [RFC2104][180-3]" would be sufficient? (also applies to pointers in 2.2, 3.1.1.1, and 3.2) - Section 3.1.1, "based on AES-CMAC-PRF-128 [RFC4615]": This is also confusing, since the PRF in RFC 4615 uses a very different construction. Perhaps just "based on AES-CMAC [800-38B][FIPS197]"? (also applies to pointer in 3.1.1.2 ) - Section 3.1.1: "not an even multiple of the output size" initially confused me (why an odd multiple is not allowed?). "exact multiple", perhaps?
Idnits finds some missing/erronous references (which really ought to have been fixed before sending this to IETF last call...)
The Gen-ART Review by Avshalom Houri on 2010-03-09 includes some editorial comments. Please consider them if an update to this document is needed for any reason.
Agreeing with Pasi's DISCUSS on management interface for keys. 3.1.1. Concrete KDFs - "||": For any X || Y, "||" represents a concatonation "concatenation"? operation of the binary strings X and Y. - Output_Length: The length in bits of the key that the KDF will produce. The Output_length is represented within two octets. This length must be the size required for the MAC algorithm that will use the PRF result as a seed. I assume this is in network byte order? It would be better to state this explicitly.
draft-ietf-mip4-rfc3344bis
There is an Erratum reported against RFC 3344. It should either be: - verified and incorporated into this document or - rejected
The Gen-ART Review by Miguel Garcia on 2010-03-08 raised a few editorial issues. Please consider them. I would really like to see the comments about Appendix G addressed, so it is repeated here for convenience: - The structure of Appendix G is a bit confusing. Section G.1 lists the changes made since RFC 3344. Sections G.2 and G.3 list the Major and Minor Changes, respectively, but it is not clear to me if these are changes since RFC 3344 or they include earlier changes as well. To add more confusion, Section G4 lists the changes since RFC 3344, but wasn't this what Section G.1 is all about?
draft-ietf-smime-cms-rsa-kem
I have reviewed draft-ietf-smime-cms-rsa-kem-12, and have couple of small concern that I'd like to discuss before recommending approval of the document: - It looks like the ASN.1 is not fully aligned with 18033-2 and X9.44. I might be misinterpreting this, but to me it looks like 18033-2 and X9.44 would use OID "id-ac-generic-hybrid" (instead of id-rsa-kem) as the "top-level OID", and id-kem-rsa would be found in GenericHybridParameters.kem structure. (The OID id-rsa-kem doesn't seem to occur in 18033-2/X9.44 at all? And BTW, it's *very* confusing to have two different OIDs named id-rsa-kem and id-kem-rsa.) - Section 2.1, "KDF3 (see [IEEE-P1363a])": IEEE 1363a-2004 doesn't have KDF3; it does, however, define KDF2. Should this be KDF2, or should the reference point to X9.44? - It looks like ANS-9.44 needs to be normative references, since you need the KDF to implement this.
Typo: A.2, "public key n,e)" -> "public key (n,e)"
The second Last Call expires 2010-03-11. The IESG should not declare that the downrefs called out in that Last Call are acceptiable to the community until the Last Call is actually over. I do not expect any objection, but let's not jump the gun.
Thanks for the examples in the back. I know they helped at least one implementor.
draft-gould-rfc4310bis
Thanks for the clear and concise Appendix A that made reviewing this document so much easier.
5.2.5 <update> command If the server does not support the "urgent" attribute, or cannot expedite processing, it returns an error message. Does the server still perform the update, or is the update completed at the lower priority?
draft-arkko-pana-iana
Editorial nit: 2.4 and 2.5 "for these bits" -> "for these values"
16 experimental message types look like a lot. I can imagine a single experiment that might need 4 or 5. The risk, always, is that there are enough codepoints that people start to have expectations about their persistence. If you were able to reduce this pool I would not be unhappy.
The Gen-ART Review by Wassim Haddad on 2010-03-09 included very minor editorial comments. Please consider them if an update to this document is needed for any reason.
draft-ietf-mpls-mpls-and-gmpls-security-framework
Typo and question, end of section 4.1: This section is focused outsider attach. The insider attack is discussed in section 4.4. Change first sentence to "This section is focused on outsider attacks." Are all of section 4.1-4.3 focused on outsider attacks or just section 4.1? --- In section 5.2.4: Bullet formatting in list after "The following is a non-exhaustive list of PW- specific threats:" is incorrect. In a bullet list a little farther along: - Since guessing a valid PW label is not difficult - it is relatively easy to introduce seemingly valid foreign packets delete second bullet marker "-" " --- Several bullet lists in section 5.2.5 are formatted inconsistently (I'll stop commenting on bullet list formats now!) --- Section 7.1.1: add citation of RFC 2385 to mention of TCP MD5?
draft-ietf-ecrit-framework
The Gen-ART Review by Francis Dupont on 2010-03-05 raised two minor issues. What, if anything, was done to address these IETF Last Call comments: (1) the Terminology is incomplete, no PSAP for instance (2) the GPS stuff seems a bit USA centric; you should show the document to a GPS (or Galileo) expert
The Gen-ART Review by Francis Dupont on 2010-03-05 included some editorial comments. Please consider them if an update to this document is needed for any reason.
AD needs to check if any new LC comments came. Few small comments as part of my AD review. Typically I would have sent these before IETF Last Call but given the timing of the IESG calls and next IETF meeting, I decided we could sort them out as part of IETF Last Call. They are all small and could likely be fixed with RFC Editor notes after we decide what they need to say. 6.2.1 Para 2. The statement that user provided location information is less accurate seems to be contradicted by the later statement that emergency responders will be dispatch to user self-declared location. I know what you are getting at here but seems like some words could be tightened up. Section 9.1 - para 1. Typo with the xref. Section 10. The text around the contact header and GRU does not seem right. Are contacts optional in an INVITE? a device with a global reachable IP can still use a GRU. When you say that the B2B contact manipulations should result in a contact header that is usable for call back it sounds like you are saying that current B2BUAs will all do this. Is that true or did it mean to say this can be a problem and they need to do this? The text here just seems to a a bit out of sync with the phone-bcp. Just have a look at this section and see if you think any changes are needed. Section 10. Use of PAI. Need to discuss how this works with anonymous call. Places like women's shelters, or many phones in some legal jurisdictions, typically configure all calls to be anonymous in the 3325 sense yet it seems like they still need call back from emergency call to work. I also wonder about how the spec-T would work. If the solutions requires every service provider to have a spec-T with every psap, this does not seem feasible. How does the PAI not get removed when passing it to out of the domain of the service prover and too the psap? Section 14. 2nd para. At the time this was first written, this was true, however, at this point of time the IETF does have consensus about keying for SRTP. It seems that given that security is desirable, we should use the agreed on keying solution.
Last paragraph of section 5: These restrictions on UA design are out of place for an IETF document. If the intent is to just ask UI implementors and regulators to consider these concerns, the language should be adjusted. 2nd paragraph page 18: "[RFC4119] with a recent extension [RFC5139]" ages badly. Suggest "[RFC4119] with an extension [RFC5139]" instead. Section 9.3 needs a little more clarity to reflect 6.3 correctly. It is not clear enough that this should only happen if the UA has not provided location information itself, and needs to discuss how the proxy determines whether UA has sufficient support on its own. Some pointers to other discussion in this document may help, but as written, this can be read to require a proxy to perform these actions no matter what the UA does. The sentence "This is a change from [RFC3261] where the Contact: header is optional." is incorrect. Inclusion of a Contact header field in an INVITE request is MUST strengh for a UAC in 3261. UASs are allowed to accept INVITE requests without a Contact header field only for backwards compatibility with RFC2543 implementations. Section 15, paragraph 2 is missing a reference to PhoneBCP at the beginning of the sentence.
Section 1: PSAP is not explained in this section, please write out on first usage Section 1: NENA (National Emergency Number Association): I guess that this is an USA National association, if that is true please make it clear. Section 6.2.2 The threshold for when interior location is needed is approximately 650 square meters. This value is derived from fire brigade recommendations of spacing of alarm pull stations. However, interior space layout, construction materials and other factors should be considered. In this type of reference it would be good to specify which fire brigade that has this recommendations. I would be highly surprised if the California recommendations are exactly the same as the one in Stockholm.
draft-ietf-geopriv-prefix
Section 2.1., paragraph 1: > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. Unused Reference: 'RFC2119' is defined on line 113, but no explicit reference was found in the text
AD to check LC comments AD to check IANA is OK
draft-ietf-autoconf-adhoc-addr-model
The document include RFC 2119 boilerplate but uses lower case requirements words throughout both normatively and non-normatively. I know this document comes from the autoconf working group, but as far as I can tell, none of the principles or rules are specific to autoconfiguration. The term "autoconfigure" is used only sporadically in the document. Is this document specifically about autoconfiguration or configuration in general? It would help to include some text explaining the scope of the document.
Expand DAD (end of section 6.2). For consistency, either use "DAD" in both 6.1 and 6.2, or in neither. --- The first paragraph of section doesn't accurately describe the applicability: The configuration proposed by this model is applicable to any router's IP interface. It specifies IP addresses and IP subnet prefixes to be configured on network interfaces. Perhaps "This model gives guidance about the autoconfiguration of IP addresses and the IP subnet prefixes as on-link on router's IP interfaces."?? --- I was OK with section 4 up to and including the principle about not configuring an interface with any knowledge of on-link prefixes. Then I got lost. While the following paragraph about L2 communication regardless of configuration of on- link prefixes is true, it's seems irrelevant because the principle advices against the configuration of on-link prefixes. The last paragraph may also be true, but appears out of place in a document about a network model in which nothing can be guaranteed about on-going L2 connectivity. --- Re-reading sectinos 6.1 and 6.2, I am pretty sure there is no fundamental difference in the ways in which this model can be applied to IPv6 and IPv4. For example, doesn't this observation apply to IPv4 as well as IPv6? o There is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, hence they can not be used to reliably identify routers. "routers" or "router interfaces" - which hints at something that might need clarification: IP addresses are used both as interface addresses and sometimes, by selecting one global address from those assigned to the interfaces, as an identifier for the entire router. Why does the model suggest no on-link prefixes for IPv6 and allow /32 on-link prefixes for IPv4? Why not /128s for IPv6 or, conversely, no prefixes for IPv4? ---
> IP Addressing Model in Ad Hoc Networks Title doesn't fit the document too well - the document is not only about ad hoc networks, and it doesn't describe a general IP addressing model, just guidelines for addressing router interfaces.
It seems the content of this document could be summarized "if you want to use a routing protocol that requires unique addresses (within the routing domain), link-local addresses are not sufficient (since they're unique only within a link)". I wonder if the document title should be more precise about this? Perhaps something like "Why Link-Local Addresses Are Not Sufficient For Ad Hoc Routers"?
The Gen-ART Review by Francis Dupont on 2010-02-27 included very minor editorial comments. Please consider them if an update to this document is needed for any reason.
draft-ietf-csi-hash-threat
Well written document, thanks. I had a few comments though: Term ADD not defined. > Theoretically this attack could harm > SEND, but in real-world situation is to achieve it. ... is hard to achieve it? > From the security > point of view, at the moment, this solution is more reasonable > then defining different hash algorithm for each hash. ... than defining ...? > The computation of the Digital Signature field is described > [rfc3971]. ... described in? > The computation of the Digital Signature field is described > [rfc3971]. It is produced as the SHA-1 hash over the IPv6 addresses, > the ICMPv6 header, the ND message and other fields, e.g. the Message > Type Tag and ND options, and signed with the sender's private key. > Private key corresponds to the public key in the CGA parameters > structure. It is usually authorized through CGAs. The signature field simply binds the private and public key together. It works for both CGA and certificate-based SEND. Indeed, routers use the certificate-based mode in practice exclusively. > o The third possible solution is to encode the algorithm in the CGA. > This would reduce the strength of the CGA and make it vulnerable > to brute force attacks. ... and also bidding down attacks, if I'm not mistaken. If the hash algorithm is part of the CGA parameters structure, simply choose a hash algorithm that is completely broken and find a value that matches the victim's address AND uses the bad algorithm within the CGA parameters structure. > o Possible solution is also the hybrid solution which would require > the hash algorithm to be the same as CGA, if CGA option is > present, and to use the Hash agility option if the CGA option is > not present. In such way, SEND is not bound exclusively to CGA. Isn't there also a hybrid solution where the hash is in the address bits for CGA based addresses, and all certificate-related hash operations are in the certificate? But maybe I'm missing something obvious. > o None of the previous solutions supports the negotiation of the > hash function. One of possible solutions is the negotiation > approach for the SEND hash agility based on the Supported > Signature Algorithm option described in [sig-agility]. I would have noted the bidding-down issue already here (as you do for some other alternatives). > The negotiation approach for the hash agility in SEND based on the > Supported Signature Algorithms option is vulnerable to bidding-down > attacks, which is usual in the case of any negotiation approach. > This issue can be mitigated with the appropriate local policies. Perhaps some mitigation can be offered, but policy really isn't a solution to the bidding down problem. Anyway, the security consideration section kind of ends without making a conclusion. My conclusion -- perhaps not surprisingly! -- is that the RFC 4982 approach seems to be valid approach. And this is what current standards track specifications say. Do the authors of this document want to change that situation, or not? It would be useful to draw a conclusion.
Is this document INFORMATIONAL or STANDARDS TRACK? The ballot say INFO and the document says STANDARDS TRACK. If you meant to say INFORMATIONAL, I will be happy to clear this discuss.
Intended status is informational.
INTRODUCTION, paragraph 2: > Intended status: Standards Track DISCUSS: I may be missing something obvious, but why is this document on the standards track? It's a threat analysis that merely makes a few observations on hash agility might be added to SEND in the future. Wouldn't Informational be the appropriate category?
COMMENT: AD, this document needs a ballot issued. List of editorial nits sent directly to the authors.
Based on the SecDir reviews by Julien Laganier and Paul Hoffman, it seems this document needs a major rewrite (and one of the authors seems to agree): http://www.ietf.org/mail-archive/web/secdir/current/msg01540.html http://www.ietf.org/mail-archive/web/secdir/current/msg01537.html http://www.ietf.org/mail-archive/web/secdir/current/msg01536.html
There are a couple of minor warnings reported by idnits, and it would be good to fix these if a new revision of the document is being prepared. --- Section 3.2 s/concer/concern/ --- Section 3.2 Even though real-world scenarios make SEND immune to recent hash attacks introduced through X.509 certificates, theoretically they are possible. This feels like a contradiction or is confusing. If the attacks are possible, do we need to worry about them? If SEND is immune, we do not need to worry even if the attacks are easy and possible. If we *do* need to worry about them, then obviously SEND isn't immune.
Assuming Informational RFC. The Gen-ART Review by Pete McCann on 2010-03-09 included some editorial comments. Please consider them if an update to this document is needed for any reason.
The OPS-DIR review performed by Richard Woundy raised a number of issues that deserve consideration before the document can be approived: 1. Section 3. “Supposing that the hash function produces an n-bit long output, since each output is equally likely, an attack takes an order of 2^n operations to be successful. Due to the birthday attack, if the hash function is supplied with a random input, it returns one of the k equally-likely values, and the number of operations can be reduced to the number of 1.2*2^(n/2) operations.” About the use of ‘n’ and ‘k’ as variables. Does k = 2^n? Worse yet, the only other time ‘k’ is mentioned as a variable, it is defined as a key (in section 3.4). In any case, I would change the second sentence to something like the following for greater clarity: “Due the birthday attack, if the hash function is supplied with a series of random inputs, the likely number of inputs required to produce a single hash collision can be reduced to 1.2*2^(n/2).” Is there a solid technical reference to the “birthday attack”? Since I am not a security expert but otherwise curious about this, I looked it up in Wikipedia: <http://en.wikipedia.org/wiki/Birthday_attack>. The Wikipedia article suggests that the number of hash inputs to obtain a single hash collision can be reduced to about 1.25*2^(n/2) input – where 1.25 is approximately the square root of pi / 2 – but I am not sure about the mathematics. Again, I AM NOT A SECURITY EXPERT. 2. Section 4. There are five proposed solutions to enable SEND to leverage new hash algorithms (such as SHA-3) via hash algorithm agility. Which of the solutions is the recommendation of this document? I am guessing it is number five: “negotiation approach for the SEND hash agility based on the Supported Signature Algorithm option described in [sig-agility]”, mostly because there is a reference to an actual draft in that proposal. But the document never comes out and says that explicitly. It should, especially since the Abstract claims to “decide” this. There is no discussion in this section about hash agility concerning backwards compatibility, i.e. the situation where some SEND devices support sig-agility and others do not. At least it should be raised as an issue to be overcome. To be fair, this topic does seem to be addressed in http://tools.ietf.org/html /draft-cheneau-send-sig-agility-01#section-2.1. 3. Section 6. Security Considerations “This issue can be mitigated with the appropriate local policies.” Maybe this is obvious to the author, but I would state what should be configurable in the local policies. Here is related text from the Security Considerations section of [sig-agility], http://tools.ietf.org/html/draft-cheneau-send-sig- agility-01#section-7: “To mitigate this issue, nodes are allowed, on a local policy, to refuse to check certain types of signature (i.e. those which are [known] to be flawed) and will treat the associated messages as unsecured.” The threat analysis seems to rely on the existence of human readable fields in X.509 certificates for the ADD process (section 3.2). Is there an implicit requirement that a human that is managing the SEND device be able to read and validate these fields? Or is this validated in some automated manner?
There are a significant number of typos in the document that detract from its readability. Abstract The first use of the acronym ‘SEND’ should be spelled out: /SEND/SEcure Neighbor Discovery (SEND)/ /Current SEND specification/The current SEND specification/ /for the hash algorithm agility/for hash algorithm agility/ /to provide analysis/to provide an analysis/ Section 1 /Cryptographically Generated Addresses (CGA)/Cryptographically Generated Addresses (CGAs)/ /Authorizaton Delegation Discovery/Authorization Delegation Discovery/ /variaty/variety/ /First hash attacks/The initial hash attacks/ /significantlly/significantly/ /Depending on the way how the Internet protocol uses the hash algorithm, Internet protocol can be affected/Depending on how the SEND protocol relies on the hash algorithm, Internet Protocol (IPv6) operation can be affected/ Section 3 /Up to date, all demonstrated attacks are attacks against a collision-free property./To date, all demonstrated attacks are attacks against the collision- free property./ /underlaying hash function/underlying hash function/ /no matter of the hash algorithm weaknesses/no matter the weaknesses of the hash algorithm/ /fingerprints/or fingerprints/ /on SEND by the cases of use/on SEND by the use cases/ /support the hash agility/support hash agility/ Section 3.2 /Router sends to a host/A router sends to a host/ /Potential problem for the attacker/The potential problem for the attacker/ /allowe/allow/ /does not allowe to provide/does not allow/ /biggest concer are/the biggest concerns are/ /such human-readble data such would prevent attacks/such human-readable data would prevent attacks / Section 3.3 /is described [rfc3971]/is described in [rfc3971]/ /Private key corresponds/The private key corresponds/ /The Digital Signature field the example of the non-repudiation digital singature/The Digital Signature field is an example of a non-repudiation digital signature/ /Possible attacks on such explicit digital signature/A possible attack on the Digital Signature field/ /He underlays one of the messages to be signed/The attacker signs one of the messages/ /but in real-world situation is to achieve it/but in real-world situations it seems difficult to achieve/ Section 3.4 /the integrity protection/integrity protection/ /the collision attacks/collision attacks/ /a non human-readable data/non human-readable data/ Section 4 /Previous section/The previous section/ /SEND context prevents/The SEND context prevents/ /The most effective and secure would be/The most effective and secure solution would be/ Section 6 /offeres/offers/ /by providing solution for the hash agility support/by providing a solution to support hash agility/
draft-ietf-l3vpn-mvpn-considerations
RFC 4364 is cited but the reference is not defined.
draft-ietf-pana-preauth
In section 6, I'm not clear what "authorized PaCs" are in this sentence: It is recommended that the authorized PaCs are limited to well-known IP networks for a given PAA.
RFC 5191 says the following: 10.2.2. Flags There are 16 bits in the Flags field of the PANA message header. This document assigns bit 0 ('R'), 1 ('S'), 2 ('C'), 3 ('A'), 4 ('P'), and 5 ('I') in Section 6.2. The remaining bits MUST only be assigned via a Standards Action [IANA]. So to my understanding this document can not be published as an experimental and get the E bit assigned.