IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2011-01-06. These are not an official record of the meeting.

Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)

Corrections from: Dan

1 Administrivia

  1. Roll Call 1134 EST Amy:
  2. Bash the Agenda
  3. Approval of the Minutes of the past telechat
  4. Review of Action Items from last Telechat

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. OCSP Algorithm Agility (Proposed Standard)
    draft-ietf-pkix-ocspagility-09
    Token: Tim Polk
    Note: Stephen Kent <kent@bbn.com> is the document shepherd
    Discusses/comments (from ballot 3388):
    1. Jari Arkko: Discuss [2011-01-04]:
      "...A responder SHOULD always apply the lowest numbered selection mechanism that is known, supported, and that meets the responder's criteria for cryptographic algorithm strength."
      I am confused by the last sentence and how it uses the words "selection mechanism". Does this sentence talk about algorithms or the above selection methods? But the selection methods do not have an algorithmic strength, nor are they negotiated. Suggested replacement text:
      "A responder SHOULD always apply the lowest numbered selecetion mechanism that results in the selection of a known and supported algorithm that meets the responder's criteria for cryptographic algorithm strength."
    2. Adrian Farrel: Discuss [2011-01-05]:
      I find a small discrepency at the end of Section 4
      "The server SHOULD use one of the preferred signature algorithms for signing OCSP responses to the requesting client."
      This means (I think) that the server MAY use an algarithm not listed by the client as preferred. You need to cover:
      - under what circumstances
      - what expectations of success it will have
      But, in fact, I think the whole of Section 5 is dedicated to the question of how to select a suitable algorithm, and that means that this sentence in Section 4 needs to be replaced with:
      "Section 5 of this document describes how a server selects an algorithm for signing OCSP responses to the requesting client."
    3. Adrian Farrel: Comment [2011-01-05]:
      The RFC Editor will ask you to remove the citation from the Abstract.
      acronyms are used without expansion.
      Section 5.1: Did you think of splitting option 5 into:
      5. select a mandatory algorithm
      6. select a recommended algorithm
      since there is a very marked difference in the likelihood of success.
    4. Alexey Melnikov: Comment [2011-01-04]:
      In Section 4: "The client MUST support each of the specified preferred signature algorithms and the client MUST specify the algorithms in the order of preference."
      I think this is not actually saying what the order is. I suggest adding something like
      "from the most preferred to the least preferred"
      8.3. Denial of Service Attack: "Algorithm agility mechanisms defined in this document introduces a slightly increased attack surface for Denial of Service attacks where the client request is altered to require algorithms that are not supported by the server, alternatively does not match pre-generated responses."
      The last part (after the final comma) is not readable.
      [NEWASN] - is this a Downref?... is [NEWASN] in the Downref registry?
    5. Peter Saint-Andre: Comment [2011-01-05]:
      1. Section 8.1 uses the phrases "considered unacceptably insecure" and "not considered acceptably secure". Are these equivalent?
      2. In Section 8.3, please consider citing RFC 4732 on the concept of denial of service attacks.
    6. Sean Turner: Comment [2011-01-04]:
      I am going to recuse myself from this draft because I was involved in proposing the ASN.1 structure. I don't consider that an insignificant contribution. I am however happy with this draft.

    Telechat:

  2. HTTP State Management Mechanism (Proposed Standard)
    draft-ietf-httpstate-cookie-20
    Token: Peter Saint-Andre
    Note: Jeff Hodges (chair of the HTTPSTATE WG) is the document shepherd.
    Discusses/comments (from ballot 3438):
    1. Jari Arkko: Comment [2011-01-03]:
      I agree with the Discusses from Alexey, Robert, Tim, and for the most part with Sean. I do not agree with the Discuss from Adrian. Obviously the document can make those actions.
    2. Adrian Farrel: Comment [2010-12-13]:
      Section 1: Please don't be so timid.
      Section 10.2: "[Netscape]"
      1. Are you sure this is the best version of the spec? The document is headed: "Preliminary Specification - Use with caution"
      2. RFC Erratum 1491 reads... Can you confirm that you do not need to add a "copy available" statement to this document?
      Erratum 2644 seems to have been submitted after the date of your I-D. I assume that this Erratum will be rejected as soon as your I-D becomes an RFC.
      Section 2.1: "..." Do you really mean "performant" which my dictionary gives only as a noun meaning " a perforemer".
    3. Alexey Melnikov: Discuss [2010-12-20]:
      [Updated as per -20]
      This is a well written document. I am contemplating voting Yes on this document once my issues (see below) are discussed/resolved, not because Cookies are pretty, but because this is the best attempt to describe them properly.
      7) In Section 5.4: "..." Clients can't assume that an arbitrary sequence of octets generated by the server would be a valid UTF-8. This needs to be clarified.
      9) From Lisa Dusseault's Apps Area Review:
      Section 3. "Origin servers can send a Set-Cookie response header with any response.". Do we happen to know if it's more common for user agents to handle, or ignore Set-Cookie response headers on error responses?
    4. Alexey Melnikov: Comment [2010-12-20]:
      5.1.1. Dates: "year = 1*4DIGIT ( non-digit *OCTET )"
      Do people really use 1 digit and 3 digit years?
    5. Tim Polk: Discuss [2011-01-06]:
      This discuss was motivated in part by Richard Barnes' Gen-ART review. Richard noted that:
      "Many of these integrity issues are caused by user agents accepting cookies from outside the context where they would send them, in particular with the Secure and Path attributes. It seems like this document, in specifying the desired/proper behavior of user agents, should require behavior that would mitigate these attacks. In direct parallel to the handling of the Domain attribute:
      "1. Set-Cookies with the Secure flag should only be accepted over secure channels
      "2. Set-Cookies with the Path attribute set should only be accepted if the path value matches the request-uri of the request (That is, update Steps 7 and 8 of S5.3 to match Steps 6 and 9/10)"
      The author responded:
      "I agree that these would be desirable changes to the cookie protocol. However, the http-state working group is not chartered to change the cookie protocol. In particular, the charter reads as follows: "The working group must not introduce any new syntax or new semantics not already in common use." "
      I understand that this document cannot impose new rules or syntax. However, as written this document appears to *prohibit* clients from extending the algorithm to protect themselves: User agents are required to implement algorithms "equivalent to" the algorithms specified in Section 5 to process dates (section 5.1.1), paths (5.1.4), parse a set cookie string (Section 5.2), and the processing the cookie (Section 5.3, which was at the heart of Richard's issues), processing the cookie header (section 5.4), etc. This does not leave an implementer with any wiggle room, forcing them to accept insecure processing rules.
      This document should not prohibit clients from doing additional processing to enhance their own security, especially since the processing rules proposed by Richard apparently would not affect interoperability with a well-behaved server.
      I believe that a better model is the PKIX path validation processing algorithm, where "functionally equivalent" implementations are required but are explicitly permitted to extend the model to enhance security. For example, some implementers have chosen to require that a certificate and CRL be signed by the same cryptographic key to guard against name collisions. This is not required by PKIX but implementations that include this feature are still compliant.
      Is there a good reason why extensions to the user agent's processing cannot be extended as Richard suggested?
    6. Tim Polk: Comment [2010-12-16]:
      I found the following Note at the end of 4.1.1 confusing: "NOTE: Some user agents represent dates using 32-bit UNIX time_t values. Some of these user agents might contain bugs that cause them to process dates after the year 2038 incorrectly."
      After considering this for a while, I concluded that the point is that user agents might convert the dates into UNIX time_t values for storage and processing, and implementation bugs mean that dates after 2038 are not interpreted correctly. If that is correct, then maybe the following would be an appropriate substitution: ...
    7. Robert Sparks: Discuss [2010-12-14]:
      In 4.1.1 (Syntax) - Why is the specification part of this proposed standard allowing implementations to violate the grammar defined by this standard?...
    8. Robert Sparks: Comment [2010-12-14]:
      Please consider moving the SHOULD in the first of the two NOTE:s at the end of 4.1.1 out of the NOTE.
      Consider noting in the discussion of "public suffixes" that the problems this mechanism attempts to avoid are still present in deeper heirarchies (A server at math.example.edu will be able to set cookies for example.edu, potentially affecting the behavior of infosec.example.edu)
    9. Sean Turner: Discuss [2010-12-16]:
      [These are my preliminary discusses. I might find more later.]
      #1) I'd like to see a new security consideration section that addresses persistent cookies. I think we need to mention how expiry date can be abused. Is there some kind of recommendation we can give on their lifetimes? Are cookies good for 2, 5, 20 years okay?
      #2) I'd like to see a new privacy|security consideration that says what's being touted as "private browsing" doesn't protect cookies it only stops the history from being updated.
      #3) Section 7.1: I understand it's hard to have one policy for third-party cookies. But, couldn't we say that assuming sites aren't behaving badly or somehow otherwise sharing tracking data that users that wish to not be tracked by third-parties ensure that third-party cookies be blocked?
      #4) Section 7.2: It's not a protocol thing, but should we really make the following two SHOULDs:
      User agents should provide users with a mechanism for managing the cookies stored in the cookie store.
      User agents should provide users with a mechanism for disabling cookies.
      #5) Section 8.3/8.5: Should point out that the format for signature/encryption is server specific.
      #6) Section 8.3, last paragraph:
      a) The last paragraph, I believe, discusses "sidejacking" and "cookie monster" attacks (or is that the 1st paragraph in 8.5?). Is it worth explicitly mentioning the name of these attacks?
      b) To that end, can we add something like (I'm not wed to the words) the following to the end of the paragraph in 8.3:...
      #7) Sec 8: Where would we say something about how when multiple users use the same machine, they're not protected from one another?
      #8) Sec 8: Shouldn't we have a section on cross-site scripting attacks (i.e., scripts that make browser send cookies to malicious servers that should not receive them) and how http-only helps? I.e., servers should set httpOnly to stop these?
      #9) Sec 4.2/8 ?: Where are cookie poising attack discussed (i.e., client returns a different cookie than the one set by the server)?
    10. Sean Turner: Comment [2010-12-16]:
      #1) Section 4: It's odd that following is in Section 4, which is titled Server Requirements: "User agents, however, MUST implement the requirements in Section 5 to ensure interoperability with servers making use of the full semantics."
      Shouldn't it be in Section 5?
      #2) In Section 5.2, add "(see Section 7.1)" to the end of: "For example, the user agent might wish to block responses to "third-party" requests from setting cookies."
      #3) In Section 5.4, add "(see Section 7.1)" to the end of: "For example, the user agent might wish to block sending cookies during "third-party" requests."

    Telechat:

  3. PIM Group-to-RP Mapping (Proposed Standard)
    draft-ietf-pim-group-rp-mapping-08
    Token: Adrian Farrel
    Note: Mike McBride is the document shepherd (mmcbride@cisco.com).
    Discusses/comments (from ballot 3536):
    1. Adrian Farrel: Comment [2010-12-31]:
      Routing Area Directorate review by Dimitri Papadimitriou raises a few very minor editorial points that should be looked at together with any other comments and issues raised during IESG review.
    2. Tim Polk: Discuss [2011-01-05]:
      This is a pretty straightforward discuss, and should be easy to clear. As noted in Vincent Roca's security directorate review, the document would benefit from some expansion of the security considerations. In particular, some pointers to mechanisms for learning group-to-rp mappings that satisfy the constraint are considered secure would be helpful. Please use Vincent's review as an input to your revisions.
    3. Dan Romascanu: Discuss [2011-01-04]:
      The issue of the relation between this document and RFC 5060 was raised by Adrian with the MIB Doctors. At the end of the discussion which prompted to various methods of altering the behavior of the routers that already support the MIB module the resolution communicated by Adrian was: 'we have decided that we do NOT want to update the semantics of the existing objects'.
      I am still to be convinced that this is the case.
      7. Interpretation of MIB Objects: "..."
      First, in RFC 5060 the 'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence' objects are in two different tables - pimGroupMappingTable and pimStaticRPTable. Each of the table has a different 'precedence' object and a different behavior.
      Does pimStaticRPTable has any function with the new RP mapping algorithm? In RFC 5060 it is used to define static entries that may precede and override those defined by the algorithm in 5060. Does this apply also to the algorithm defined here?
      What does exactly mean 'the usage of these fields will decline'? All the MIB module defined in RFC 5060 is supported ('we do not want to update the semantics') - so what happens with the pimGroupMappingTable? Section 8 describes how objects in this table will continue to be used to indicate Group-to-RP mapping. Whay I am missing is what happenss if a manager creates a new entry as per RFC 5060? Should the router just ignore it? We cannot assume all managers are 'well-bahaved' and we need to prevent I think mis-configuration.
      If the writeable part of the of this table is not disabled, this would be a serious security problem, as it would interfere with the works of the new algorithm.
      A proper solution should include an update of RFC 5060, including changes in MODULE-COMPLIANCE and possibly a new read-only table that would help the operators read the entries created as result of the application of the new mechanism. I understand that the authors and WG do not plan to do this in the near future, but they need to define a clear and acceptable behavior of the agents runing RFC 5060. Dully obsoleting RFC 5060 (and the usage of the MIB module defined there) would be another solution at this point, but this is not what the WG wants, as I understand.
    4. Dan Romascanu: Comment [2011-01-04]:
      1. Section 5: "A network management station can determine the RP for a specific group in a specific router by running this algorithm on the Group-to-RP mapping table fetched using SNMP MIB objects."
      MIB objects are meant to work not only with SNMP. Please change 'SNMP MIB objects' to 'SMI MIB objects' or just 'MIB objects'.
      2. Need to expand MIB and SNMP at first occurence.
    5. Peter Saint-Andre: Discuss [2011-01-05]:
      This is a fine document. However, the algorithm does not specify rules for determining which hash value or IP address is "highest", which might inhibit interoperability. Please specify such rules (e.g., convert to "network byte order" octet string representation and then apply i;octet collation from RFC 4790), or refer to specifications that define such rules.

    Telechat:

  4. The Trickle Algorithm (Proposed Standard)
    draft-ietf-roll-trickle-07
    Token: Adrian Farrel
    Note: JP Vasseur (jpv@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3545):
    1. Stewart Bryant: Discuss [2010-12-15]:
      "All that matters is that some nodes communicate with one another at some nonzero rate."
      This is not right. If every node received, nothing would get communicated. In addition I tend to think of communication as requiring some degree transmission. I think that you mean transmits at some nonzero rate.
      Considering that later text says that Trickle breaks if there is a parameter mismatch, I am concerned that this text is not strict enough:
      "It is RECOMMENDED that a protocol which uses Trickle includes mechanisms to inform nodes of configuration parameters at runtime. However, it is not always possible to do so."
      I am also concerned with the get out clause that allows the degradation of a MUST to a RECOMMENDATION. Surely for the cost of a few bytes the parameters can at least be announced so that other nodes can get some hint that the mismatch is occurring.
    2. Ralph Droms: Comment [2010-12-14]:
      Nit: 3rd para of section 3, s/their/its/
      Question: is the typical value of k in the range 1-5 independent of the density of the network nodes, where I'm thinking of "density" as the number of nodes that hear a given message?
    3. Lars Eggert: Discuss [2010-12-16]:
      I'm sorry for deferring this document to the next telechat. I want the TSV directorate to review it and I didn't realize this in time to get the review assigned.
      I'm also balloting DISCUSS. That is, because looking at the current ROLL charter, I have a hard time understanding how this document is in scope of the WG. This document does not fall under any of the work items on the charter; and it's not even what I'd consider a "routing" protocol.
    4. Adrian Farrel: Comment [2010-12-24]:
      Rtg Dir review from Alia Atlas says: "I have reviewed draft-ietf-roll-trickle-06. It is one of the best drafts that I have read and I do not have any substantial or even editorial comments on it. I found the protocol as described to be clear, simple and pretty elegant."
    5. Robert Sparks: Comment [2010-12-14]:
      In section 6.5 - The comment about "having the parameter describe k-1 instead of k being confusing" is confusing. I had to think for some time to convince myself that I understood what you were trying to say. I encourage you to further explain, or rewrite the comment.
      Why are you allowing different uses of trickle to give different meanings to k=0? It would seem to facilitate interoperability (and simplify implementation) if you just defined k=0 to mean turning off suppression in all cases. Individual uses of trickle can forbid setting k=0 if they don't want to allow turning off suppression.

    Telechat:

  5. Pseudowire (PW) OAM Message Mapping (Proposed Standard)
    draft-ietf-pwe3-oam-msg-map-14
    Token: Stewart Bryant
    Note: Andrew Malis, andrew.g.malis@verizon.com is the document shepherd.
    IPR: Cisco's Statement about IPR Claimed in draft-ietf-pwe3-oam-msg-map-05.txt
    Discusses/comments (from ballot 3588):
    1. Adrian Farrel: Discuss [2011-01-03]:
      There are a couple of nits reported by idnits... I think the license statement should be fixed and posted (to reflect the authors' intent) before the document is approved.
      I see IPR disclosed at http://datatracker.ietf.org/ipr/863/... I don't see this declared in the proto write-up. More important, it is not present in the IETF last call announcement in datatracker.
      What is the situation wrt multi-segment PWs? I can understand that this document was developed before the WG turned to MS-PWs, but we now have RFC 5254 and RFC 5659.
      I would prefer that this document fully addressed MS-PWs...
      However, an option is to declare MS-PW out of scope, and provide a forward reference to work being done on OAM message mapping for MS-PWs in the PWE3 WG.
      Section 4.2: "If LSP-Ping [RFC4379] is run over a PW as described in [RFC4377], it will be referred to as "VCCV-Ping"."
      I believe s/RFC4377/RFC5085/
      Section 5: You should add a note to explain why the CE ends of the ACs are not considered as possible defect locations. They are part of the emulated service, so a naif reader might expect to see them listed. Possibly you will want to explicitly include it in case (a).
      Additionally, your text does not match the figure: c. Defect on a PE1 PSN interface. But (c) also appears on the PE2-PSN interface in the figure.
      Furthermore, (e) and (f) appear tbe reversed in the figure compared to the text.
      Section 13: RFC 5085 and RFC 4447 should be presented as references.
      I will let Security experts comment further, but: It seems to me that facilitating end-to-end coordination of PW status and fualt reporting provides an extra tool for attackers. I would expect this to be pointed out and held up as a reason for ensuring the use of the security mechanisms.
      I think that there are security coordination issues. Perhaps these are already mentioned in the references. Consider carrying NS OAM from CE to CE across the PSN in Single Emulated OAM Loop mode or Coupled OAM Loops mode. The security relationship perceived by the CEs would presumably be between each other, but doesn't the PE need to participate?
    2. Adrian Farrel: Comment [2011-01-03]:
      Section 3: s/whereby/where/
      The Introduction uses a number of acronyms without prior expansion. On the other hand, having defined acronyms in Section 4.1, you don't gave to expand them in subsequent sections.
      Section 4.1: Several acronyms are not used in the rest of the document.
      s/label Switched Path/Label Switched Path/
      s/Operations, Administration and Maintenance/Operations, Administration, and Maintenance/
      Section 4.2: "The words "defect" and "fault" are used interchangeably to mean any condition that obstructs forwarding of user traffic between the CE endpoints of the PW service."
      I'm fine with this, but I think "obstructs" is ambiguous. Do you mean "impose a complete blockage", or do you mean to include degradation in some form? Perhaps you could add a clarification.
      Section 4.2: "If BFD is run over a PW as described in [RFC5885], it will be referred to as "VCCV-BFD".
      Add a reference to [RFC5880]
      Section 4.2: "A "transmit defect" is any defect that impacts traffic that is meant to be sent or relayed by the observing PE. A "receive defect" is any defect that impacts traffic that is meant to be received by the observing PE."
      While "meant to be" is appropriate for the reception of data, I don't think it necessarily applies to transmission. Consider that the defect may be somewhat downstream of (and not yet notfied to) the upstream PE such that the traffic that is impaced is that which *has* been sent or relayed by the observing PE.
      Additionally, the term "observing PE" has not been defined and may clarify or complicate the meaning of the text.
      I had a few problems with Section 8.1. I think my issue is with the use of the control plane as an OAM exchange mechanism (this also shows up in Appendix B). I believe the section could benefit from some polishing.
      "For MPLS and MPLS/IP PSNs, a PE that establishes a PW using Label Distribution Protocol [RFC3036] MUST use the LDP status TLV as the mechanism for AC and PW status and defect notification, as explained in [RFC4447]."
      I don't think that this "MUST" is good or consitent with:
      - the text in Section 7 that is relaxed in saying "LDP or in the ACH"
      - the work in MPLS-TP
      It sounds like 3036 (or rather 5036) is a normative reference.
      While conveying PW status in LDP per 4447 is fine, it is not OAM with the utility of rapid propagation of fault notifications. LDP, reliant as it is on TCP, is not suitable to that purpose.
      Wouldn't it be better to require the use of the ACH for OAM fault notification messages, and (if you must :-) mandate the use of LDP for status information propagation when LDP is present (but not as a replacement for real OAM).
      Additionally...: "Additionally, a PE MAY use VCCV-BFD Connectivity Verification (CV) for fault detection only (CV types 0x04 and 0x10 [RFC5885]) but SHOULD notify the remote PE using the LDP Status TLV.
      The "SHOULD" here seems to be in conflict with te previous "MUST"
      And it goes on...: "A PE that establishes a PW using means other than LDP, e.g., by static configuration or by use of BGP, MAY use VCCV-BFD CV (CV types 0x08 and 0x20 [RFC5885]) for AC and PW status and defect notification. Note that these CV types SHOULD NOT be used when the PW is established with the LDP control plane."
      If you supply only a "MAY" you should probably describe how else the fault notification might work.
      As to the "SHOULD NOT" in the last sentence. Well, see my previous comments. And what possible harm could it do?
      Section 6: "Generally, a PE cannot detect transmit defects directly and will therefore need to be notified of AC transmit or PW transmit defects by other devices."
      I think you mean s/directly/direct/
      Section 8.1.1: "[RFC4447] specifies that the "Pseudowire forwarding" code point is used to clear all faults. It also specifies that the "Pseudowire Not Forwarding" code is used to convey any defect that cannot be represented by the other code points."
      The language seems rather week. The use of the code point does not clear the faults. It is used to report (notify) that the faults have been cleared. Likewise, defects are not conveyed by the use of a control points, but existence of the defect can be reported (or conveyed, if you like).
    3. Russ Housley: Comment [2011-01-05]:
      Appendix B.3: s/Los/Loss/

    Telechat:

  6. RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions (Proposed Standard)
    draft-ietf-avt-rtcp-port-for-ssm-04
    Token: Robert Sparks
    Note: The document shepherd for this document is Keith Drage (keith.drage@alcatel-lucent.com).
    Discusses/comments (from ballot 3614):
    1. Adrian Farrel: Comment [2011-01-05]:
      As idnits points out, you can strip the RFC 2119 boilerplate and reference. I'm sure the RFC Editor can handle this.
    2. David Harrington: Comment [2011-01-05]:
      1) in section 1, "the +1 rule" is mentioned without definition or reference.
    3. Sean Turner: Comment [2011-01-05]:
      Section 5 has: "This can, for example, be achieved on an end-to-end basis using S/MIME [RFC5652] when SDP is used in a signaling packet using MIME types (application/sdp)."
      Technically, S/MIME messages aren't in [RFC5652] they're in [RFC5751]. RFC 5652 is CMS, which is profiled for email in RFC 5751. I've noted that when used with SDP S/MIME has been referred to as follows: RFC 4566 uses text that is similar, but omits a reference for S/MIME; RFC 4657 uses RFC 3851 (previous version of RFC 5751); RFC 4658 uses RFC 3851; RFC 3605 uses RFC 3852 (prior version of RFC 5652); RFC 3261 refers to both 2633 (S/MIME) and 2630 (CMS). Maybe the right approach is to point to both CMS and S/MIME.

    Telechat:

  7. Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) (Proposed Standard)
    draft-ietf-avt-rtp-cnames-03
    Token: Robert Sparks
    Note: Keith Drage (keith.drage@alcatel-lucent.com) is the document shepherd.
    Discusses/comments (from ballot 3635):
    1. Stewart Bryant: Discuss [2011-01-05]:
      I think it would be helpful to the reader to briefly note that whilst the methods described in this document are good enough for most practical purposes they are not technically perfect. Whilst I can see no particular problem in the application described here, these methods may well be re-purposed as convenient general purpose UID mechanisms.
      Specifically when the method described in (5) does not use an EUI-64 there is a non-zero probability of collision, and the method in (4) that uses the MAC address is only as good as the quality procedures and ethics of the hardware manufacturer.
    2. Adrian Farrel: Comment [2011-01-05]:
      Support Stewart's Discuss since we have observed "clone" equipment with identical MAC addresses in the past. Also, I believe that some h/w exists with configurable MAC addresses.
      Abstract" s/these/those/
    3. Russ Housley: Discuss [2011-01-05]:
      The Gen-ART Review by Suresh Krishnan on 2-Jan-2011 raised an issue that needs to be resolved before publication. Section 5, Step 2, describes the use of an EUI-64 identifier and how to generate one if it does not exist. The procedure for the creation of the EUI-64 from a 48-bit MAC address is incorrect: ...
      While I recognize that no interoperability issues will result from this difference, there may be issues with testing if this is not resolved. Therfore, I suggest using the term "modified EUI-64" instead of EUI-64 or changing the reference from RFC 4291 to the IEEE document.
    4. Alexey Melnikov: Comment [2010-12-25]:
      5. Procedure to Generate a Unique Identifier: "2. Obtain an EUI-64 identifier from the system running this..."
      I think this needs an Informative reference to a document which explains what is EUI-64.
    5. Tim Polk: Comment [2011-01-06]:
      I support Sean's discuss: hard-coding SHA-1 is unnecessary and counterproductive. There is no reason that all clients need to use the same secure hash algorithm, IMHO. (For example, two clients using SHA-256 and SHA-512 are no more likely to generate a collision than two clients using SHA-256.) I suggest "compute a message digest using a secure hash function (e.g., SHA-256)" would provide the right level of detail for section 5.
      A short paragraph should also be added to the security considerations section with appropriate references. (I think Sean's discuss has the right list.)
      I would also note that the algorithm in section 5 does not *guarantee* uniqueness. I think your odds of a collision are one in 2**48 (but check with a real mathematician!). I note this since the Requirements section states "It is believed that obtaining uniqueness is an important property ..."
      Section 4.2, third bullet: "After performing the procedure, the significant 96 bits are used ..."
      Please specify "most significant" or "least significant"; the latter would be consistent with the preceding bullet.
    6. Dan Romascanu: Comment [2011-01-04]:
      1. "After obtaining a identifier by doing (a) or (b), the least significant 48 bits are converted to the standard colon-separated hexadecimal format, e.g., "00:23:32:af:9b:aa", resulting in a 17-octet printable string representation.
      It would be good to provide a reference for this 'standard ... format'. RFC 5342 uses a different notation, so arguably there is more than one format used in RFCs.
      2. Also from 5342 - here is a reference for EUI-64 which could be added (also answers the COMMENT from Alexey)
    7. Peter Saint-Andre: Discuss [2011-01-05]:
      This is a fine document with the laudable goal of improving interoperability, but in one respect I think it is both overly specific and unclear about the requirements it is working to meet.
      Section 4.1 states: "An implementation that wishes to discourage this type of third-party monitoring can generate a unique RTCP CNAME for each RTP session...."
      However, a unique identifier does not necessarily discourage third-party monitoring, e.g., incrementing from UniqueID-1 UniqueID-2 might ensure uniqueness but not privacy. I suggest that we provide a reference to RFC 4086 here and recommend that those who desire privacy need to generate identifiers that are not only unique but also random.
      This issue is connected to Section 4.2, which mandates one algorithm for long-term identifiers and a different algorithm for short-term identifiers (with seemingly different security properties, since long-term identifiers are 36 octets in length whereas short-term identifiers are only 17 octets in length). Would an implementation that generates a UUID for short-term identifiers violate the spec? If so, why? As long as the short-term identifier is unique, the implementation has met the relevant requirement. (Perhaps there is a further requirement or desire to make the identifier random, as mentioned above, but that is a separate issue.)
    8. Sean Turner: Discuss [2011-01-06]:
      #2 was revised based on some side discussions.
      #1) Section 5: On the use of SHA-1: What properties are you looking from the output? If you require no collisions then SHA-1 is probably a bad idea (see https://datatracker.ietf.org/doc/draft-turner-sha0-sha1-seccon/). It would be much better to use SHA-256 and truncate it. And, then point to https://datatracker.ietf.org/doc/draft-eastlake-sha2b/. Yes it is a dependency but it's in AD Evaluation.
      #2) Section 5: Algorithm agility would be really nice here. Locking yourself in to one hash algorithm isn't a good idea. If the client is the only entity that is ever going to generate this hash true algorithm agility might not be needed, but you could get it by picking a length you want and then saying that one of the algorithms x, y, or z MUST be used. That way the implementer can pick on that they're doing in their cipher suite.
    9. Sean Turner: Comment [2011-01-05]:
      Section 4: Need to add "NOT RECOMMENDED" to Section 2. It's used as a key word and the 2119 errata allow it, but you need to include it as shown in the errata (http://www.rfc-editor.org/errata_search.php?rfc=2119).
      Any chance for an example per-session unique identifier?

    Telechat:

  8. Domain Name System (DNS) IANA Considerations (BCP)
    draft-ietf-dnsext-5395bis-02
    Token: Ralph Droms
    Note: Olafur Gudmundsson (ogud@ogud.com) is the document shepherd.
    Discusses/comments (from ballot 3657):
    1. Jari Arkko: Comment [2011-01-05]:
      This is a good document and should go forward. A few comments regarding the comments and discusses from other ADs:
      - I do not believe this document is the place to obsolete z-bit. This is an IANA considerations doc.
      - Regarding URLs and the template, I note that Specification Required is not explictly called for. Maybe it should be, and that would solve the URL problem (as the semantics of Specification Required have been defined elsewhere and reference stability is one criteria).
    2. Stewart Bryant: Comment [2011-01-05]:
      I agree with David Harrington's discuss.
    3. Adrian Farrel: Discuss [2011-01-05]:
      A small piece of IANA pedantry... Section 1.1: "IETF Standards Action", "IETF Review", "Specification Required", and "Private Use" are as defined in [RFC5226].
      5226 uses the term "Standards Action" not "IETF Standards Action". Could you fix this up throughout the document?
    4. Adrian Farrel: Comment [2011-01-05]:
      A nit: The Abstract reads... "Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes."
      Pedantically, this Abstract says nothing about *this* document. Could you make it read... "This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of..."
    5. David Harrington: Discuss [2011-01-04]:
      in section 2.1, should the document state that the ancient usage is hereby obsoleted and the z-bit MUST NOT be used for this ancient purpose in implmenetations compliant to this spec?
      in Annex 1, field E, should the document specify that it MUST be a long-lived, stable URL if a URL is used? What happens if the URL disappears? Should a document be required for escrow purposes?
    6. David Harrington: Comment [2011-01-04]:
      in section 1, s/is the change is the public review mailing list /is the change to the public review mailing list/
      in section 2.3, might it be good to recommend NOT overloading the values, ala the 16 bit, since we have 60000+ bits available?
      section 3.1.4 uses MX RR without prior definition, or reference to the definition.
      in Annex 1, field E, why does this end in a colon?
      why is field J on a totally separate page?
    7. Alexey Melnikov: Comment [2010-12-19]:
      I have a couple of comments. Taking into consideration that this is a bis document, I am making them Comment-level:
      1) 3.1.1. DNS RRTYPE Allocation Policy: "No less than three weeks and no more than six weeks after a completed template has been formally posted to dnsext@ietf.org, the selected Expert shall post a message, explicitly accepting or rejecting the application, to IANA, dnsext@ietf.org, and the email address provided by the applicant. If the Expert does not post such a message, the application shall be considered rejected but may be re-submitted to IANA."
      The last sentence: is "rejection by silence" a good idea? Has this worked well in the past?
      2) Excuse my ignorance, but what is the relationship between 2 mailing lists:
      3.1.1. DNS RRTYPE Allocation Policy: "No less than three weeks and no more than six weeks after a completed template has been formally posted to dnsext@ietf.org, the selected Expert shall post a message, explicitly accepting or rejecting the application, to IANA, dnsext@ietf.org, and the email address provided by the applicant."
      5. IANA Considerations: This document consists entirely of DNS IANA Considerations.
      "IANA shall establish a process for accepting Annex A templates, selecting an Expert from those appointed to review such template form applications, and archive and make available all approved RRTYPE allocation templates. It is the duty of the applicant to post the formal application template to the dns-rrtype-applications@ietf.org mailing list. See Section 3.1 and Annex A for more details."
      Is a request always posted to dns-rrtype-applications@ietf.org and then to dnsext@ietf.org? If the answer is yes, why have 2 mailing lists?

    Telechat:

  9. The use of AES-192 and AES-256 in Secure RTP (Proposed Standard)
    draft-ietf-avt-srtp-big-aes-05
    Token: Robert Sparks
    Note: Keith Drage (keith.drage@alcatel-lucent.com) is the document shepherd.
    Discusses/comments (from ballot 3659):
    1. Russ Housley: Discuss [2011-01-02]:
      The Gen-ART Review by Richard Barnes on 10-Dec-2010 raises a question that deserves a response. I have not see a response to the question.
    2. Russ Housley: Comment [2011-01-02]:
      Please consider the nit and editorial comments from the Gen-ART Review by Richard Barnes on 10-Dec-2010:
    3. Alexey Melnikov: Comment [2010-12-24]:
      3.1. Usage Requirements: "When AES_192_CM is used for encryption, AES_192_CM SHOULD be used as"
      I think the 2nd AES_192_CM should be AES_192_CM_PRF
      "the key derivation function, and AES_128_CM MUST NOT be used as the"
      s/AES_128_CM/AES_128_CM_PRF ?
      "When AES_256_CM is used for encryption, AES_256_CM SHOULD be used as the key derivation function. Both AES_128_CM and AES_192_CM MUST NOT be used as the key derivation function."
      Same comments as above.
    4. Tim Polk: Comment [2011-01-04]:
      Please note Hilarie Orman's secdir review.
      (1) In particular, she notes: "The block counter "b_c" is two octets, but the "default key lifetime" is 2^31. Is this perhaps the "maximum" key lifetime? Should implementors introduce an internal counter to keep track of the history of key usage (across sessions?)? Perhaps earlier documents explain this?"
      Should implementers use the rollover counter (ROC) from RFC 3711 in combination with b_c, or is there another mechanism that the authors had in mind?
      (2) You might consider moving the rationale to the front of the section as an alternative to Hilarie's suggestions on section 3.1,
    5. Sean Turner: Discuss [2011-01-05]:
      I don't think SHA-1 is part of any Suite B specifications. Because of this, it's unclear to me that you should hint that by implementing this RFC an implementation would be considered Suite B compliant.
    6. Sean Turner: Comment [2011-01-05]:
      #1) Support Russ' and Tim's discusses.
      #2) Section 3: "In this note, the AES-192 counter mode PRF and AES-256 counter mode PRF are and are denoted as AES_192_CM_PRF and AES_256_CM_PRF respectively."
      extra words "are and"?
      #3) Section 3.1 (similar to Russ's 2nd comment): Should the rationale include a MUST?

    Telechat:

2.1.2 Returning Items

  1. MPLS Upstream Label Assignment for LDP (Proposed Standard)
    draft-ietf-mpls-ldp-upstream-09
    Token: Adrian Farrel
    Note: Loa Andersson (loa@pi.nu) is the Document Shepherd.
    IPR: Juniper's Statement of IPR related to draft-ietf-mpls-ldp-upstream-03
    IPR: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mpls-ldp-upstream-09 and draft-ietf-mpls-ldp-p2mp-11
    Discusses/comments (from ballot 3375):
    1. Jari Arkko: Discuss [2010-12-02]:
      Section 5 should explain what the semantics of the second field of the Sub-TLVs are. Presumably that has been defined in some earlier RFC that defined the syntax for Sub-TLVs. A reference would suffice.
      Reference to Section 4.2 for some behaviour needs to be changed as there is no Section 4.2.
    2. Jari Arkko: Comment [2010-12-02]:
      A few comments from Ari Keränen:...
    3. Stewart Bryant: Comment [2010-12-02]:
      (blank)
    4. Adrian Farrel: Comment [2010-12-02]:
      Gen Art review comments from Avshalom Houri...
    5. David Harrington: Comment [2010-11-30]:
      SECTION 3: s/MUST be carried only LDP initialization messages/MUST be carried only in LDP initialization messages/
    6. Russ Housley: Comment [2010-11-28]:
      The Gen-ART Review by Avshalom Houri on 13-Oct-2010 includes some editorial suggestions. Please consider them.
    7. Sean Turner: Comment [2010-11-30]:
      Section 4: Shouldn't the two "optional"s be "OPTIONAL"? They're indicating support requirements.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. Cloud Data Management Interface (CDMI) Media Types (Proposed Standard)
    draft-cdmi-mediatypes-06
    Token: Peter Saint-Andre
    Discusses/comments (from ballot 3598):
    1. Adrian Farrel: Comment [2011-01-05]:
      Support Alexey's Discuss wrt the reference to 4627 and the potential positioning of this document as Informational in which case I don't think the minimal usage of 2119 language would suffer from being changed to lower case, since it seems to be referenced from another specification.
    2. Alexey Melnikov: Discuss [2010-12-21]:
      [Updated as per -06]
      DISCUSS DISCUSS (something that I want to discuss with IESG, no action from the author required):
      RFC 4627 is a Normative reference, so this is a DOWNREF. If the document is changed to Informational, the issue will go away.
    3. Alexey Melnikov: Comment [2010-12-21]:
      (blank)
    4. Sean Turner: Discuss [2011-01-05]:
      #1) Sec 3.1: "The implementations are free to store the data in any form they choose, but the application/cdmi-object SHOULD be represented in the CDMI interface as defined in section 8 of the CDMI specification."
      Seems like there's a normative reference missing to the CDMI spec.
      #2) Sec 3.2: "The implementations are free to represent the container in any form they choose, but the application/cdmi-container SHOULD be represented in the CDMI interface as defined in section 9 of the CDMI specification."
      Seems like there's a normative reference missing to the CDMI spec.
      #3) Sec 4 says: "We do not expect the CDMI to operate over other protocols, nor to use a transport protocol, such as TCP (RFC 793), directly."
      Sec 6.1 says: "CDMI does not contain any specific mechanisms, and relies on transport mechanisms such as TLS (see https [RFC2818]) for confidentiality and integrity of the messages across the network."
      Is Sec 4 wrong? 2818 doesn't mandate TCP, but it sure strong hints at it.
    5. Sean Turner: Comment [2011-01-05]:
      From Sec 3.2: ... includes standardized and optional metadata.
      There can be standardized optional metadata - no? Is this "required and optional meadata"?

    Telechat:

  2. Moving mailserver: URI scheme to historic (Proposed Standard)
    draft-melnikov-mailserver-uri-to-historic-00
    Token: Peter Saint-Andre
    Discusses/comments (from ballot 3639):
    1. Sean Turner: Comment [2011-01-05]:
      Should "Updates: 1738 (once approved)" appear on the 1st page?

    Telechat:

  3. Authentication-Results Registration For Vouch By Reference Results (Proposed Standard)
    draft-kucherawy-authres-vbr-02
    Token: Alexey Melnikov
    Note: Barry Leiba <barryleiba@computer.org> is the document shepherd.
    Discusses/comments (from ballot 3658):
    1. (none)

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Operations, Administration and Maintenance Framework for MPLS- based Transport Networks (Informational)
    draft-ietf-mpls-tp-oam-framework-10
    Token: Adrian Farrel
    Note: Loa Andersson (loa@pi.nu) is the Document Shepherd.
    IPR: Alcatel Lucent's Statement about IPR related to draft-ietf-mpls-tp-oam-framework-07
    Discusses/comments (from ballot 3411):
    1. Stewart Bryant: Discuss [2011-01-05]:
      I am concerned about this text: "Protection Switching: default transmission period is 3.33ms (i.e. transmission rate of 300 packets/second)."
      Firstly the the requirement in RFC5654 only specifies the total time to detect and to act as 50ms and how the system partitions this time should be a local matter.
      Secondly there are some applications of MPLS-TP that may not need this high peed detection, and it is unreasonable to burden them with the need to implement this high speed detection mechanism.
    2. Adrian Farrel: Comment [2010-12-31]:
      Three Directorate reviews have been addressed, but a few non-blocking comments remain that should be addressed to improve the document before it is published as an RFC:
      SecDir - vincent.roca@inrialpes.fr ...
      GenArt - david.black@emc.com ...
      RtgDir - thomas.morin@orange-ftgroup.com ...
    3. Russ Housley: Comment [2011-01-02]:
      The Gen-ART Review by David Black lead to some document updates. However, one comment was not addressed. Please consider updates to the security considerations section. David said:
      "[D] The security considerations section should include specific mention of injection of LKI request OAM packets as a vector for a denial-of-service attack (this is an obvious way for a man-in-the-middle to quickly cause serious havoc). That would be a good specific example to add to the end of the current security considerations paragraph that requires the network to be physically secure against man-in-the-middle attacks."
      While the security considerations section does cover the countermeasures necessary to prevent this attack, it seems like a good idea to document something that can go badly wrong when implementers do not pay attention.

    Telechat:

  2. Sieve Email Filtering: Use of Presence Information with Auto Responder functionality (Informational)
    draft-ietf-sieve-autoreply-03
    Token: Peter Saint-Andre
    Note: The Document Shepherd is Cyrus Daboo.
    Discusses/comments (from ballot 3525):
    1. Stewart Bryant: Comment [2011-01-05]:
      This is somewhat unusual language to find in a RFC to be:
      Consider whether it's truly important to tell people that you'll read their mail in an hour or so, or whether that can just be taken as how email works. There are times when this makes sense, but let's not use it to exacerbate information overload.
    2. Adrian Farrel: Comment [2011-01-05]:
      Your homily to users in Section 1 is a good message, but I think it is in the wrong document or targeted at the wrong audience. *This* document would, I think, mainly apply to application developers since it is an unusual user who writes their own Seive scripts. So the warning is better rephrased to advise application developers to be careful to not provide too many knobs and whistles, or to make sure that their implementations warn users to exercise appropriate caution.
      I would also note in this context that presence information might be a good tool to reduce the amount of autoresponses generated thus mitigating the sad effect of auto-responder functionality.
      Section 4: "Despite the "intelligence", too, errors in scripts can result in private information getting to senders inappropriately."
      Is "too," superfluous? I find it hard to parse.
    3. Robert Sparks: Comment [2011-01-05]:
      Example 2 in section 3 does what the last paragraph in section 1 says is a bad idea. Please consider reconciling these two parts of the document.

    Telechat:

  3. LoST Service List Boundary Extension (Experimental)
    draft-ietf-ecrit-lost-servicelistboundary-05
    Token: Robert Sparks
    Note: Richard Barnes (rbarnes@bbn.com) is the document shepherd.
    Discusses/comments (from ballot 3548):
    1. Tim Polk: Comment [2011-01-06]:
      This document *defines* a Service List Boundary extension, not *proposes* a Service List Boundary. Perhaps the -00 draft was a proposal, but this one is a technical specification.
      I suggest a minor edit in the Abstract to clarify the document scope.
    2. Sean Turner: Discuss [2011-01-05]:
      Section 3.2, 2nd to last paragraph: Add a normative reference to BCP 106/RFC 4086 for randomness requirements (should have been in RFC 5222).
    3. Sean Turner: Comment [2011-01-05]:
      Sec 3.3: r/is optional and/is OPTIONAL and

    Telechat:

  4. IP Flow Anonymisation Support (Experimental)
    draft-ietf-ipfix-anon-05
    Token: Dan Romascanu
    Note: Nevil Brownlee is the Document Shepherd
    Discusses/comments (from ballot 3589):
    1. Stewart Bryant: Discuss [2010-12-13]:
      In the security section you say: "When releasing anonymised data, publishers need to ensure that data that could be used in deanonymisation is not leaked through the export protocol; guidelines for addressing this risk are provided in Section 7.2."
      However it's not just protocol action that needs to be secured, the anonymising system (i.e. h/w, s/w, operational procedures) itself needs to be secure and is a system that will be the prime focus of any attack to recover the base data.
    2. Stewart Bryant: Comment [2010-12-13]:
      "Binning can be seen as a special case of precision degradation; the operation is identical, except for in precision degradation the counter ranges are uniform, and in binning they need not be. For example, a common counter binning scheme for packet counters could be to bin values 1-2 together, and 3-infinity together, thereby separating potentially completely-opened TCP connections from unopened ones.
      I am not a TCP specialist, so I do not understand the leap from the simple text "to bin values 1-2 together, and 3-infinity together" to the TCP connection example, however I suspect that grouping and the protocol state are in the wrong order. Either way, a few more words of a different example would add clarity.
    3. Adrian Farrel: Comment [2011-01-03]:
      Thanks for bringing this work forward as Experimental. While it is not a requirement, I think it is helpful to the community if Experimental documents give some indication of the scope of the experiment. Where will these protocol extensions be used? How will they be kept separate from the wider IPFIX deployment? How will the success or failure of the experiment be judged? What is the plan, assuming success? (The latter is usually: return to update this document based on experience, and move it to the standards track.) Note that some of the answers were presented in the proto writeup.
      I see questions from IANA in the data tracker that appear to have been answered by email during IETF last call. It would be good to get these answers transfered into the document or added as an RFC Editor Note. Additionally, the registry referenced is split into two ranges, but there is no advice to IANA about which range should be used.
    4. Alexey Melnikov: Comment [2010-12-26]:
      5.1. Stability: "If no information about stability is available, users of anonymised data MAY assume that the techniques used are stable across the entire dataset, but unstable across datasets."
      This doesn't look like an implementation choice, so I think MAY is wrong here.
      6.1. Anonymisation Records and the Anonymisation Options Template: "First, reliability is important: an Exporting Process SHOULD export Anonymisation Records after the Templates they describe have been exported, and SHOULD export anonymisation records reliably."
      What is the exact meaning of the last SHOULD?
      TLS and DTLS need Informational References.

    Telechat:

  5. Security Concerns With IP Tunneling (Informational)
    draft-ietf-v6ops-tunnel-security-concerns-04
    Token: Ron Bonica
    Note: Joel Jaeggli (joelja@bogus.com) v6ops wg cochair is the document shepherd.
    Discusses/comments (from ballot 3615):
    1. Jari Arkko: Comment [2011-01-05]:
      Section 6.1.1 attack does not appear to be any worse than the assumptions required for this attack to be possible. If you can spoof the victim's DNS, you can hijack the victim's communications, tunnels or no tunnels.
      In this light the recommendation to prefer IPv4 over tunneled IPv6 is odd. Also, its not clear that whoever is selecting which addresses to use is aware of whether tunneling is being done or not (host vs. router, for instance).
      (This recommendation may be good for other reasons, of course.)
    2. Stewart Bryant: Comment [2011-01-05]:
      There are a lot of tunnel mechanisms are being deployed simply so that end users can work around the fact that they do not have enough IP addresses by creating a private overlay network.
      The document seems to miss the opportunity to say that by deploying IPv6 the need for many of these tunnels can be removed.
    3. Adrian Farrel: Discuss [2011-01-05]:
      I *think* that the scope of this document is intended to be "security considerations for the use of IP tunnels in IPv6 migration scenarios."
      It looks like the document goes on mainly to consider the issues that arise in such situations, although the title and abstract etc. are not clear on this limitation, and some places in the text seem to open the discussion up more general tunneling applications.
      While v6ops is a good home for a document with limited scope, it worries me that the more general discussion is restricted to that working group. The shepherd write-up declares "The document has been quite extensively socialized", without explaining where this socialization took place.
      In short, scoped so widely (i.e., not limited to the applicability of tunnels to v6 migration strategies) this document appears to be out of scope for the v6ops working group.
      There would appear to be two solutions:
      1. Add a few small changes to make clear that the scope is limited to v6 migration (or maybe to v6 use of tunnels)
      2. Find the right review forums within the IETF to ensure proper breadth of review (opsec, WGs responsible for the main tunneling protocols, ...)
      Note that I do not consider that the IETF last call on a document with a file name starting "draft-ietf-v6ops-..." guarantees broad enough review.
      I would like to see a little more clarity on the meaning of "IP tunnels". I think you are trying to discuss situations where an IP packet can contain, through some form of encapsulation, another IP packet. It would be really nice to make this crystal clear.
    4. Adrian Farrel: Comment [2011-01-05]:
      Section 2.1.1: "This reduces defense in depth and may cause security gaps."
      I can't parse this :-( Do you mean... "This reduces the depth of security available, and may cause security gaps."
      Is it right that Section 2.3 is limited only to source routing? Isn't it the case that tunneling can be used to inject any IP option into a network and cause trouble?
    5. Russ Housley: Discuss [2011-01-05]:
      The Gen-ART Review by Joel Halpern on 28-Dec-2010 raises a question that has not been answered. I think that a response is needed.
    6. Tim Polk: Comment [2011-01-05]:
      Issue #1: I think the intended scope of this document is not consistently stated (explicitly and implicitly):
      (1) the document title is "Tunneling Security Concerns";
      (2) the abstract states "The primary intent of this document is to raise the awareness level ..."
      (3) the introduction states "This document discusses security concerns ... and includes recommendations where relevant."
      (4) the introduction also states "The primary intent is to help improve security deployments ..."
      Based on the title and the abstract, I was expecting a problem statement draft. The first bit I quoted from the intro implies that this is a problem statement draft, and the recommendations are an afterthought. The last bit says the recommendations are the whole point of the document.
      IMHO, the recommendations are the most important contribution made by this document. I would like to see edits in the abstract and intro to clearly state that. It may be too late to address the title, but "Mitigating Tunneling Security Concerns" would also clearly demonstrate that scope.
      Issue #2: The document presents a collection of network architecture and network administration recommendations, but readers might really benefit from some summary recommendations. I was hoping for a section that moved the document from a laundry list to a methodology of sorts that worked through the architectural decisions first, then moved on to mitigating the specific problems remaining after the architectural decisions are made. For example, it seems that architecting your network so that tunnels don't cross security boundaries is a key first step. If you don't follow that recommendation, everything else is harder, isn't it?
      Issue #3: The introduction closes with "The intended audience ... includes network administrators and future protocol developers." I had a hard time understanding what the lessons are for future protocol developers.
      Perhaps a paragraph or two summarizing recommendations for protocol developers would be useful here.
      Issue #3: Section 5.1 is conspicuous in its structure: it includes a "5.1.1 Problem", but omits the expected "5.1.2 Discussion" and "5.1.3 Recommendations". Is it true that there is nothing to say here?

    Telechat:

  6. Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations (Informational)
    draft-ietf-v6ops-tunnel-loops-01
    Token: Ron Bonica
    Note: Joel Jaeggli (joelja@bogus.com) is the document shepherd.
    Discusses/comments (from ballot 3637):
    1. Jari Arkko: Discuss [2011-01-05]:
      This is a good document and should be published. However, I have one concern about the described neighbor cache check solution. First off, the document is incorrect that hosts must continuously send RSes to keep their address configuration up to date. More importantly, the neighbor cache is just that, a cache. A better solution would be to probe for a neighbor and only drop the packet if there was no response. This is already described in the document. My suggestion would be to delete the neighbor cache check solution entirely from the document.
      I think it would also be great if this document made a stronger statement about the IMO most important use case for automatic tunnels: broadband home networks. These are very simple networks with just one exit router and it would be important to highlight the significance (or lack thereof) of the attack in this case & point to the recommended solution.
    2. Stewart Bryant: Discuss [2011-01-05]:
      "based on protocol-41 encapsulation" needs a reference
      I have tried to read section 2 a number of times and I do not understand the loop.
      I do not understand what "The attacker exploits the fact that R2 does not know that R1 does not take part of T2" means.
    3. Adrian Farrel: Discuss [2011-01-06]:
      Having had some time to go back and re-read this document I am now not comfortable.
      1. In Figure 1, why is R2 advertising reachability to an IPv6 at all? It has only one point of attachment to the v6 network. I think you are trying to say that there is a virtual link (v6 capable) running over the v4 network. Isn't that link simply part of the v6 network?
      2. Why is R2 advertising reachability to an address that is not reachable through it? You say: "...destined to a fictitious end point that appears to be reached via T2..."
    4. Russ Housley: Discuss [2011-01-05]:
      The Gen-ART Review by Joel Halpern on 28-Dec-2010 raises a question that has not been answered. I think that a response is needed.
    5. Tim Polk: Comment [2011-01-05]:
      Please clarify that the document's scope does not address the Teredo attacks specified in the USENIX paper.
    6. Peter Saint-Andre: Comment [2011-01-05]:
      Given that the document describes an attack that can result in denial of service, a reference to RFC 4732 would be appropriate.

    Telechat:

3.1.2 Returning Items

  1. VPLS Interoperability with CE Bridges (Informational)
    draft-ietf-l2vpn-vpls-bridge-interop-06
    Token: Stewart Bryant
    Note: Shane Amante <Shane.Amante@Level3.com> is the document shepherd.
    Discusses/comments (from ballot 2633):
    1. Adrian Farrel: Comment [2010-03-09]:
      The new revision addresses a number of the points I raised in my review of 11-Apr-2009. I will clear my Discuss and record the three unaddressed points here.
      Section 2: Maybe this could use a figure. There is a lot of information conveyed and perhaps a figure of a VPLS showing the network and instance would help.
      Figure 2+: I can sort of look at figures 1 and 2 and see a more complete picture of the PE model with PWs on one side and CEs on another. I think that in figure 2 it would help to label the ACs (C-VLANs), but it would also be helpful to show CE attachment when the ACs are not VLANs. Is there some way to give this more comprehensive picture?
      Section 9: To me, this section feels very light. I am not a security expert, but the fact that you are extending an architectural model should give rise to new security issues for consideration.
    2. Sam Hartman: Discuss [2007-12-19]:
      Security directorate comments by Phillip Hallam-baker have not been addressed. These comments were not submitted as public last call comments. However they raise serious readability and interpretability questions of the document. I do know that some of Phil's comments are wrong because I've read some of the VPLS base specs. So, I tried to make an independent review of the document in order to determine if there was anything blocking. However I failed to be able to comprehend the document well enough to follow it. I gave up in the middle of section 3 with very little understanding of where the document was going and low confidence that the description of VPLS in this document matched my understanding from the base VPLS specs.
      To make this discuss actionable, I recommend that the authors work with reviewers outside their working group and improve the document to a point where someone who has not worked extensively in the L2VPN working group but who has read the VPLS documents can easily follow the document and can accurately describe what is going on.
    3. Russ Housley: Comment [2010-03-10]:
      (blank)
    4. David Ward: Discuss [2007-12-20]:
      Unfort, I find the doc very, very terse and almost unable to understand the points that are being made and the suggested recommendations. In addition I find it odd that there are cases where interop needs to be "worked out." It suggests that an interop procedure or recommendation is incomplete and thus, the doc is premature.

    Telechat:

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP (Informational)
    draft-loreto-http-bidirectional-07
    Token: Alexey Melnikov
    Note: Martin Thomson <Martin.Thomson@andrew.com> is the document shepherd.

    Discusses/comments (from ballot 3451):
    1. Sean Turner: Comment [2011-01-05]:
      Sec 8: r/attacks.[RFC4732]./attacks [RFC4732].

    Telechat:

  2. Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms (Informational)
    draft-turner-md5-seccon-update-08
    Token: Alexey Melnikov
    Note: Sean Turner (turners@ieca.com) is the document shepherd.
    Discusses/comments (from ballot 3493):
    1. Russ Housley: Comment [2011-01-05]:
      I think this documnet would be more useful to people trying to choose an algorithm if Section 2 were structured to present the conclusions at the beginning, and then provide the details in the susbsections. I suggest:
      "MD5 was published in 1992 as an Informational RFC. Since that time, MD5 has been extensively studied and new cryptographic attacks have been discovered. Message digest algorithms are designed to provide collision, pre-image, and second pre-image resistance. In addition, message digest algorithms are used with a shared secret value for message authentication in HMAC, and in this context, some people may find the guidance for key lengths and algorithm strengths in [SP800-57] and [SP800-131] useful.
      "MD5 is no longer acceptable where collision resistance is required such as digital signatures. It is not urgent to stop using MD5 in other ways, such as HMAC-MD5; however, since MD5 must not be used for digital signatures, new protocol designs should not employ HMAC-MD5. Alternatives to HMAC-MD5 include HMAC-SHA256 [HMAC][HMAC-SHA256] and [AES-CMAC] when AES is more readily available than a hash function."

    Telechat:

  3. MD2 to Historic Status (Informational)
    draft-turner-md2-to-historic-10
    Token: Robert Sparks
    Note: Sean Turner (turners@ieca.com) is the document Shepherd.
    Discusses/comments (from ballot 3575):
    1. Adrian Farrel: Comment [2011-01-04]:
      Comment transferred from my previous process Discuss.
      I fully support knocking MD2 on the head. However, I am a little inexperienced with the process of making an I-D Historic.
      What happens to an standards track documents with references (especially normative references) to 1319 as listed in Section 3? Should they at least also be marked as "updated by" this draft?
      Similarly, 1319 updates 1115. What happens to 1115 and its text on MD2?
    2. Alexey Melnikov: Comment [2010-12-19]:
      Updates: 1319 (once approved)
      - why not Obsolete: 1319 ? This document is moving RFC 1319 to Historic.
      3. Documents that Reference RFC 1319
      MD2 has been specified in the following RFCs:
      *Use* of MD2 has been specified ...

    Telechat:

  4. MD4 to Historic Status (Informational)
    draft-turner-md4-to-historic-10
    Token: Robert Sparks
    Note: Sean Turner (turners@ieca.com) is the document Shepherd.
    Discusses/comments (from ballot 3611):
    1. Adrian Farrel: Comment [2011-01-05]:
      As with the MD2 document, I think it is worth listing the standards track documents shown in Section 3 as Updated in the document header.
      It looks to me that you might also want to update some of the informational documents listed here.
      The prime benefit is that those documents will be marked in the RFC repository as having been updated by this document.
      Abstract, etc.: Once published, this document should be more assertive. Thus:
      OLD: This document recommends RFC 1320 be moved to Historic status.
      NEW: This document moves RFC 1320 to Historic status.
      4. Impact on Moving MD4 to Historic: s/on/of/
      Section 4: MD4 was used in the Inter-Domain Routing Protocol (IDRP); each IDRP message carries a 16-octet hash that is computed by applying the MD-4 algorithm (RFC 1320) to the context of the message itself. Over time IDRP was replaced by BGP-4."
      Need to add a refernce to 4271, and an indication that BGP-4 requires at least MD-5. You could reference 2385, but that might be de trop.
      Section 4: "The three Microsoft RFCs, [RFC2433], [RFC2759], and [RFC4757], are:
      Do we need to describe these as "Microsoft RFCs"? How about: "The three RFCs describing Microsoft protocols"?
    2. Alexey Melnikov: Comment [2010-12-19]:
      The document header has: "Updates: 1320 (once approved)" Why not "Obsoletes: 1320" ?

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. Cisco Vendor Specific RADIUS Attributes for the Delivery of Keying Material (Informational)
    draft-zorn-radius-keywrap-17
    Token: Dan Romascanu
    Discusses/comments (from ballot 2377):
    1. (none)

    Telechat:

  2. A Framework of Media-Independent Pre-Authentication (MPA) for Inter- domain Handover Optimization (Informational)
    draft-irtf-mobopts-mpa-framework-08
    Token: Jari Arkko
    Note: Rajeev Koodli (rkoodli@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3602):
    1. Ralph Droms: Comment [2011-01-06]:
      I strongly suggest that the following comments are addressed before publication:
      In section 7.3.1, a DHCP relay agent does not have the capability to operate independently and perform a DHCP message exchange with a DHCP server in anticipation of an eventual DHCP message exchange initiated by a client. The mecahnism described in this section would require the definition of a new DHCP proxy function.
      In the case of IPv6, it's probably required to forward the RA to the mobile node regardless of the address assignment model, to pre-configure the mobile node with all the requisite information about prefixes, etc.
      In section 7.3.3, there is a conflict with the DHCPv6 specification, which requires that a DHCPv6 client send any messages to the DHCPv6 servers/relays multicast address, rather than unicast to a server.
      There may also be a problem with all of these methods using DHCP: how does the CTN DHCP server know what address to assign to the client?
      Other comments:
      Perhaps a nit, but I was somewhat mislead by the title, "A Framework of Media-Independent Pre-Authentication (MPA) for Inter-domain Handover Optimization" to believe that I was going to read about a protocol that focused on authentication and secure communication. In my opinion, this document describes a complete framework for media-independent inter-domain handover optimization that goes beyond authentication and security.
      In Appendix A, wouldn't DAD be performed by the NAR rather than the PAR?
      From the Intro: "In this document we discuss a framework to support terminal mobility that provides seamless handovers with low latency and low loss."
      Are there other components to terminal mobility aside from MPA?
      Section 1.2: "A trade-off between one-way-delay and packet loss is desired based on the type of application."
      Unclear to me - a trade-off should be available through tuning or one-way-delay should be improved relative to packet loss?
      Section 3: Define "inter-subnet handover"?
      Section 6.1: "MPA provides three basic procedures to provide this functionality. The first procedure is referred to as "pre-authentication", the second procedure is referred to as "pre-configuration", the combination of the third and fourth procedures are referred to as "secure proactive handover"."
      "three basic procedures" and "third and fourth procedures" is confusing; where did that fourth procedure come from?
      Section 6.1: "Especially, the third procedure described above (i.e., binding update procedure)"
      Change "third procedure described above" to "step (iii) in the previous paragraph" to avoid confusion with the use of "procedures in the earlier paragraph in section 6.1.
      Section 6.2: "The authentication protocol MUST be able to derive a key between the mobile node and the authentication agent and SHOULD be able to provide mutual authentication."
      Is "derive a key between ..." a term of art or can the requirement be described more accurately as "establish a shared key between..."?
      "The authentication protocol SHOULD be able to interact with a AAA protocol such as RADIUS and Diameter to carry authentication credentials to an appropriate authentication server in the AAA infrastructure."
      Does the authentication protocol interact directly with the AAA protocol, or does the interaction happen through the AA?

    Telechat:

3.3.2 Returning Items

  1. The Internet Routing Overlay Network (IRON) (Experimental)
    draft-templin-iron-16
    Token: Jari Arkko
    Note: Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot 3638):
    1. Jari Arkko: Comment [2010-12-16]:
      (blank)
    2. Stewart Bryant: Comment [2010-12-15]:
      I am surprise that the document contains no reference to LISP which is operating broadly in this space.
      SRA is not a defined abbreviation.
      This needs a few words of clarification - presumably the "locator addresses" are the addresses learned from the relay.
      "After the Client receives an SRA message from the nearby Relay listing the locator addresses of nearby Servers, it sends SRS test messages to one or more of the locator addresses to elicit SRA messages."
      "If this Server fails, the Client will quickly select a new one which will automatically update the VPC overlay network mapping system with a new EP-to-Server mapping."
      "quickly" is a non-specific metric
      [I-D.templin-intarea-seal] looks like it should be normative
      [I-D.templin-intarea-vet] looks like it should be normative
      Although the RFCeditor may wish to overlook this if there is a concern that these drafts will not be taken to completion.
    3. Ralph Droms: Comment [2010-12-16]:
      I have one suggestion about the content of the document. I'd like to see an analysis of how IRON actually "provide[s] scalable PI addressing without changing the current BGP [RFC4271] routing system" along with costs incurred by IRON. How does hiding the EPA addresses inside the IRON locator prefixes reduce the routes in the real Internet core? What is the cost in the routing tables maintained by the relays? How expensive is the anycast routing? How does inter-VPC routing work and how expensive is it?
      The remainder of my COMMENTs are editorial.
      In Section 6.1, I think I understand what this text is trying to explain, but I don't think it's correct:
      "It is therefore essential that the Client send the initial packets through its Server to avoid loss of SCMP messages that cannot traverse a NAT in the reverse direction."
      Does this mean to explain that the Client sends packets through its Server to establish NAT state so SCMP messages from the Server to the Client can traverse the NAT?
      In Section 6.2, this text uses "into the Internet" in a confusing way, assuming I'm understanding the meaning of the text correctly:
      "The Server then forwards the revised packet into the Internet via a default or more-specific route, where it will be directed to the closest Relay within the destination VPC overlay network."
      Everywhere else in this section "into the Internet" is used to describe the forwarding of a decapsulated datagram, after the outer header with locator addresses have been removed, into the (non-IRON) Internet. In the text quoted aboce, "into the Internet" seems to mean forwarding of an encapsulated datagram, which is described elsewhere in this section as simply "forwards" or "sends". I suggest rewriting, for consistency, as
      "The Server then forwards to the closest Relay within the destination VPC overlay network."
      In Figure 6, why would the anycast datagram from Server(A) be delivered to Relay(B) rather than Relay(A) (which presumably would be in the routing fabric for ISP A)? Does it matter?
      Once Server(B) receives the datagram to be forwarded to Client(B), is it possible for Server(B) to send a redirect to Client(A) so Client(A) can send traffic directly to Client(B)?
      Stylistic nit in section 6.4.1 (and elsewhere) - why start using the verb "releases" instead of the previously used "forwards" or "sends"? Seems like lots of unnecessary verbiage right after Figure 6; why not something like "..., host A sends packets to host B through its EUN. Client(A), as the defautl router for the EUN, receives the packets, encapsulates them in the IRON encapsulation and forwards them to Server(A). ..." (etc.) All the explanation of routing, etc., seems redundant at this point.
      Sorry, can't help myself; in section 6.6:
      "The IRON approach to renumbering avoidance therefore depends on VPCs conducting ethical business practices and offering reasonable rates."
      ... as opposed to the unethical business practices and unreasonably high rates from those evil, greedy ISPs.
      Seriously, has the renumbering problem simply been moved from the ISPs to the VPCs?
    4. Adrian Farrel: Comment [2010-12-16]:
      Thank you for bringing this work forward as Experimental and so increasing the documentation and discussion of potential solutions.
      I feel that it would be helpful if the document contained a pointer to draft-irtf-rrg-recommendation so that the other ideas in the field can be easily found and compared.

    Telechat:

1253 EST break

1258 EST back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Audio/Video Transport Payloads (payload)
    Token: Robert

    Telechat:

  2. Metric Blocks for use with RTCP's Extended Report Framework (xrblock)
    Token: Robert

    Telechat:

  3. Audio/Video Transport Core Maintenence (avtcore)
    Token: Robert

    Telechat:

  4. Audio/Video Transport Extensions (avtext)
    Token: Robert

    Telechat:

4.1.2 Proposed for Approval

  1. ControLling mUltiple streams for TElepresence (clue)
    Token: Gonzalo

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. IPFIX interoperability meeting in Prague (Dan Romascanu)

    Telechat:

  2. WG and BoF Scheduling for IETF 80 (Russ)

    Telechat:

  3. Note (Amy)

    Telechat:

7. Agenda Working Group News

1338 EST Adjourned

Appendix: Snapshot of discusses/comments

(at 2011-01-06 07:27:56 PST)

draft-ietf-pkix-ocspagility

  1. Jari Arkko: Discuss [2011-01-04]:
        
> A responder MAY maximize the potential for ensuring interoperability
> by selecting a supported signature algorithm using the following
> order of precedence, as long as the selected algorithm meets all
> security requirements of the OCSP responder, where the first method
> has the highest precedence:
>
> 1.  Select an algorithm specified as a preferred signing algorithm in
>     the client request
>
> 2.  Select the signing algorithm used to sign a CRL issued by the
>     certificate issuer providing status information for the
>     certificate specified by CertID
>
> 3.  Select the signing algorithm used to sign the OCSPRequest
>
> 4.  Select a signature algorithm that has been advertised as being
>     the default signature algorithm for the signing service using an
>     out of band mechanism
>
> 5.  Select a mandatory or recommended signing algorithm specified for
>     the version of the OCSP protocol in use
>
> A responder SHOULD always apply the lowest numbered selection
> mechanism that is known, supported, and that meets the responder's
> criteria for cryptographic algorithm strength.

I am confused by the last sentence and how it uses the words "selection
mechanism". Does this sentence talk about algorithms or the above selection
methods? But the selection methods do not have an algorithmic strength, nor are
they negotiated. Suggested replacement text:

A responder SHOULD always apply the lowest numbered selecetion mechanism that
results in the selection of a known and supported algorithm that meets the
responder's criteria for cryptographic algorithm strength.
  2. Jari Arkko: Comment [2011-01-04]:
    
    
  3. Adrian Farrel: Discuss [2011-01-05]:
    
    
        I find a small discrepency at the end of Section 4

   The server SHOULD use one of the preferred signature algorithms for
   signing OCSP responses to the requesting client.

This means (I think) that the server MAY use an algarithm not listed by the
client as preferred. You need to cover:
- under what circumstances
- what
expectations of success it will have

But, in fact, I think the whole of Section 5 is dedicated to the question of how
to select a suitable algorithm, and that means that this sentence in Section 4
needs to be replaced with:

   Section 5 of this document describes how a server selects an
   algorithm for signing OCSP responses to the requesting client. 
    
    
    
  4. Adrian Farrel: Comment [2011-01-05]:
    
    
    The RFC Editor will ask you to remove the citation from the Abstract. 

---

http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt shows 
that OCSP is not a "well-known" acronym. SO could you please expand it 
in the document title, the Abstract, and on first use in Section 2.

---

A number of other acronyms are used without expansion.
CA
CRL
DSA

---

Section 5.1

Did you think of splitting option 5 into:
  5. select a mandatory algorithm
  6. select a recommended algorithm
since there is a very marked difference in the likelihood of success.

    
    
  5. Alexey Melnikov: Comment [2011-01-04]:
    
    
    In Section 4:

   The client MUST support each of the specified preferred signature
   algorithms and the client MUST specify the algorithms in the order of
   preference.

I think this is not actually saying what the order is. I suggest adding
something like
"from the most preferred to the least preferred"

8.3. Denial of Service Attack

   Algorithm agility mechanisms defined in this document introduces a
   slightly increased attack surface for Denial of Service attacks where
   the client request is altered to require algorithms that are not
   supported by the server, alternatively does not match pre-generated
   responses.

The last part (after the final comma) is not readable.

[NEWASN] - is this a Downref? If it is (and it wasn't explicitly called out
during the IETF LC), is [NEWASN] in the Downref registry?
    
    
  6. Peter Saint-Andre: Comment [2011-01-05]:
    
    
    1. Section 8.1 uses the phrases "considered unacceptably insecure" and "not
considered acceptably secure". Are these equivalent?

2. In Section 8.3, please consider citing RFC 4732 on the concept of denial of
service attacks.
    
    
  7. Sean Turner: Comment [2011-01-04]:
    
    
    I am going to recuse myself from this draft because I was involved in proposing
the ASN.1 structure.  I don't consider that an insignificant contribution.  I am
however happy with this draft.
    
  




draft-ietf-httpstate-cookie


  
    
    
  1. Jari Arkko: Comment [2011-01-03]:
    
    
    I agree with the Discusses from Alexey, Robert, Tim, and for the most part with
Sean. I do not agree with the Discuss from Adrian. Obviously the document can
make those actions.
    
    
  2. Adrian Farrel: Comment [2010-12-13]:
    
    
    Section 1

Please don't be so timid.

OLD
   This
   document attempts to specify the syntax and semantics of these
   headers as they are actually used on the Internet.
NEW
   This
   document specifies the syntax and semantics of these
   headers as they are actually used on the Internet.
END

---

Section 10.2

You have:

   [Netscape]
              Netscape Communications Corp., "Persistent Client State --
              HTTP Cookies", 1999, <http://web.archive.org/web/
              20020803110822/http://wp.netscape.com/newsref/std/
              cookie_spec.html>.

1. Are you sure this is the best version of the spec? The document is
   headed: "Preliminary Specification - Use with caution"

2. RFC Erratum 1491 reads:

     Section 12 says:

     [Netscape] "Persistent Client State -- HTTP Cookies", available at
                <http://www.netscape.com/newsref/std/cookie_spec.html>,
                undated.

     It should say:

     [Netscape] "Persistent Client State -- HTTP Cookies", available at
                <http://www.netscape.com/newsref/std/cookie_spec.html>,
                undated.

                Copy avalaible at <http://curl.haxx.se/rfc/cookie_spec.html>

   Can you confirm that you do not need to add a "copy available"
   statement to this document?

   (See http://www.rfc-editor.org/errata_search.php?eid=1491)

---

Erratum 2644 seems to have been submitted after the date of your I-D.
I assume that this Erratum will be rejected as soon as your I-D
becomes an RFC.
                                                    
   (See http://www.rfc-editor.org/errata_search.php?eid=2644)

---

Section 2.1
In particular, the algorithms defined in this
   specification are intended to
be easy to understand and are not
   intended to be performant.

Do you really mean "performant" which my dictionary gives only as a 
noun meaning " a perforemer".

I found
http://weblogs.asp.net/jgalloway/archive/2007/05/10/performant-isn-t-a-word.aspx

    
    
  3. Alexey Melnikov: Discuss [2010-12-20]:
    
    
        [Updated as per -20]

This is a well written document. I am contemplating voting Yes on this document
once my issues (see below) are discussed/resolved, not because Cookies are
pretty, but because this is the best attempt to describe them properly.

7) In Section 5.4:

   NOTE: Despite its name, the cookie-string is actually a sequence of
   octets, not a sequence of characters.  To convert the cookie-string
   (or components thereof) into a sequence of characters (e.g., for
   presentation to the user), the user agent might wish use the UTF-8
   character encoding [RFC3629] to decode the octet sequence.

Clients can't assume that an arbitrary sequence of octets generated by the
server would be a valid UTF-8.
This needs to be clarified.

9) From Lisa Dusseault's Apps Area Review:

Section 3. "Origin servers can send a Set-Cookie response header with
any response.".  Do we happen to know if it's more common for user
agents to handle, or ignore Set-Cookie response headers on error
responses?  I'd be surprised if user-agents do handle them including
on 500-level, 400-level and particularly on a 100 Continue response,
but I haven't tested it.  Is it part of your tests?  So while this
statement is factual, it might not help servers much.  If my
assumption about some clients ignoring the header on some classes of
responses is correct, I would add that information to the document in
a non-normative sentence.
 
    
    
    
  4. Alexey Melnikov: Comment [2010-12-20]:
    
    
    5.1.1.  Dates

   year            = 1*4DIGIT ( non-digit *OCTET )

Do people really use 1 digit and 3 digit years?
I very much doubt that a single digit year is allowed, so may I suggest:

   year            = 2*4DIGIT ( non-digit *OCTET )

    
    
  5. Tim Polk: Discuss [2011-01-06]:
    
    
        This discuss was motivated in part by Richard Barnes' Gen-ART review.   Richard
noted that:

"Many of these integrity issues are caused by user agents accepting cookies from
outside the context where they would send them, in particular with the Secure
and Path attributes.  It seems like this document, in specifying the
desired/proper behavior of user agents, should require behavior that would
mitigate these attacks.  In direct parallel to the handling of the Domain
attribute:
 1. Set-Cookies with the Secure flag should only be accepted over
secure channels
 2. Set-Cookies with the Path attribute set should only be
accepted if the path value matches the request-uri of the request
(That is,
update Steps 7 and 8 of S5.3 to match Steps 6 and 9/10)

The author responded:
"I agree that these would be desirable changes to the cookie protocol.
However, the http-state working group is not chartered to change the
cookie protocol.  In particular, the charter reads as follows:

     The working group must not introduce any new syntax or new semantics
     not already in common use."

I understand that this document cannot impose new rules or syntax.  However, as
written this document
appears to *prohibit* clients from extending the algorithm
to protect themselves:  User agents are required
to implement algorithms
"equivalent to" the algorithms specified in Section 5  to process dates (section
5.1.1),
paths (5.1.4), parse a set cookie string (Section 5.2), and the
processing the cookie (Section 5.3, which was
at the heart of Richard's issues),
processing the cookie header (section 5.4), etc.  This does not leave an
implementer with any wiggle room, forcing them to accept insecure processing
rules.

This document should not prohibit clients from doing additional processing to
enhance their own security,
especially since the processing rules proposed by
Richard apparently would not affect interoperability with
a well-behaved server.

I believe that a better model is the PKIX path validation processing algorithm,
where "functionally equivalent"
implementations are required but are explicitly
permitted to extend the model to enhance security.  For example,
some
implementers have chosen to require that a certificate and CRL be signed by the
same cryptographic key
to guard against name collisions.  This is not required
by PKIX but implementations that include this feature
are still compliant.

Is there a good reason why extensions to the user agent's processing cannot be
extended as Richard suggested? 
    
    
    
  6. Tim Polk: Comment [2010-12-16]:
    
    
    I found the following Note at the end of 4.1.1 confusing:

   NOTE: Some user agents represent dates using 32-bit UNIX time_t
   values.  Some of these user agents might contain bugs that cause them
   to process dates after the year 2038 incorrectly.

After considering this for a while, I concluded that the point is that user
agents
might convert the dates into UNIX time_t values for storage and
processing, and
implementation bugs mean that dates after 2038 are not
interpreted correctly.  If
that is correct, then maybe the following would be an
appropriate substitution:

   NOTE: Some user agents store and process dates in cookies as 32-bit UNIX
time_t values.  Implementation bugs in the libraries supporting time_t
processing
   on some systems may cause such user agents to process dates after
the year
   2038 incorrectly.


    
    
  7. Robert Sparks: Discuss [2010-12-14]:
    
    
        In 4.1.1 (Syntax) - Why is the specification part of this proposed standard
allowing implementations to 
violate the grammar defined by this standard? The
SHOULD NOT in the first paragraph of this section must
be a MUST NOT. If the
intent is to make sure clients are liberal in what they accept because existing
servers may generate non-conformant grammar, just say that (and if possible,
point to what they might
need to expect). If the intent is to allow servers that
are compliant to generate messages not covered
by this grammar, then the grammar
is incorrect. If that's the case, the grammar should be extended to 
allow the
alternate behavior and the document's prose can say that servers SHOULD NOT use
those parts 
of the grammar.

    
    
    
  8. Robert Sparks: Comment [2010-12-14]:
    
    
    Please consider moving the SHOULD in the first of the two NOTE:s at the end of
4.1.1 out of the NOTE.

Consider noting in the discussion of "public suffixes" that the problems this
mechanism attempts
to avoid are still present in deeper heirarchies (A server at
math.example.edu will be able to
set cookies for example.edu, potentially
affecting the behavior of infosec.example.edu)
    
    
  9. Sean Turner: Discuss [2010-12-16]:
    
    
        [These are my preliminary discusses.  I might find more later.]

This is a well written document, but I've got a couple of things I'd like to
discuss:

#1) I'd like to see a new security consideration section that addresses
persistent cookies.  I think we need to mention how expiry date can be abused.
Is there some kind of recommendation we can give on their lifetimes?  Are
cookies good for 2, 5, 20 years okay?

#2) I'd like to see a new privacy|security consideration that says what's being
touted as "private browsing" doesn't protect cookies it only stops the history
from being updated.

#3) Section 7.1:  I understand it's hard to have one policy for third-party
cookies.  But, couldn't we say that assuming sites aren't behaving badly or
somehow otherwise sharing tracking data that users that wish to not be tracked
by third-parties ensure that third-party cookies be blocked?

#4) Section 7.2:  It's not a protocol thing, but should we really make the
following two SHOULDs:

User agents should provide users with a mechanism for managing the
   cookies stored in the cookie store.

User agents should provide users with a mechanism for disabling
   cookies.

#5) Section 8.3/8.5: Should point out that the format for signature/encryption
is server specific.

#6) Section 8.3, last paragraph:

a) The last paragraph, I believe, discusses "sidejacking" and "cookie monster"
attacks (or is that the 1st paragraph in 8.5?).  Is it worth explicitly
mentioning the name of these attacks?

b) To that end, can we add something like (I'm not wed to the words) the
following to the end of the paragraph in 8.3:

For example, a webmail server that is initially accessed via HTTPS but later
exchanges mail (and cookies) over HTTP will expose whatever cookie (and mail) is
exchanged between the client and server.  Sidejacking is when a MITM intercepts
the HTTP exchanges.  If a server incorrectly sets the Secure attribute and sends
a cookie that otherwise should have been sent over a secure channel, a MITM can
access the cookie (sometimes called a cookie monster attack).

#7) Sec 8:  Where would we say something about how when multiple users use the
same machine, they're not protected from one another?

#8) Sec 8: Shouldn't we have a section on cross-site scripting attacks (i.e.,
scripts that make browser send cookies to malicious servers that should not
receive them) and how http-only helps?  I.e., servers should set httpOnly to
stop these?

#9) Sec 4.2/8 ?: Where are cookie poising attack discussed (i.e., client returns
a different cookie than the one set by the server)? 
    
    
    
  10. Sean Turner: Comment [2010-12-16]:
    
    
    #1) Section 4: It's odd that following is in Section 4, which is titled Server
Requirements:

   User agents,
   however, MUST implement the requirements in Section 5 to ensure
   interoperability with servers making use of the full semantics.

Shouldn't it be in Section 5?

#2) In Section 5.2, add "(see Section 7.1)" to the end of:

For example, the user agent might wish to block responses to "third-party"
requests from setting cookies.

#3) In Section 5.4, add "(see Section 7.1)" to the end of:

For example, the user agent might wish to block sending cookies during "third-
party" requests.
    
  




draft-ietf-pim-group-rp-mapping


  
    
    
  1. Adrian Farrel: Comment [2010-12-31]:
    
    
    Routing Area Directorate review by Dimitri Papadimitriou raises a few very minor
editorial points that should be looked at together with any other comments and
issues raised during IESG review.

> Section 1: 
> 
> - "Each PIM-SM router may learn Group-to-RP mappings through
>    various mechanisms." which mechanisms ? ref's would be helpful
> 
> - "It is critical that each router select the same 'RP' for a specific
>    multicast group address." why ? a short sentence would be helpful
>    - note this requirement applies to al routers in the same "domain"
> 
> Section 4:
> 
> - "A Group-to-RP mapping learned for PIM-BIDIR mode is preferred to
>    an entry learned for PIM-SM mode."
>    is this reason dictated by arbitrary criteria or protocol operation 
>    criteria (dictated by RFC 5059) or other ?
> 
> Section 5: 
> 
> - Add ref's to BSR and Auto-RP in sentence
>   "In this case, to support some specific applications, they might like to
>    learn Group-to-RP mappings dynamically using either BSR or Auto-RP
>    mechanism."
> 
> - "This is not an issue for IPv6 Multicast address ranges." what "this" 
>    refers to ?
> 
> Section 6:
> 
> - What's the input to this algorithm ? there is a need to describe the set
>   of information onto which this procedure applies (the output is implicit).
> 
> - The description seems to mandate a sequential execution (from 1 to
>    10) but this is not stated ahead in the Section 6.
> 
> Section 9:
> 
> - " The algorithm in this document MUST be used. " on all routers in 
>   the domain? Please clarify. 
> 
> - "improve stability under misconfiguration" stability of what ? 
> 
> Section 11:
> 
> - does the term "block" refers to disable or filter ? or left unspecified ?
    
    
  2. Tim Polk: Discuss [2011-01-05]:
    
    
        This is a pretty straightforward discuss, and should be easy to clear.  As noted
in Vincent Roca's security
directorate review, the document would benefit from
some expansion of the security considerations.  In particular,
some pointers to
mechanisms for learning group-to-rp mappings that satisfy the constraint are
considered secure
would be helpful.  Please use Vincent's review as an input to
your revisions. 
    
    
    
  3. Dan Romascanu: Discuss [2011-01-04]:
    
    
        The issue of the relation between this document and RFC 5060 was raised by
Adrian with the MIB Doctors. At the end of the discussion which prompted to
various methods of altering the behavior of the routers that already support the
MIB module the resolution communicated by Adrian was: 'we have decided that we
do NOT want to update the semantics of the existing objects'.

I am still to be convinced that this is the case. 

7.  Interpretation of MIB Objects

   The algorithm defined in this document does not use the concept of
   precedence and therefore the values configured in the
   'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence' objects of
   the 'pimGroupMappingTable' table in the PIM-STD-MIB module [RFC5060]
   are not applicable to the new algorithm.  The objects still retain
   their meaning for 'legacy' implementations, but since the algorithm
   defined in this document is to be used in preference to that found in
   PIM-SM [RFC4601] and PIM-STD-MIB [RFC5060], the usage of these fields
   will decline as implementations are upgraded to support the new
   algorithm.

First, in RFC 5060 the  'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence'
objects are in two different tables - pimGroupMappingTable and pimStaticRPTable.
Each of the table has a different 'precedence' object and a different behavior.

Does pimStaticRPTable has any function with the new RP mapping algorithm? In RFC
5060 it is used to define static entries that may precede and override those
defined by the algorithm in 5060. Does this apply also to the algorithm defined
here?

What does exactly mean 'the usage of these fields will decline'? All the MIB
module defined in RFC 5060 is supported ('we do not want to update the
semantics') - so what happens with the pimGroupMappingTable? Section 8 describes
how objects in this table will continue to be used to indicate Group-to-RP
mapping.   Whay I am missing is what happenss if a manager creates a new entry
as per RFC 5060? Should the router just ignore it? We cannot assume all managers
are 'well-bahaved' and we need to prevent I think mis-configuration.

If the writeable part of the of this table is not disabled, this would be a
serious security problem, as it would interfere with the works of the new
algorithm.

A proper solution should include an update of RFC 5060, including changes in
MODULE-COMPLIANCE and possibly a new read-only table that would help the
operators read the entries created as result of the application of the new
mechanism. I understand that the authors and WG do not plan to do this in the
near future, but they need to define a clear and acceptable behavior of the
agents runing RFC 5060. Dully obsoleting RFC 5060 (and the usage of the MIB
module defined there) would be another solution at this point, but this is not
what the WG wants, as I understand. 
    
    
    
  4. Dan Romascanu: Comment [2011-01-04]:
    
    
    1. Section 5: 

   A network management station can determine the RP for a specific
   group in a specific router by running this algorithm on the
   Group-to-RP mapping table fetched using SNMP MIB objects.

MIB objects are meant to work not only with SNMP. Please change 'SNMP MIB
objects' to 'SMI MIB objects' or just 'MIB objects'.

2. Need to expand MIB and SNMP at first occurence. 
    
    
  5. Peter Saint-Andre: Discuss [2011-01-05]:
    
    
        This is a fine document. However, the algorithm does not specify rules for
determining which hash value or IP address is "highest", which might inhibit
interoperability. Please specify such rules (e.g., convert to "network byte
order" octet string representation and then apply i;octet collation from RFC
4790), or refer to specifications that define such rules. 
    
    
  




draft-ietf-roll-trickle


  
    
    
  1. Stewart Bryant: Discuss [2010-12-15]:
    
    
        "All that matters is that
   some nodes communicate with one another at some nonzero rate."

This is not right. If every node received, nothing would get communicated. In
addition I tend to think of communication as requiring some degree transmission.

I think that you mean transmits at some nonzero rate.

=======

Considering that later text says that Trickle breaks if there is a parameter
mismatch, I am concerned that this text is not strict enough:

   It is RECOMMENDED that a protocol which uses Trickle includes
   mechanisms to inform nodes of configuration parameters at runtime.
   However, it is not always possible to do so.  

I am also concerned with the get out clause that allows the degradation of a
MUST to a RECOMMENDATION. Surely for the cost of a few bytes the parameters can
at least be announced so that other nodes can get some hint that the mismatch is
occurring. 
    
    
    
  2. Ralph Droms: Comment [2010-12-14]:
    
    
    Nit: 3rd para of section 3, s/their/its/

Question: is the typical value of k in the range 1-5 independent of
the density of the network nodes, where I'm thinking of "density" as
the number of nodes that hear a given message?

    
    
  3. Lars Eggert: Discuss [2010-12-16]:
    
    
        I'm sorry for deferring this document to the next telechat. I want the TSV
directorate to review it and I didn't realize this in time to get the review
assigned.

I'm also balloting DISCUSS. That is, because looking at the current ROLL
charter, I have a hard time understanding how this document is in scope of the
WG. This document does not fall under any of the work items on the charter; and
it's not even what I'd consider a "routing" protocol. 
    
    
    
  4. Adrian Farrel: Comment [2010-12-24]:
    
    
    Rtg Dir review from Alia Atlas says:

I have reviewed draft-ietf-roll-trickle-06.   It is one of the best drafts that
I have read and I do not have any substantial or even editorial comments on it.
I found the protocol as described to be clear, simple and pretty elegant.
    
    
  5. Robert Sparks: Comment [2010-12-14]:
    
    
    In section 6.5 - The comment about "having the parameter describe k-1 instead of
k being confusing" is confusing. I had to think for some time to convince myself
that I understood what you were trying to say. I encourage you to further
explain, or rewrite the comment.

Why are you allowing different uses of trickle to give different meanings to
k=0? It would seem to facilitate interoperability (and simplify implementation)
if you just defined k=0 to mean turning off suppression in all cases. Individual
uses of trickle can forbid setting k=0 if they don't want to allow turning off
suppression.
    
  




draft-ietf-pwe3-oam-msg-map


  
    
    
  1. Adrian Farrel: Discuss [2011-01-03]:
    
    
        There are a couple of nits reported by idnits (an out of date reference,
an old license statement). I think the license statement should be
fixed and posted (to reflect the authors' intent) before the document is
approved.

---

I see IPR disclosed at http://datatracker.ietf.org/ipr/863/
I don't see this declared in the proto write-up. More important, it is
not present in the IETF last call announcement in datatracker.

---
What is the situation wrt multi-segment PWs? I can understand that this
document
was developed before the WG turned to MS-PWs, but we now have
RFC 5254 and RFC
5659.

I would prefer that this document fully addressed MS-PWs. That would not
be hard because each PW segment at an S-PE regards the adjacent segments
as ACs, so it could probably be addressed in just one or two paragraphs
in a new section.

However, an option is to declare MS-PW out of scope, and provide a
forward
reference to work being done on OAM message mapping for MS-PWs
in the PWE3 WG.

---

Section 4.2

   If LSP-Ping [RFC4379] is run over a PW as described in [RFC4377], it
   will be referred to as "VCCV-Ping".

I believe s/RFC4377/RFC5085/

---

Section 5
You should add a note to explain why the CE ends of the ACs are not
considered
as possible defect locations. They are part of the emulated
service, so a naif
reader might expect to see them listed. Possibly you
will want to explicitly
include it in case (a).

Additionally, your text does not match the figure:
   c. Defect on a PE1 PSN interface.
But (c) also appears on the PE2-PSN interface in the figure.

Furthermore, (e) and (f) appear tbe reversed in the figure compared to
the text.

---

Section 13

RFC 5085 and RFC 4447 should be presented as references.

I will let Security experts comment further, but:

 It seems to me that facilitating end-to-end coordination of PW status
 and fualt reporting provides an extra tool for attackers. I would
 expect this to be pointed out and held up as a reason for ensuring the
 use of the security mechanisms.

 I think that there are security coordination issues. Perhaps these are 
 already mentioned in the references. Consider carrying NS OAM from CE 
 to CE across the PSN in Single Emulated OAM Loop mode or Coupled OAM
 Loops mode. The security relationship perceived by the CEs would 
 presumably be between each other, but doesn't the PE need to 
 participate? 
    
    
    
  2. Adrian Farrel: Comment [2011-01-03]:
    
    
    Section 3                  
s/whereby/where/

---

The Introduction uses a number of acronyms without prior expansion.
On the other hand, having defined acronyms in Section 4.1, you don't
gave to expand them in subsequent sections.

---

Section 4.1
Several acronyms are not used in the rest of the document.
BDI
CPCS
IWF

s/label Switched Path/Label Switched Path/
s/Operations, Administration and Maintenance/
  Operations, Administration, and Maintenance/

---

Section 4.2

   The words "defect" and "fault" are used interchangeably to mean any
   condition that obstructs forwarding of user traffic between the CE
   endpoints of the PW service.

I'm fine with this, but I think "obstructs" is ambiguous. Do you mean
"impose a complete blockage", or do you mean to include degradation in
some form? Perhaps you could add a clarification.

---

Section 4.2

   If BFD is run over a PW as
   described in [RFC5885], it will be referred to as "VCCV-BFD".

Add a reference to [RFC5880]

---

Section 4.2

   A "transmit defect" is any defect that impacts traffic that is meant
   to be sent or relayed by the observing PE.  A "receive defect" is any
   defect that impacts traffic that is meant to be received by the
   observing PE.

While "meant to be" is appropriate for the reception of data, I don't
think it necessarily applies to transmission. Consider that the defect
may be somewhat downstream of (and not yet notfied to) the upstream PE
such that the traffic that is impaced is that which *has* been sent or
relayed by the observing PE.

Additionally, the term "observing PE" has not been defined and may
clarify or complicate the meaning of the text.

---

I had a few problems with Section 8.1. I think my issue is with the
use of the control plane as an OAM exchange mechanism (this also shows
up in Appendix B). I believe the section could benefit from some
polishing.

   For MPLS and MPLS/IP PSNs, a PE that establishes a PW using Label
   Distribution Protocol [RFC3036] MUST use the LDP status TLV as the
   mechanism for AC and PW status and defect notification, as explained
   in [RFC4447].

I don't think that this "MUST" is good or consitent with:
- the text in Section 7 that is relaxed in saying "LDP or in the ACH"
- the work in MPLS-TP

It sounds like 3036 (or rather 5036) is a normative reference.

While conveying PW status in LDP per 4447 is fine, it is not OAM with 
the utility of rapid propagation of fault notifications. LDP, reliant
as it is on TCP, is not suitable to that purpose.

Wouldn't it be better to require the use of the ACH for OAM fault
notification messages, and (if you must :-) mandate the use of LDP
for status information propagation when LDP is present (but not as a
replacement for real OAM).

Additionally...

   Additionally, a PE MAY use VCCV-BFD Connectivity
   Verification (CV) for
fault detection only (CV types 0x04 and 0x10
   [RFC5885]) but SHOULD notify the
remote PE using the LDP Status TLV.
The "SHOULD" here seems to be in conflict with te previous "MUST"

And it goes on...

   A PE that establishes a PW using means other than LDP, e.g., by
   static configuration or by use of BGP, MAY use VCCV-BFD CV (CV types
   0x08 and 0x20 [RFC5885]) for AC and PW status and defect
   notification.  Note that these CV types SHOULD NOT be used when the
   PW is established with the LDP control plane.

If you supply only a "MAY" you should probably describe how else the
fault notification might work.

As to the "SHOULD NOT" in the last sentence. Well, see my previous
comments. And what possible harm could it do?

---   

Section 6

   Generally, a PE cannot detect transmit defects directly and will
   therefore need to be notified of AC transmit or PW transmit defects
   by other devices.

I think you mean s/directly/direct/

---

Section 8.1.1
                                                                          
   [RFC4447] specifies that the "Pseudowire forwarding" code point is
   used to clear all faults.  It also specifies that the "Pseudowire Not
   Forwarding" code is used to convey any defect that cannot be
   represented by the other code points.

The language seems rather week.
The use of the code point does not clear the faults. It is used to 
report (notify) that the faults have been cleared.
Likewise, defects are not conveyed by the use of a control points, but
existence of the defect can be reported (or conveyed, if you like).
    
    
  3. Russ Housley: Comment [2011-01-05]:
    
    
      Appendix B.3: s/Los/Loss/
    
  




draft-ietf-avt-rtcp-port-for-ssm


  
    
    
  1. Adrian Farrel: Comment [2011-01-05]:
    
    
    As idnits points out, you can strip the RFC 2119 boilerplate and 
reference. I'm sure the RFC Editor can handle this.
    
    
  2. David Harrington: Comment [2011-01-05]:
    
    
    1) in section 1, "the +1 rule" is mentioned without definition or reference.
    
    
  3. Sean Turner: Comment [2011-01-05]:
    
    
    Section 5 has:

   This
   can, for example, be achieved on an end-to-end basis using S/MIME
   [RFC5652] when SDP is used in a signaling packet using MIME types
   (application/sdp).

Technically, S/MIME messages aren't in [RFC5652] they're in [RFC5751].  RFC 5652
is CMS,  which is profiled for email in RFC 5751.  I've noted that when used
with SDP S/MIME has been referred to as follows: RFC 4566 uses text that is
similar, but omits a reference for S/MIME; RFC 4657 uses RFC 3851 (previous
version of RFC 5751); RFC 4658 uses RFC 3851; RFC 3605 uses RFC 3852 (prior
version of RFC 5652); RFC 3261 refers to both 2633 (S/MIME) and 2630 (CMS).
Maybe the right approach is to point to both CMS and S/MIME.
    
  




draft-ietf-avt-rtp-cnames


  
    
    
  1. Stewart Bryant: Discuss [2011-01-05]:
    
    
        I think it would be helpful to the reader to briefly note that whilst the
methods described in this document are good enough for most practical purposes
they are not technically perfect. Whilst I can see no particular problem in the
application described here, these methods may well be re-purposed as convenient
general purpose UID mechanisms.

Specifically when the method described in (5) does not use an EUI-64 there is a
non-zero probability of collision, and the method in (4) that uses the MAC
address is only as good as the quality procedures and ethics of the hardware
manufacturer. 
    
    
    
  2. Adrian Farrel: Comment [2011-01-05]:
    
    
    Support Stewart's Discuss since we have observed "clone" equipment with
identical MAC addresses in the past. Also, I believe that some h/w exists with
configurable MAC addresses.

---

Abstract
s/these/those/

    
    
  3. Russ Housley: Discuss [2011-01-05]:
    
    
        
  The Gen-ART Review by Suresh Krishnan on 2-Jan-2011 raised an issue
  that needs to be resolved before publication. Section 5, Step 2,
  describes the use of an EUI-64 identifier and how to generate one if
  it does not exist. The procedure for the creation of the EUI-64 from a
  48-bit MAC address is incorrect:

  RFC 4291 describes how to create a *modified* EUI-64 identifier (not a
  EUI-64 identifier) from a MAC address. A MAC address of
  xx:78:90:12:34:56 will be transformed to a modified EUI-64 of
  yy7890FFFE123456, where yy is the value of xx with the u/l bit (bit 6)
  flipped. The IEEE reference for creation of an EUI-64 from a 48-bit
  MAC address (http://standards.ieee.org/develop/regauth/tut/eui64.pdf)
  would result in an EUI-64 of xx7890FFFF123456 for the same MAC address.

  While I recognize that no interoperability issues will result from
  this difference, there may be issues with testing if this is not
  resolved. Therfore, I suggest using the term "modified EUI-64" instead
  of EUI-64 or changing the reference from RFC 4291 to the IEEE
  document.
 
    
    
    
  4. Alexey Melnikov: Comment [2010-12-25]:
    
    
    5.  Procedure to Generate a Unique Identifier

   2.  Obtain an EUI-64 identifier from the system running this

I think this needs an Informative reference to a document which explains what is
EUI-64.

       algorithm.  If an EUI-64 does not exist, one can be created from
       a 48-bit MAC address as specified in [RFC4291].  If an EUI-64
       cannot be obtained or created, a suitably unique identifier,
       local to the node, should be used (e.g., system serial number).
    
    
  5. Tim Polk: Comment [2011-01-06]:
    
    
    I support Sean's discuss: hard-coding SHA-1 is unnecessary and
counterproductive.  There is no reason that all 
clients need to use the same
secure hash algorithm, IMHO.  (For example, two clients using SHA-256 and
SHA-512
are no more likely to generate a collision than two clients using
SHA-256.)  I suggest "compute a message digest
using a secure hash function
(e.g., SHA-256)" would provide the right level of detail for section 5.

A short paragraph should also be added to the security considerations section
with appropriate references.  (I think
Sean's discuss has the right list.)

I would also note that the algorithm in section 5 does not *guarantee*
uniqueness.  I think your odds of a collision
are one in 2**48 (but check with a
real mathematician!).  I note this since the Requirements section states "It is
believed that obtaining uniqueness is an important property ..."

Section 4.2, third bullet:

"After performing the procedure, the significant 96 bits are used ..."

Please specify "most significant" or "least significant"; the latter would be
consistent with the preceding bullet.
    
    
  6. Dan Romascanu: Comment [2011-01-04]:
    
    
    1. 
>    After obtaining a identifier by doing (a) or (b),
      the least significant 48 bits are converted to the standard colon-
      separated hexadecimal format, e.g., "00:23:32:af:9b:aa", resulting
      in a 17-octet printable string representation.

It would be good to provide a reference for this 'standard ... format'. RFC 5342
uses a different notation, so arguably there is more than one format used in
RFCs.

2. Also from 5342 - here is a reference for EUI-64 which could be added (also
answers the COMMENT from Alexey)

[EUI-64]  IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
             Registration Authority", <http://standards.ieee.org/
             regauth/oui/tutorials/EUI64.html>, March 1997.
    
    
  7. Peter Saint-Andre: Discuss [2011-01-05]:
    
    
        This is a fine document with the laudable goal of improving interoperability,
but in one respect I think it is both overly specific and unclear about the
requirements it is working to meet.

Section 4.1 states:

   An implementation that wishes to
   discourage this type of third-party monitoring can generate a unique
   RTCP CNAME for each RTP session....

However, a unique identifier does not necessarily discourage third-party
monitoring, e.g., incrementing from UniqueID-1 UniqueID-2 might ensure
uniqueness but not privacy. I suggest that we provide a reference to RFC 4086
here and recommend that those who desire privacy need to generate identifiers
that are not only unique but also random.

This issue is connected to Section 4.2, which mandates one algorithm for long-
term identifiers and a different algorithm for short-term identifiers (with
seemingly different security properties, since long-term identifiers are 36
octets in length whereas short-term identifiers are only 17 octets in length).
Would an implementation that generates a UUID for short-term identifiers violate
the spec? If so, why? As long as the short-term identifier is unique, the
implementation has met the relevant requirement. (Perhaps there is a further
requirement or desire to make the identifier random, as mentioned above, but
that is a separate issue.) 
    
    
    
  8. Sean Turner: Discuss [2011-01-06]:
    
    
        #2 was revised based on some side discussions.

#1) Section 5: On the use of SHA-1:  What properties are you looking from the
output?  If you require no collisions then SHA-1 is probably a bad idea (see
https://datatracker.ietf.org/doc/draft-turner-sha0-sha1-seccon/).  It would be
much better to use SHA-256 and truncate it.  And, then point to
https://datatracker.ietf.org/doc/draft-eastlake-sha2b/.  Yes it is a dependency
but it's in AD Evaluation.

#2) Section 5: Algorithm agility would be really nice here.  Locking yourself in
to one hash algorithm isn't a good idea.  If the client is the only entity that
is ever going to generate this hash true algorithm agility might not be needed,
but you could get it by picking a length you want and then saying that one of
the algorithms x, y, or z MUST be used.  That way the implementer can pick on
that they're doing in their cipher suite. 
    
    
    
  9. Sean Turner: Comment [2011-01-05]:
    
    
    Section 4: Need to add "NOT RECOMMENDED" to Section 2.  It's used as a key word
and the 2119 errata allow it, but you need to include it as shown in the errata
(http://www.rfc-editor.org/errata_search.php?rfc=2119).

Any chance for an example per-session unique identifier?
    
  




draft-ietf-dnsext-5395bis


  
    
    
  1. Jari Arkko: Comment [2011-01-05]:
    
    
    This is a good document and should go forward.

A few comments regarding the comments and discusses from other ADs:

- I do not believe this document is the place to obsolete z-bit. This is
  an IANA considerations doc.

- Regarding URLs and the template, I note that Specification Required
  is not explictly called for. Maybe it should be, and that would solve
  the URL problem (as the semantics of Specification Required have
  been defined elsewhere and reference stability is one criteria).
    
    
  2. Stewart Bryant: Comment [2011-01-05]:
    
    
    I agree with David Harrington's discuss.
    
    
  3. Adrian Farrel: Discuss [2011-01-05]:
    
    
        A small piece of IANA pedantry...

Section 1.1.

   "IETF Standards Action", "IETF Review", "Specification Required", and
   "Private Use" are as defined in [RFC5226].

5226 uses the term "Standards Action" not "IETF Standards Action". Could
you fix this up throughout the document? 
    
    
    
  4. Adrian Farrel: Comment [2011-01-05]:
    
    
    A nit:

The Abstract reads...

   Internet Assigned Number Authority (IANA) parameter assignment
   considerations are specified for the allocation of Domain Name System
   (DNS) resource record types, CLASSes, operation codes, error codes,
   DNS protocol message header bits, and AFSDB resource record subtypes.

Pedantically, this Abstract says nothing about *this* document.
Could you make it read...

   This document specifies Internet Assigned Number Authority (IANA)
   parameter assignment considerations for the allocation of...

    
    
  5. David Harrington: Discuss [2011-01-04]:
    
    
        in section 2.1, should the document state that the ancient usage is hereby
obsoleted and the z-bit MUST NOT be used for this ancient purpose in
implmenetations compliant to this spec?

in Annex 1, field E, should the document specify that it MUST be a long-lived,
stable URL if a URL is used?
What happens if the URL disappears?
Should a
document be required for escrow purposes?

    
    
    
  6. David Harrington: Comment [2011-01-04]:
    
    
    in section 1, s/is the change is the public review mailing list /is the change
to the public review mailing list/

in section 2.3, might it be good to recommend NOT overloading the values, ala
the 16 bit, since we have 60000+ bits available?

section 3.1.4 uses MX RR without prior definition, or reference to the
definition.

in Annex 1, field E, why does this end in a colon?

why is field J on a totally separate page?
    
    
  7. Alexey Melnikov: Comment [2010-12-19]:
    
    
    I have a couple of comments. Taking into consideration that this is a bis
document, I am making them Comment-level:

1)
3.1.1. DNS RRTYPE Allocation Policy

   No less than three weeks and no more than six weeks after a completed
   template has been formally posted to dnsext@ietf.org, the selected
   Expert shall post a message, explicitly accepting or rejecting the
   application, to IANA, dnsext@ietf.org, and the email address provided
   by the applicant. If the Expert does not post such a message, the
   application shall be considered rejected but may be re-submitted to
   IANA.

The last sentence: is "rejection by silence" a good idea? Has this worked well
in the past?

2) Excuse my ignorance, but what is the relationship between 2 mailing lists:

3.1.1. DNS RRTYPE Allocation Policy

   No less than three weeks and no more than six weeks after a completed
   template has been formally posted to dnsext@ietf.org, the selected
   Expert shall post a message, explicitly accepting or rejecting the
   application, to IANA, dnsext@ietf.org, and the email address provided
   by the applicant.

5. IANA Considerations

   This document consists entirely of DNS IANA Considerations.

   IANA shall establish a process for accepting Annex A templates,
   selecting an Expert from those appointed to review such template form
   applications, and archive and make available all approved RRTYPE
   allocation templates. It is the duty of the applicant to post the
   formal application template to the dns-rrtype-applications@ietf.org
   mailing list. See Section 3.1 and Annex A for more details.

Is a request always posted to dns-rrtype-applications@ietf.org and then to
dnsext@ietf.org?
If the answer is yes, why have 2 mailing lists?
    
  




draft-ietf-avt-srtp-big-aes


  
    
    
  1. Russ Housley: Discuss [2011-01-02]:
    
    
        
  The Gen-ART Review by Richard Barnes on 10-Dec-2010 raises a question
  that deserves a response.  I have not see a response to the question.
  >
  > The Suite B specifications require the use of SHA-256 and SHA-384 as
  > hash functions for SECRET and TOP SECRET, respectively.  Given that
  > Suite B compatibility is listed as an objective of this document, it
  > seems like there should be a cryptosuite that would use Suite B hash
  > algorithms as well as encryption algorithms. 
    
    
    
  2. Russ Housley: Comment [2011-01-02]:
    
    
      Please consider the nit and editorial comments from the Gen-ART Review
  by Richard Barnes on 10-Dec-2010:
  >
  > [Section3] In the first sentence, should "AES_CM PRF" be changed
  > to "AES_CM_PRF"?
  >
  > [Section3.1] Do you want to say explicitly that stronger KDFs MAY
  > be used?  That you could use the AES_256_CM KDF with AES_192_CM as
  > the bulk encryption algorithm, or use either 192 or 256 with 128?
    
    
  3. Alexey Melnikov: Comment [2010-12-24]:
    
    
    3.1.  Usage Requirements

   When AES_192_CM is used for encryption, AES_192_CM SHOULD be used as

I think the 2nd AES_192_CM should be AES_192_CM_PRF

   the key derivation function, and AES_128_CM MUST NOT be used as the

s/AES_128_CM/AES_128_CM_PRF ?

   key derivation function.

   When AES_256_CM is used for encryption, AES_256_CM SHOULD be used as
   the key derivation function.  Both AES_128_CM and AES_192_CM MUST NOT
   be used as the key derivation function.

Same comments as above.

    
    
  4. Tim Polk: Comment [2011-01-04]:
    
    
    Please note Hilarie Orman's secdir review.

(1) In particular, she notes:

The block counter "b_c" is two octets, but the "default key lifetime"
is 2^31.  Is this perhaps the "maximum" key lifetime?  Should
implementors introduce an internal counter to keep track of the
history of key usage (across sessions?)?  Perhaps earlier documents
explain this?

Should implementers use the rollover counter (ROC) from RFC 3711
in combination with b_c, or is there another mechanism that the
authors had in mind?

(2)  You might consider moving the rationale to the front of the section
as an alternative to Hilarie's suggestions on section 3.1, 
    
    
  5. Sean Turner: Discuss [2011-01-05]:
    
    
        I don't think SHA-1 is part of any Suite B specifications.  Because of this,
it's unclear to me that you should hint that by implementing this RFC an
implementation would be considered Suite B compliant. 
    
    
    
  6. Sean Turner: Comment [2011-01-05]:
    
    
    #1) Support Russ' and Tim's discusses.

#2) Section 3: 

   In
   this note, the AES-192 counter mode PRF and AES-256 counter mode PRF
   are and are denoted as AES_192_CM_PRF and AES_256_CM_PRF
   respectively.

extra words "are and"?

#3) Section 3.1 (similar to Russ's 2nd comment): Should the rationale include a
MUST?  For example:

   The cryptographic strength of the key derivation function MUST
   meet or exceed the cryptographic strength of the encryption method.
    
  




draft-ietf-mpls-ldp-upstream


  
    
    
  1. Jari Arkko: Discuss [2010-12-02]:
    
    
        Section 5 should explain what the semantics of the second field of the Sub-TLVs
are. Presumably that has been defined in some earlier RFC that defined the
syntax for Sub-TLVs. A reference would suffice.

Reference to Section 4.2 for some behaviour needs to be changed as there
is no Section 4.2. 
    
    
    
  2. Jari Arkko: Comment [2010-12-02]:
    
    
    A few comments from Ari Keränen:

The format of the packet format figures is not consistent: in the 
section 5's sub-TLVs "type" is given with syntax "Type  = XX" whereas in 
rest of the figures it's "Name (code)".

The second field of sub-TLVs (length?) is not defined at all in the 
figures but just the value is given. Also the length seems to include 
the type and length of the TLV -- is that intentional? Especially since 
in the other TLVs do not seem to include type and length.

Also the sentence "The TLV value in the sub-TLV acts as the tunnel 
identifier" is strange. Do you mean "the value of the sub-TLV"?

    1. RSVP-TE P2MP LSP TLV. Type = 28 (To be assigned by IANA). Value of
    the TLV is as carried in the RSVP-TE P2MP LSP SESSION Object
    [RFC4875].

The second sentence above is a bit confusing. Perhaps removing the "as 
carried in" part from the sentence and changing "value of the TLV" into 
"value of the sub-TLV" would help, if you mean that the whole object is 
in the value of the sub-TLV.

It's also somewhat confusing that with RSVP-TE P2MP LSP TLV there are 
Type and Length in the figure and with LDP P2MP LSP TLV there aren't.

The format of the 3rd and 4th sub-TLV seems underspecified. For example, 
how do you encode a "<Source Address, Multicast Group Address> tuple" in 
a sub-TLV?

6. LDP Point-to-Multipoint LSPs on a LAN

    Processing
    of the Label Request and Label Mapping messages for LDP upstream-
    assigned labels is as described in section 4.2.

Section 4.2. does not exist.

    2. The following hash is performed: H = (Sum Opaque value) modulo N,
    where N is the number of candidate upstream LSRs. Opaque value is
    defined in [MLDP] and comprises the P2MP LSP identifier.

What does the "Sum" in the hash equation mean? I would assume it's sum 
over all opaque values if there is more than one, but it's not really 
clear from the context. Also, how do you convert the opaque value(s) 
into number(s)?
    
    
  3. Stewart Bryant: Comment [2010-12-02]:
    
    
    
    
  4. Adrian Farrel: Comment [2010-12-02]:
    
    
    Gen Art review comments from Avshalom Houri

Summary: The document is ready for a Standard Track RFC.

Major issues: None
Minor issues: None

Nits/editorial comments:

One or more occurrences in the document
a LDP -> an LDP
a LSR -> an LSR
a MPLS -> an MPLS

Line 540
  [MLDP] describe how to setup P2MP LSPs using LDP. On a LAN the
->    [MLDP] describes how to setup P2MP LSPs using LDP. On a LAN the

Line 572
  Ru on receiving this message sends back a Label Mapping message to Rd
->    On receiving this message, Ru sends back a Label Mapping message to Rd

    
    
  5. David Harrington: Comment [2010-11-30]:
    
    
    SECTION 3: s/MUST be carried only LDP initialization messages/MUST be carried
only in LDP initialization messages/
    
    
  6. Russ Housley: Comment [2010-11-28]:
    
    
      The Gen-ART Review by Avshalom Houri on 13-Oct-2010 includes some
  editorial suggestions.  Please consider them.
    
    
  7. Sean Turner: Comment [2010-11-30]:
    
    
    Section 4: Shouldn't the two "optional"s be "OPTIONAL"?  They're indicating
support requirements.
    
  




draft-cdmi-mediatypes


  
    
    
  1. Adrian Farrel: Comment [2011-01-05]:
    
    
    Support Alexey's Discuss wrt the reference to 4627 and the potential
positioning of this document as Informational in which case I don't
think the minimal usage of 2119 language would suffer from being
changed to lower case, since it seems to be referenced from another
specification.
    
    
  2. Alexey Melnikov: Discuss [2010-12-21]:
    
    
        [Updated as per -06]

DISCUSS DISCUSS (something that I want to discuss with IESG, no action from the
author required):

RFC 4627 is a Normative reference, so this is a DOWNREF. If the document is
changed to Informational, the issue will go away. 
    
    
    
  3. Alexey Melnikov: Comment [2010-12-21]:
    
    
    
    
  4. Sean Turner: Discuss [2011-01-05]:
    
    
        updated to remove #3

#1) Sec 3.1: The implementations are free to store the data in
   any form they choose, but the application/cdmi-object SHOULD be
   represented in the CDMI interface as defined in section 8 of the CDMI
   specification.

Seems like there's a normative reference missing to the CDMI spec.

#2) Sec 3.2: The implementations are free to represent the
   container in any form they choose, but the application/cdmi-container
   SHOULD be represented in the CDMI interface as defined in section 9
   of the CDMI specification.

Seems like there's a normative reference missing to the CDMI spec. 
    
    
    
  5. Sean Turner: Comment [2011-01-05]:
    
    
    From Sec 3.2: ... includes standardized and optional metadata.

There can be standardized optional metadata - no?  Is this "required and
optional meadata"?
    
  




draft-melnikov-mailserver-uri-to-historic


  
    
    
  1. Sean Turner: Comment [2011-01-05]:
    
    
    Should "Updates: 1738 (once approved)" appear on the 1st page?
    
  




draft-kucherawy-authres-vbr


  
    

  1.  (none)
  




draft-ietf-mpls-tp-oam-framework


  
    
    
  1. Stewart Bryant: Discuss [2011-01-05]:
    
    
        I am concerned about this text:

Protection Switching: default transmission period is 3.33ms (i.e. transmission
rate of 300 packets/second).

Firstly the the requirement in RFC5654 only specifies the total time to detect
and to act as 50ms and how the system partitions this time should be a local
matter.

Secondly there are some applications of MPLS-TP that may not need this high peed
detection, and it is unreasonable to burden them with the need to implement this
high speed detection mechanism. 
    
    
    
  2. Adrian Farrel: Comment [2010-12-31]:
    
    
    Three Directorate reviews have been addressed, but a few non-blocking comments
remain that should be addressed to improve the document before it is published
as an RFC:

SecDir - vincent.roca@inrialpes.fr

> However there's a (naive) question which you didn't answer: is it
> realistic to assume the physical network can be secured? Are there
> known weaknesses in the MPLS infrastructure? Nothing is said in
> the I-D.
>
> Another point (from -10). It is said:
>
>         However
>         it should be observed that the combination of the need for
>         timeliness of OAM transaction exchange and all permutations of
>         unique MEP to MEP, MEP to MIP, and intermediate system
>         originated transactions mitigates against the practical
>         establishment and maintenance of a large number of security
>         associations per MEG either in advance or as required.
>
> The reasons mentioned here to justify nothing is done is critical.
> Only two reasons are listed: timeliness and combinatorial motivations.
> In your answer you also mention the high transmission frequency of
> heartbeats. This is not mentioned. Something else?

GenArt - david.black@emc.com

> The authors have addressed most of the items noted in the Gen-ART review
> of
the -09 version, but there is one item that could still use some attention.  
>
From the original review:
>
>       [D] The security considerations section
should include specific mention
>       of injection of LKI request OAM packets
as a vector for a denial-of-service
>       attack (this is an obvious way for a
man-in-the-middle to quickly cause
>       serious havoc).  That would be a good
specific example to add to the end
>       of the current security
considerations paragraph that requires the network
>       to be physically
secure against man-in-the-middle attacks.
>
> This has not been done.  While the
security considerations section does
> cover the countermeasures necessary to
prevent this attack, I prefer security
> considerations sections that include
examples of things that can go badly
> wrong when implementers don't pay
attention when the examples are simple.
> That preference is a matter of
style/taste that I'll leave to the responsible AD's
> judgment

RtgDir - thomas.morin@orange-ftgroup.com

> I replied to Dave Allan that my current 
> feeling, after going through today's revision of the OAM framework 
> document, is that the comments I made are only partially addressed.

    
    
  3. Russ Housley: Comment [2011-01-02]:
    
    
      The Gen-ART Review by David Black lead to some document updates.
  However, one comment was not addressed.  Please consider updates
  to the security considerations section.  David said:
  >
  > [D] The security considerations section should include specific
  > mention of injection of LKI request OAM packets as a vector for a
  > denial-of-service attack (this is an obvious way for a man-in-the-
  > middle to quickly cause serious havoc).  That would be a good
  > specific example to add to the end of the current security
  > considerations paragraph that requires the network to be
  > physically secure against man-in-the-middle attacks.
  >
  While the security considerations section does cover the
  countermeasures necessary to prevent this attack, it seems like
  a good idea to document something that can go badly wrong when
  implementers do not pay attention.

    
  




draft-ietf-sieve-autoreply


  
    
    
  1. Stewart Bryant: Comment [2011-01-05]:
    
    
    This is somewhat unusual language to find in a RFC to be:

Consider whether it's truly important to tell people that
   you'll read their mail in an hour or so, or whether that can just be
   taken as how email works.  There are times when this makes sense, but
   let's not use it to exacerbate information overload.

    
    
  2. Adrian Farrel: Comment [2011-01-05]:
    
    
    Your homily to users in Section 1 is a good message, but I think it is
in the wrong document or targeted at the wrong audience. *This* document
would, I think, mainly apply to application developers since it is an
unusual user who writes their own Seive scripts. So the warning is 
better rephrased to advise application developers to be careful to not
provide too many knobs and whistles, or to make sure that their
implementations warn users to exercise appropriate caution.

I would also note in this context that presence information might be a
good tool to reduce the amount of autoresponses generated thus 
mitigating the sad effect of auto-responder functionality.

---

Section 4

   Despite the "intelligence", too, errors in scripts can result in
   private information getting to senders inappropriately.

Is "too," superfluous? I find it hard to parse.

    
    
  3. Robert Sparks: Comment [2011-01-05]:
    
    
    Example 2 in section 3 does what the last paragraph in section 1 says is a bad
idea. Please consider reconciling these two parts of the document.
    
  




draft-ietf-ecrit-lost-servicelistboundary


  
    
    
  1. Tim Polk: Comment [2011-01-06]:
    
    
    My apologies before climbing onto the editorial soapbox, but...

This document *defines* a Service List Boundary extension, not *proposes* a
Service List Boundary.  Perhaps the
-00 draft was a proposal, but this one is a
technical specification.

I suggest a minor edit in the Abstract to clarify the document scope.
    
    
  2. Sean Turner: Discuss [2011-01-05]:
    
    
        Section 3.2, 2nd to last paragraph: Add a normative reference to BCP 106/RFC
4086 for randomness requirements (should have been in RFC 5222).

[RFC4086]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,  "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. 
    
    
    
  3. Sean Turner: Comment [2011-01-05]:
    
    
    Sec 3.3: r/is optional and/is OPTIONAL and
    
  




draft-ietf-ipfix-anon


  
    
    
  1. Stewart Bryant: Discuss [2010-12-13]:
    
    
        In the security section you say

"When releasing anonymised data, publishers need to ensure that data that could
be used in deanonymisation is not leaked through the  export protocol;
guidelines for addressing this risk are provided in Section 7.2."

However it's not just protocol action that needs to be secured, the anonymising
system (i.e. h/w, s/w, operational procedures) itself needs to be secure and is
a system that will be the prime focus of any attack to recover the base data. 
    
    
    
  2. Stewart Bryant: Comment [2010-12-13]:
    
    
     "Binning can be seen as a special case of precision degradation; the operation
is identical, except for in precision degradation the counter ranges are
uniform, and in binning they need not be.  For  example, a common counter
binning scheme for packet counters could be to bin values 1-2 together, and
3-infinity together, thereby separating potentially completely-opened TCP
connections from unopened ones.

I am not a TCP specialist, so I do not understand the leap from the simple text
"to bin values 1-2 together, and 3-infinity together" to the TCP connection
example, however I suspect that grouping and the protocol state are in the wrong
order.
Either way, a few more words of a different example would add clarity.
    
    
  3. Adrian Farrel: Comment [2011-01-03]:
    
    
    Thanks for bringing this work forward as Experimental. While it is not a
requirement, I think it is helpful to the community if Experimental documents
give some indication of the scope of the experiment. Where will these protocol
extensions be used? How will they be kept separate from the wider IPFIX
deployment? How will the success or failure of the experiment be judged? What is
the plan, assuming success? (The latter is usually: return to update this
document based on experience, and move it to the standards track.) Note that
some of the answers were presented in the proto writeup.

I see questions from IANA in the data tracker that appear to have been answered
by email during IETF last call. It would be good to get these answers transfered
into the document or added as an RFC Editor Note. Additionally, the registry
referenced is split into two ranges, but there is no advice to IANA about which
range should be used.
    
    
  4. Alexey Melnikov: Comment [2010-12-26]:
    
    
    5.1.  Stability

   If no information about stability is available, users of anonymised
   data MAY assume that the techniques used are stable across the entire
   dataset, but unstable across datasets.

This doesn't look like an implementation choice, so I think MAY is wrong here.

6.1.  Anonymisation Records and the Anonymisation Options Template

   First, reliability is important: an
   Exporting Process SHOULD export Anonymisation Records after the
   Templates they describe have been exported, and SHOULD export
   anonymisation records reliably.

What is the exact meaning of the last SHOULD?

TLS and DTLS need Informational References.

    
  




draft-ietf-v6ops-tunnel-security-concerns


  
    
    
  1. Jari Arkko: Comment [2011-01-05]:
    
    
    Section 6.1.1 attack does not appear to be any worse than the assumptions
required for this attack to be possible. If you can spoof the victim's
DNS, you can hijack the victim's communications, tunnels or no tunnels.

In this light the recommendation to prefer IPv4 over tunneled IPv6
is odd. Also, its not clear that whoever is selecting which addresses
to use is aware of whether tunneling is being done or not (host vs.
router, for instance).

(This recommendation may be good for other reasons, of course.)
    
    
  2. Stewart Bryant: Comment [2011-01-05]:
    
    
    There are a lot of tunnel mechanisms are being deployed simply so that end users
can work around the fact that they do not have enough IP addresses by creating a
private overlay network.

The document seems to miss the opportunity to say that by deploying IPv6 the
need for many of these tunnels can be removed.
    
    
  3. Adrian Farrel: Discuss [2011-01-05]:
    
    
        I think this is a worthwhile and useful document

I *think* that the scope of this document is intended to be "security
considerations for the use of IP tunnels in IPv6 migration scenarios."

It looks like the document goes on mainly to consider the issues that
arise in such situations, although the title and abstract etc. are 
not clear on this limitation, and some places in the text seem to 
open the discussion up more general tunneling applications.

While v6ops is a good home for a document with limited scope, it
worries me that
the more general discussion is restricted to that                
working group.
The shepherd write-up declares "The document has been
quite extensively
socialized", without explaining where this
socialization took place.

In short, scoped so widely (i.e., not limited to the applicability of
tunnels to v6 migration strategies) this document appears to be out of
scope for the v6ops working group.

There would appear to be two solutions:
1. Add a few small changes to make clear
that the scope is limited to                          
   v6 migration (or maybe
to v6 use of tunnels)
2. Find the right review forums within the IETF to ensure
proper
   breadth of review (opsec, WGs responsible for the main tunneling
protocols, ...)

Note that I do not consider that the IETF last call on a document with
a file name starting "draft-ietf-v6ops-..." guarantees broad enough
review.

---

I would like to see a little more clarity on the meaning of "IP 
tunnels". I think you are trying to discuss situations where an IP
packet can contain, through some form of encapsulation, another IP
packet. It would be really nice to make this crystal clear.
 
    
    
    
  4. Adrian Farrel: Comment [2011-01-05]:
    
    
    Section 2.1.1

   This reduces defense in depth
   and may cause security gaps.

I can't parse this :-( Do you mean...

This reduces the depth of security available, and may cause security 
gaps.

---

Is it right that Section 2.3 is limited only to source routing? Isn't
it the case that tunneling can be used to inject any IP option into a
network and cause trouble?

    
    
  5. Russ Housley: Discuss [2011-01-05]:
    
    
        
  The Gen-ART Review by Joel Halpern on 28-Dec-2010 raises a question
  that has not been answered.  I think that a response is needed.

  Joel says:
  > It is unclear in the document what assumptions section 3.1 makes
  > about the relationship between supported tunnels and checked
  > embedded addresses.  Is there an assumption that the router only has
  > to check for addresses in the format and prefix it supports?  
    
    
    
  6. Tim Polk: Comment [2011-01-05]:
    
    
    This is a useful document and I support its publication.  I believe this could
be a better and more useful document
if the authors could address a few issues
before publication:

Issue #1

I think the intended scope of this document is not consistently stated
(explicitly and implicitly):
(1) the document title is "Tunneling Security
Concerns";
(2) the abstract states "The primary intent of this document is to
raise the awareness level ..."
(3) the introduction states "This document
discusses security concerns ... and includes recommendations
where relevant."
(4) the introduction also states "The primary intent is to help improve security
deployments ..."

Based on the title and the abstract, I was expecting a problem statement draft.
The first bit I quoted from the
intro implies that this is a problem statement
draft, and the recommendations are an afterthought.  The last bit
says the
recommendations are the whole point of the document.

IMHO, the recommendations are the most important contribution made by this
document.  I would like to see
edits in the abstract and intro to clearly state
that.  It may be too late to address the title, but "Mitigating
Tunneling
Security Concerns" would also clearly demonstrate that scope.

Issue #2

The document presents a collection of network architecture and network
administration recommendations, 
but readers might really benefit from some
summary recommendations.  I was hoping for a section that 
moved the document
from a laundry list to a methodology of sorts that worked through the
architectural 
decisions first, then moved on to mitigating the specific
problems remaining after the architectural decisions 
are made.  For example, it
seems that architecting your network so that tunnels don't cross security
boundaries is a key first step.  If you don't follow that recommendation,
everything else is harder, isn't it?

Issue #3

The introduction closes with "The intended audience ... includes network
administrators and future protocol 
developers."  I had a hard time
understanding what the lessons are for future protocol developers.

Perhaps a paragraph or two summarizing recommendations for protocol developers
would be useful here.

Issue #3

Section 5.1 is conspicuous in its structure: it includes a "5.1.1 Problem", but
omits the expected
"5.1.2 Discussion" and "5.1.3 Recommendations".  Is it true
that there is nothing to say here?
    
  




draft-ietf-v6ops-tunnel-loops


  
    
    
  1. Jari Arkko: Discuss [2011-01-05]:
    
    
        This is a good document and should be published.

However, I have one concern about the described neighbor cache check
solution. First off, the document is incorrect that hosts must
continuously send RSes to keep their address configuration up to date.
More importantly, the neighbor cache is just that, a cache. A better
solution would be to probe for a neighbor and only drop the packet if
there was no response. This is already described in the document.
My suggestion would be to delete the neighbor cache check solution
entirely from the document.

I think it would also be great if this document made a stronger statement
about the IMO most important use case for automatic tunnels: broadband
home networks. These are very simple networks with just one exit router
and it would be important to highlight the significance (or lack
thereof) of the attack in this case & point to the recommended solution. 
    
    
    
  2. Jari Arkko: Comment [2011-01-05]:
    
    
    
    
  3. Stewart Bryant: Discuss [2011-01-05]:
    
    
        "based on protocol-41 encapsulation" needs a reference

I have tried to read section 2 a number of times and I do not understand the
loop.

I do not understand what "The attacker exploits the fact that R2 does not know
that R1 does not take part of T2" means. 
    
    
    
  4. Stewart Bryant: Comment [2011-01-05]:
    
    
    
    
  5. Adrian Farrel: Discuss [2011-01-06]:
    
    
        Having had some time to go back and re-read this document I am now not
comfortable.

1. In Figure 1, why is R2 advertising reachability to an IPv6 at all? It has
only one point of attachment to the v6
   network. I think you are trying to say
that there is a virtual link (v6 capable) running over the v4 network. Isn't
that link simply part of the v6 network?

2. Why is R2 advertising reachability to an address that is not reachable
through it? You say:
      "...destined to a fictitious end point that appears
to be reached via T2..." 
    
    
    
  6. Russ Housley: Discuss [2011-01-05]:
    
    
        
  The Gen-ART Review by Joel Halpern on 28-Dec-2010 raises a question
  that has not been answered.  I think that a response is needed.

  Joel says:
  > It is unclear in the document what assumptions section 3.1 makes
  > about the relationship between supported tunnels and checked
  > embedded addresses.  Is there an assumption that the router only has
  > to check for addresses in the format and prefix it supports? 
  The Gen-ART Review by Joel Halpern on 28-Dec-2010 raises a question
  that has not been answered.  I think that a response is needed. 
    
    
    
  7. Tim Polk: Comment [2011-01-05]:
    
    
    Please clarify that the document's scope does not address the Teredo attacks
specified in the USENIX paper.
    
    
  8. Peter Saint-Andre: Comment [2011-01-05]:
    
    
    Given that the document describes an attack that can result in denial of
service, a reference to RFC 4732 would be appropriate.
    
  




draft-ietf-l2vpn-vpls-bridge-interop


  
    
    
  1. Adrian Farrel: Comment [2010-03-09]:
    
    
    The new revision addresses a number of the points I raised in my review of
11-Apr-2009. I will clear my Discuss and record the three unaddressed points
here.

Section 2
Maybe this could use a figure. There is a lot of information conveyed
and perhaps a figure of a VPLS showing the network and instance would
help.
---
Figure 2+
I can sort of look at figures 1 and 2 and see a more complete picture
of the PE model with PWs on one side and CEs on another. I think that
in figure 2 it would help to label the ACs (C-VLANs), but it would also
be helpful to show CE attachment when the ACs are not VLANs.
Is there some way to give this more comprehensive picture?
---
Section 9
To me, this section feels very light. I am not a security expert,
but the fact that you are extending an architectural model should
give rise to new security issues for consideration.
    
    
  2. Sam Hartman: Discuss [2007-12-19]:
    
    
        Security directorate comments by Phillip Hallam-baker have not been
addressed.  These comments were not submitted as public last call
comments.  However they raise serious readability and interpretability
questions of the document.  I do know that some of Phil's comments are
wrong because I've read some of the VPLS base specs.  So, I tried to
make an independent review of the document in order to determine if
there was anything blocking.  However I failed to be able to
comprehend the document well enough to follow it.  I gave up in the
middle of section 3 with very little understanding of where the
document was going and low confidence that the description of VPLS in
this document matched my understanding from the base VPLS specs.

To make this discuss actionable, I recommend that the authors work
with reviewers outside their working group and improve the document to
a point where someone who has not worked extensively in the L2VPN
working group but who has read the VPLS documents can easily follow
the document and can accurately describe what is going on. 
    
    
    
  3. Russ Housley: Comment [2010-03-10]:
    
    
    
    
  4. David Ward: Discuss [2007-12-20]:
    
    
        Unfort, I find the doc very, very terse and almost unable to understand the
points that are being made and the suggested recommendations. In addition I find
it odd that there are cases where interop needs to be "worked out." It suggests
that an interop procedure or recommendation is incomplete and thus, the doc is
premature. 
    
    
  




draft-loreto-http-bidirectional


  
    
    
  1. Sean Turner: Comment [2011-01-05]:
    
    
    Sec 8: r/attacks.[RFC4732]./attacks [RFC4732].
    
  




draft-turner-md5-seccon-update


  
    
    
  1. Russ Housley: Comment [2011-01-05]:
    
    
      I think this documnet would be more useful to people trying to choose
  an algorithm if Section 2 were structured to present the conclusions
  at the beginning, and then provide the details in the susbsections.  I
  suggest:

   MD5 was published in 1992 as an Informational RFC.  Since that time,
   MD5 has been extensively studied and new cryptographic attacks have
   been discovered.  Message digest algorithms are designed to provide
   collision, pre-image, and second pre-image resistance.  In addition,
   message digest algorithms are used with a shared secret value for
   message authentication in HMAC, and in this context, some people may
   find the guidance for key lengths and algorithm strengths in
   [SP800-57] and [SP800-131] useful.

   MD5 is no longer acceptable where collision resistance is required
   such as digital signatures.  It is not urgent to stop using MD5 in
   other ways, such as HMAC-MD5; however, since MD5 must not be used for
   digital signatures, new protocol designs should not employ HMAC-MD5.
   Alternatives to HMAC-MD5 include HMAC-SHA256 [HMAC][HMAC-SHA256] and
   [AES-CMAC] when AES is more readily available than a hash function.
    
  




draft-turner-md2-to-historic


  
    
    
  1. Adrian Farrel: Comment [2011-01-04]:
    
    
    Comment transferred from my previous process Discuss.

I fully support knocking MD2 on the head. However, I am a little
inexperienced with the process of making an I-D Historic.

What happens to an standards track documents with references
(especially normative references) to 1319 as listed in Section 3?
Should they at least also be marked as "updated by" this draft?

Similarly, 1319 updates 1115. What happens to 1115 and its text
on MD2?
    
    
  2. Alexey Melnikov: Comment [2010-12-19]:
    
    
    Updates: 1319 (once approved)

 - why not Obsolete: 1319 ? This document is moving RFC 1319 to Historic.

3. Documents that Reference RFC 1319 

   MD2 has been specified in the following RFCs:

*Use* of MD2 has been specified ...

    
  




draft-turner-md4-to-historic


  
    
    
  1. Adrian Farrel: Comment [2011-01-05]:
    
    
    As with the MD2 document, I think it is worth listing the standards 
track documents shown in Section 3 as Updated in the document header.

It looks to me that you might also want to update some of the 
informational documents listed here.

The prime benefit is that those documents will be marked in the RFC
repository as having been updated by this document.

---

Abstract, etc.

Once published, this document should be more assertive. Thus:
OLD
This document recommends RFC 1320 be moved to Historic status.
NEW
This document moves RFC 1320 to Historic status.
END

etc.

---

4. Impact on Moving MD4 to Historic

s/on/of/

---

Section 4

   o MD4 was used in the Inter-Domain Routing Protocol (IDRP); each IDRP
     message carries a 16-octet hash that is computed by applying the
     MD-4 algorithm (RFC 1320) to the context of the message itself.
     Over time IDRP was replaced by BGP-4.

Need to add a refernce to 4271, and an indication that BGP-4 requires at
least MD-5. You could reference 2385, but that might be de trop.

---

Section 4

   o The three Microsoft RFCs, [RFC2433], [RFC2759], and [RFC4757], are

Do we need to describe these as "Microsoft RFCs"? 
How about: "The three RFCs describing Microsoft protocols"?
    
    
  2. Alexey Melnikov: Comment [2010-12-19]:
    
    
    The document header has:

   Updates: 1320 (once approved)

Why not "Obsoletes: 1320" ?

    
  




draft-irtf-mobopts-mpa-framework


  
    
    
  1. Ralph Droms: Comment [2011-01-06]:
    
    
    I strongly suggest that the following comments are addressed
before publication:

In section 7.3.1, a DHCP relay agent does not have the capability to
operate independently and perform a DHCP message exchange with a DHCP
server in anticipation of an eventual DHCP message exchange initiated
by a client.  The mecahnism described in this section would require
the definition of a new DHCP proxy function.

In the case of IPv6, it's probably required to forward the RA to the
mobile node regardless of the address assignment model, to
pre-configure the mobile node with all the requisite information about
prefixes, etc.

In section 7.3.3, there is a conflict with the DHCPv6 specification,
which requires that a DHCPv6 client send any messages to the DHCPv6
servers/relays multicast address, rather than unicast to a server. 

There may also be a problem with all of these methods using DHCP: how
does the CTN DHCP server know what address to assign to the client?

Other comments:

Perhaps a nit, but I was somewhat mislead by the title, " A Framework
of Media-Independent Pre-Authentication (MPA) for Inter-domain
Handover Optimization" to believe that I was going to read about a
protocol that focused on authentication and secure communication.  In
my opinion, this document describes a complete framework for
media-independent inter-domain handover optimization that goes beyond
authentication and security.

In Appendix A, wouldn't DAD be performed by the NAR rather than the
PAR?

From the Intro:

   In this document
   we discuss a framework to support terminal mobility that provides
   seamless handovers with low latency and low loss.

Are there other components to terminal mobility aside from MPA?

Section 1.2:

   A trade-off between one-way-delay and
   packet loss is desired based on the type of application.

Unclear to me - a trade-off should be available through tuning or
one-way-delay should be improved relative to packet loss?

Section 3: Define "inter-subnet handover"?

Section 6.1:

   MPA provides three basic procedures to provide this functionality.
   The first procedure is referred to as "pre-authentication", the
   second procedure is referred to as "pre-configuration", the
   combination of the third and fourth procedures are referred to as
   "secure proactive handover".

"three basic procedures" and "third and fourth procedures" is
confusing; where did that fourth procedure come from?

Section 6.1:

   Especially, the third procedure described above (i.e., binding update
   procedure)

Change "third procedure described above" to "step (iii) in the
previous paragraph" to avoid confusion with the use of "procedures in
the earlier paragraph in section 6.1.

Section 6.2:

   The authentication
   protocol MUST be able to derive a key between the mobile node and the
   authentication agent and SHOULD be able to provide mutual
   authentication.

Is "derive a key between ..." a term of art or can the requirement be
described more accurately as "establish a shared key between..."?

   The authentication protocol SHOULD be able to
   interact with a AAA protocol such as RADIUS and Diameter to carry
   authentication credentials to an appropriate authentication server in
   the AAA infrastructure.

Does the authentication protocol interact directly with the AAA
protocol, or does the interaction happen through the AA?

    
  




draft-templin-iron


  
    
    
  1. Jari Arkko: Comment [2010-12-16]:
    
    
    
    
  2. Stewart Bryant: Comment [2010-12-15]:
    
    
    I am surprise that the document contains no reference to LISP which is
operating broadly in this space.

=======

SRA is not a defined abbreviation.

=======

This needs a few words of clarification - presumably the "locator addresses" are
the addresses learned from the relay.

  After the Client receives an SRA message from the nearby Relay
   listing the locator addresses of nearby Servers, it sends SRS test
   messages to one or more of the locator addresses to elicit SRA
   messages.

=======
				   
If this Server fails, the Client will quickly select a new
   one which will automatically update the VPC overlay network mapping
   system with a new EP-to-Server mapping.

"quickly" is a non-specific metric

=======

[I-D.templin-intarea-seal] looks like it should be normative
[I-D.templin-intarea-vet]  looks like it should be normative

Although the RFCeditor may wish to overlook this if there is a concern that
these drafts will not be taken to completion.


    
    
  3. Ralph Droms: Comment [2010-12-16]:
    
    
    I have one suggestion about the content of the document.  I'd like to
see an analysis of how IRON actually "provide[s] scalable PI
addressing without changing the current BGP [RFC4271] routing system"
along with costs incurred by IRON.  How does hiding the EPA addresses
inside the IRON locator prefixes reduce the routes in the real
Internet core?  What is the cost in the routing tables maintained by
the relays?  How expensive is the anycast routing?  How does inter-VPC
routing work and how expensive is it?

The remainder of my COMMENTs are editorial.

In Section 6.1, I think I understand what this text is trying to
explain, but I don't think it's correct:

   It
   is therefore essential that the Client send the initial packets
   through its Server to avoid loss of SCMP messages that cannot
   traverse a NAT in the reverse direction.

Does this mean to explain that the Client sends packets through its
Server to establish NAT state so SCMP messages from the Server to the
Client can traverse the NAT?

In Section 6.2, this text uses "into the Internet" in a confusing way,
assuming I'm understanding the meaning of the text correctly:

   The Server then
   forwards the revised packet into the Internet via a default or more-
   specific route, where it will be directed to the closest Relay within
   the destination VPC overlay network.

Everywhere else in this section "into the Internet" is used to
describe the forwarding of a decapsulated datagram, after the outer
header with locator addresses have been removed, into the (non-IRON)
Internet.  In the text quoted aboce, "into the Internet" seems to mean
forwarding of an encapsulated datagram, which is described elsewhere
in this section as simply "forwards" or "sends".  I suggest rewriting,
for consistency, as

   The Server then
   forwards to the closest Relay within
   the destination VPC overlay network.

In Figure 6, why would the anycast datagram from Server(A) be
delivered to Relay(B) rather than Relay(A) (which presumably would be
in the routing fabric for ISP A)?  Does it matter? 

Once Server(B) receives the datagram to be forwarded to Client(B), is
it possible for Server(B) to send a redirect to Client(A) so Client(A)
can send traffic directly to Client(B)?

Stylistic nit in section 6.4.1 (and elsewhere) - why start using the
verb "releases" instead of the previously used "forwards" or "sends"?
Seems like lots of unnecessary verbiage right after Figure 6; why not
something like "..., host A sends packets to host B through its EUN.
Client(A), as the defautl router for the EUN, receives the packets,
encapsulates them in the IRON encapsulation and forwards them to
Server(A). ..."  (etc.)  All the explanation of routing, etc., seems
redundant at this point.

Sorry, can't help myself; in section 6.6:

   The IRON approach to
   renumbering avoidance therefore depends on VPCs conducting ethical
   business practices and offering reasonable rates.

... as opposed to the unethical business practices and unreasonably
high rates from those evil, greedy ISPs.

Seriously, has the renumbering problem simply been moved from the ISPs
to the VPCs?

    
    
  4. Adrian Farrel: Comment [2010-12-16]:
    
    
    Thank you for bringing this work forward as Experimental and so increasing the
documentation and discussion of potential solutions.

I feel that it would be helpful if the document contained a pointer to draft-
irtf-rrg-recommendation so that the other ideas in the field can be easily found
and compared.