Re: [ietf-privacy] New Webiquette RFC
The questions you refer to are not new. The same issues (IPR policy conformance and hidden agendas) have been raised with respect to the affiliations of ‘consultants’ who are hired by clients who wish to remain anonymous. AFAICT, the IETF has never required that consultants divulge their clients, even to the nomcom. Anonymous participation takes this trend one step further. The W3C does not allow anonymous participation due to IPR concerns, but their IPR policy is also significantly different, since W3C is membership-based (and not particularly friendly to ‘consultants’ or small businesses). We might decide that this anonymous participation is one step too far, but my take is that IETF crossed an important line long ago. On Sun, Apr 17, 2022 at 12:15 Christian Huitema wrote: > This submission raises an interesting question for the IETF: how to > treat anonymous (or pseudonymous) submissions? > > On one hand, there are lots of classic reasons for hiding behind a > pseudonym when participating in public discussions. On the other hand, > the IETF has to be protected against intellectual property issues and > against sabotage by external groups. > > Before submissions are accepted for publication, their authors have to > disclose whether they, or their employer, own intellectual property > rights on the technologies described in the draft. Failure to disclose > would influence the prosecution of intellectual property disputes that > might arise when third parties implement the technology. This provides > some degree of protection to implementers. But when the submission > cannot be traced to a specific company, these protections disappear, and > we might have a problem. So this is one source of tension between > standards and anonymity. > > The other source of tension is the risk of sabotage. Various groups have > tried to sabotage the standard process in the past, for example to delay > the deployment of encryption, or to introduce exploitable bugs in > security standards -- some of these tactics were exposed in the Snowden > revelations. Anonymous participation could allow these groups to perform > such sabotage in untraceable ways, which is obviously not desirable. > > I think this issue of anonymous participation is worth discussing. > > -- Christian Huitema > > > On 4/17/2022 11:35 AM, kate_9023+...@systemli.org wrote: > > Dear all, > > > > I'm quite new at creating RFCs. I have recently submitted a draft for > > a new webiquette and I am still searching a group which will take care > > of it. It would fit into privacy as this new webiquette is dealing > > with new internet technology such as deepfakes, sharing photos of 3rd > > parties and so on and also deleting old information on a regular basis > > good behavior. It's also quite short with only 9 pages and also covers > > cancel culture and mobbing. I think a document like this is needed and > > important. Anyone here who'd like to take care or helping me making an > > RFC out of it? Or guide me in the right direction? > > > > The draft can be found here: > > > https://www.ietf.org/archive/id/draft-rfcxml-general-the-new-webiquette-00.txt > > > > Best Regards, > > > > Kate > > > > ___ > > ietf-privacy mailing list > > ietf-privacy@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-privacy > > ___ > ietf-privacy mailing list > ietf-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-privacy > ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Ted said: If there are problems with the document, part of the adoption process should be the identification of those flaws and an agreement to address them. So bringing up those flaws during the adoption process is crucial to the process. [BA] I would agree that there should be an agreement to address the flaws prior to adoption, but in my experience that is often not enough. If the flaws are major enough, sometimes the fixes end up being non-trivial, or even turn into an argument about the feasibility of fixing them at all. More than once I have seen this turn into a war of attribution between the editors and the WG, where the editors assert that because the WG adopted the document, they effectively endorsed the approach, and the WG asserting that they never would have adopted the document with the knowledge that the flaws would remain. To prevent this kind of argument down the line, if there is a major flaw in a document, I now believe it is best to insist that it be addressed *prior* to adoption. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: charging remote participants
Hadriel said: I agree. My proposal for how/what/where to get more revenue (and not from remote participants) was only in case we actually need it to pay for enhancing remote participation. It's not clear we have such a need any time soon, but I was only trying to provide an alternative model to charging remote participants. [BA] It appears quite possible to significantly enhance remote participation in the IETF with minimal funding. The load pattern of the IETF (heavy during physical meetings, much lower in between), accommodates itself well to the use of cloud services. - making it possible for the IETF to avoid having to purchase hardware to handle the peak load, instead being able to scale up/down capacity as needed. From what I can tell, the breadth and depth of services obtainable for a few thousand $/year of expenditure is pretty impressive. As an example, the cost of putting up an audio conferencing service supporting Opus (usable by any WG that needed it for virtual or design team meetings) would only be a few hundred $/year, excluding the cost of PSTN connectivity. Even small scale video conferencing doesn't appear to be very expensive. If there are only a few video participants, it is possible to mix on the peer, and for centralized conferencing, a small instance virtual machine (e.g. one core, 1 GB RAM) appears capable of handling half a dozen participants using software such as jitsi-videobridge, without breaking a sweat. So, a thousand $/year might cover it (assuming that we aren't attempting to provide telepresence-quality video). Even if money were *really* tight, we could easily obtain donations to cover costs in that ballpark. IMHO, the hard problems relate to engineering, not finance. In particular, the challenge is to provide a system with low administrative overhead and good ease-of-use, integrated with IETF processes. To advance the state of the art, IAOC RPS committee (see http://iaoc.ietf.org/committees.html#rps) will continue to sponsor ongoing experiments at meetings, as well as pilot tests.
RE: Internationalization and draft-ietf-abfab-eapapplicability
The question is: this document is about an applicability update, not a change of the on-the-wire behaviour of EAP. [BA] That's right -- which is why I see no need for the applicability update to depend on RFC 4282bis. It just needs to discuss the applicability aspects. If we were to try and apply a proper fix to RFC3748 to make Identities UTF-8 everywhere [BA] We are just talking about core EAP and RADIUS RFCs here. Internationalization of method-specific identities (and passwords) is defined by the EAP method specifications, so the Identities UTF-8 everywhere is a much broader topic (and one which I'd argue is not relevant to an ABFAB applicability statement). The next best solution then would be to require that only ABFAB-using EAP supplicants are required to use UTF-8 (and possibly also require a normalisation). [BA] I would agree with a UTF-8 requirement for EAP-Response/Identities. That is necessary in practice, because RFC 3579 requires that the EAP-Response/Identity be copied into the RADIUS User-Name attribute, and RFC 2865 Section 5.1 states that: The format of the username MAY be one of several forms: text Consisting only of UTF-8 encoded 10646 [7] characters. network access identifier A Network Access Identifier as described in RFC 2486 [8]. distinguished name A name in ASN.1 form used in Public Key authentication systems. Internationalization of method-specific identities and passwords are up to the methods, so the document can just point this out and say see applicable RFCs. Personally, I don't think that the ABFAB applicability statement has to mandate normalization in NAIs - that would make it depend on RFC 4282bis, and that doesn't seem necessary to me. Instead, it can just make the reader aware of RFC 4282bis and say that uses need to conform to internationalization requirements which are a work in progress. That would indeed solve ABFAB's i18n'ed use of EAP, but not everybody else's. That's a bit selfish, but it would certainly be better than nothing. I wonder what the other authors think about nailing down a UTF-8/NFC-normalised Identity into the draft. Greetings, Stefan Winter Since RFC 3579 Section 2.1 specifies that the EAP-Response/Identity is copied into the RADIUS User-Name Attribute: In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request. Therefore for use with EAP, the User-Name Attribute also inherits a UTF-8 encoding requirement, restricting the potential encodings permitted by RFC 2865 Section 5.1 (User-Name Attribute): The format of the username MAY be one of several forms: text Consisting only of UTF-8 encoded 10646 [7] characters. network access identifier A Network Access Identifier as described in RFC 2486 [8]. distinguished name A name in ASN.1 form used in Public Key authentication systems. -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
RE: Internationalization and draft-ietf-abfab-eapapplicability
Sam said: My recommendation is that we point out the issue. And say that strings used within a specific EAP method MUST follow the rules for that method. If AAA is used, strings used within AAA MUST follow the rules for the AAA protocol in use. We can add an informative citation to 4282bis as a snapshot of current thinking. [BA] That works for me. Stefan Pushing the requirement down to the EAP method won't work Stefan IMHO. Take as example EAP-TTLS in RFC5281. A full-text Stefan search for UTF in it yields 0 hits; and a look at section Stefan 7.3 (EAP Identity Information) does not speak of any Stefan encodings. [BA] You are right that a number of method specifications are deficient in the internationalization area. However, I don't think that's an issue that an ABFAB applicability statement can solve. Sam's proposed approach seems like the only feasible one. Sam said: Nah, you'd just be living in a different hell if you'd been explicit in the EAP spec. I know: other parts of the IETF are in that hell. The protocols are clear and everything is fine until you realize that the backend authentication systems you're dealing with are using a totally different set of rules than the protocols. That hell sucks too. [BA] I totally agree. Some EAP methods are going to care a lot. They'll care more about passwords than they will usernames. Usernames are complex because they can be carried in AAA, EAP identity and within a method. [BA] Yes, but at least the method-specific identities and passwords are opaque to the EAP core implementation and the AAA protocol. we can write a guidance document for non-standards-track methods that are ambiguous giving the best advice we can. We can give good requirements in standards-track methods. TEAP is in last-call now; I'm fairly sure it gets this reasonably OK, but we should probably check that. However, none of the above matters for this document. [BA] Exactly. It's just an applicability statement, not a prescription for world peace :)
RE: Internationalization and draft-ietf-abfab-eapapplicability
[BA] Exactly. It's just an applicability statement, not a prescription for world peace :) Sure: we need more than an applicability statement update to achieve peace in the EAP world. But if an applicability statement update is all we can work with, we could try and do our best in that one. [BA] The goal of an applicability statement to provide guidance as to the applicability of a particular standard. Using a marine analogy, it can say it is ok to take a boat of this size out into the ocean, but it doesn't have to provide a detailed map of every harbor. So it seems like there is a need to address application-layer protocols that don't encode their identities in UTF-8 over the wire today. Is EAP applicable to these protocols? If so, is there something they need to be aware of? Going beyond that is probably for other documents, not this one.
RE: Internationalization and draft-ietf-abfab-eapapplicability
Sam said: We don't get to place requirements on applications except to say what they need to do to use EAP. The protocol requirement for that is that applications using EAP need to know what character set they have so that EAP can convert the identity to UTF-8 and so that EAP methods can do any needed conversions. [BA] That sounds right.
Internationalization and draft-ietf-abfab-eapapplicability
After reading this document, I believe that this document omits discussion of an important aspect, which is internationalization. Since the contents of the EAP Identity and RADIUS User-Name attributes are specified to be encoded in UTF-8, application protocols that utilize encodings other than UTF-8 for user identities and passwords could have issues utilizing EAP (and RADIUS). Currently RFC 4282bis proposes that all EAP implementations normalize identities and passwords before utilizing them, and therefore application protocols that do not do this will be at variance with RFC 4282bis. IMHO the document needs to state what the internationalization requirements are for application-layer protocol use of EAP. There are potential workarounds, such as requiring that application protocols convert identities and passwords to UTF-8 prior to use of EAP, or modifying RFC 4282bis so as to require normalization in RADIUS proxies or servers. However, without fixes being applied and/or changes to RFC 4282bis, use of EAP by applications may not be compatible with either existing specifications or implementations. Background EAP and protocols that carry it (e.g. RADIUS) assume that the EAP-Response/Identity is encoded in UTF-8. For example, RFC 3748 Section 1.2 defines displayable message as follows: Displayable Message This is interpreted to be a human readable string of characters. The message encoding MUST follow the UTF-8 transformation format [RFC2279]. Therefore EAP messages including EAP Identity and Notification that are described as displayable messages have a UTF-8 encoding requirement applied to them. Since RFC 3579 Section 2.1 specifies that the EAP-Response/Identity is copied into the RADIUS User-Name Attribute:In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request. Therefore for use with EAP, the User-Name Attribute also inherits a UTF-8 encoding requirement, restricting the potential encodings permitted by RFC 2865 Section 5.1 (User-Name Attribute): The format of the username MAY be one of several forms: text Consisting only of UTF-8 encoded 10646 [7] characters. network access identifier A Network Access Identifier as described in RFC 2486 [8]. distinguished name A name in ASN.1 form used in Public Key authentication systems.
[ietf-privacy] Ongoing Call for Comments
This is a note about two ongoing Call for Comments that may interest participants on this list. Comments on these documents can be sent to i...@iab.org or entered in TRAC. 1. Privacy Considerations for Internet Protocols. This Call for Comment ends on February 18, 2013. The document is being considered for publication as an Informational RFC within the IAB stream, and is available for inspection here: http://tools.ietf.org/html/draft-iab-privacy-considerations The Call for Comment announcement is available here: https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=934k2=11573tid=1359572424 2. Issues in Identifier Comparison for Security Purposes. This Call for Comment ends on February 10, 2013. The document is being considered for publication as an Informational RFC within the IAB stream, and is available for inspection here: http://tools.ietf.org/html/draft-iab-identifier-comparison The Call for Comment announcement is available here: https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=934k2=11533tid=1359572424 ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
RE: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
+1 [IAB Chair hat off]. Date: Fri, 11 Jan 2013 22:25:38 +0100 Subject: Re: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC From: abdussalambar...@gmail.com To: s...@resistor.net CC: ietf@ietf.org; i...@ietf.org Hi SM, I totally agree with your comments and suggestions, the draft SHOULD mention the important clarifications and the answers to SM's questions. This is an important draft and SHUOLD be clear about such important details in sections, why it ignores them without refering to informative procedure items to link things for understanding. How do authors write these drafts are they done with following procedure, AB In Section 1: Additionally, the experiment will only require issues raised during these three stages to be addressed if they meet the IESG's Discuss criteria. Does this mean that a document does not have to represent consensus? In contrast, a -bis RFC that aims for Proposed Standard or Experimental is likely to be a fine candidate. I read what the document proposes as lowering the barrier of entry for first publication. My preference is to say nothing about -bis RFCs (see quoted text). Some of the -bis drafts I have come across (note that this is not related to a draft being discussed currently) are not well-written even though there is running code. The running code might be due to author intervention instead of a blind test of the specification. In Section 2: Implementations developed during the production of an Internet-draft can indicate that a working group has had the opportunity to get early confirmation of its engineering choices. Agreed. In Section 3: Any Working Group Last Call (WGLC) or Area Director (AD) review (which are routinely done, though not part of the formal [BCP9] process) will run in parallel with the two-week IETF Last Call (IETF-LC) period. I am not suggesting changing the two weeks. It can cause logistical problems. I'll take the risk of trying this experiment. Only comments that would be DISCUSS-worthy according to the IESG Discuss Criteria [DCRIT] need be handled during last call. Other comments can be handled or not, at the authors/editors discretion. See my previous comment about this criteria. In Section 4: The fast-track process can be used for bis RFCs and might well be quite suitable for those. I suggest removing this. If the timers (IETF LC or the two-weeks after IETF LC for fixing things) co-incide with a major holiday period or IETF meeting then the responsible AD can add a week or two as appropriate. I suggest not using the Fast-Track if it is less than two weeks before or after an IETF meeting. Some people only do IETF work during that period and that results in a spike. I don't think that it is a good idea for this experiment to encourage work during the meeting phase instead of the mailing list. In Section 5: An AD who wishes to do her review in parallel with Last Call is always free to make that choice. his or a gender neutral term. This memo itself has no impact on appeal processes. However, in considering an appeal that relates to a document that has been fast-track processed, the relevant judge (WG chair, AD, IESG or IAB as appropriate) should consider the requirements posited here. The WG Chair is not a judge in such cases as it would be his/her decision being appealed. Some people are discouraged from bringing work into the IETF because of the long debates (which I likely contributed to). Big companies have an incentive to do work within the IETF. There is a perception in open source circles than there isn't much to gain in having a specification published as a RFC. The young, free and wild will not listen to the fogies. The better approach, in my opinion, is not to act as a gatekeeper or encourage a wall-garden attitude. Regards, -sm
Re: [IAB] Last Call: Affirmation of the Modern Global Standards Paradigm
[BA] The reply below represents my personal opinion. Dave Crocker said: It's true that this was not put into an Internet Draft. Apart from that, we seem to be doing the right thing: - The IAB Chair announced the text and the intent to sign it on 1 Aug. Two weeks is normal process for spontaneous consensus calls? When did the community approve that change in process? [BA] Thanks for raising this issue, Dave. A document that describes the processes utilized by Modern SDOs should probably take extra care to follow the applicable process. Below find my best guess as to what that is. At one point the suggestion was to publish the statement as an RFC; had this been done, the procedures to be followed would have been governed by the procedures for publication on the selected stream. For example, if the document were to have been published as an Informational RFC within the IAB stream, then RFC 4845 would apply. Section 3 states: 5. The chair of the IAB issues an IETF-wide Call for Comment on the IETF Announce mailing list. The comment period is normally no shorter than four weeks. However, AFAIK this document is not being considered for publication as an RFC (at least within the IAB stream), so RFC 4845 does not apply. He asked for comments. No he didn't: Please send strong objections... This asserts a forceful bias against general comments and criticisms by establishing a very high threshhold for relevance. While no, no one is prevented from other kinds of postings, the bias is nonetheless established. [BA] Specifically, comments were requested to be sent to the IAB and/or to the IETF list. In the first iteration of comments, the IAB mailing list was given as the place to send comments, and a number of comments were received which resulted in changes to the document. While it might be considered inconvenient, similarly persuasive comments could be received in this round as well. As noted in the announcement, the intent is for the document to be signed by the IETF and IAB Chairs, both of whom are members of the IAB. Were the process followed in approval of IAB statements to be applied here, then IAB consensus would be required for approval. In making up their minds, members of the IAB can consider any relevant information, including the comments in this and the earlier round. Personally, in making up my mind I would look at the comments on their merit, ignoring the threshold in the announcement.
Re: Last Call: draft-betts-itu-oam-ach-code-point-03.txt (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM)
Russ Housley said: This is not an IETF problem, and I do not think that the IETF ought to be discussing the internal workings of the ITU-T process. The point is to come up with a mechanism that allows the code point to be assigned if and only if the ITU-T does come to a consensus by whatever means is allowed by their own process. [BA] Indeed, as a procedural matter, it should be clear that this is an IETF last call on draft-betts-itu-oam-ach-code-point, not an IETF last call on G.8113.1. As Russ has noted, draft-betts-itu-oam-ach-code-point can be approved for publication, holding issuance of an RFC and assignment of a code point until G.8113.1 is approved by the ITU-T. This guarantees that upon publication of draft-betts-itu-oam-ach-code-point as an RFC, the reference will be to a stable, ITU-T approved version of G.8113.1. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [radext] Review of draft-ietf-radext-radsec
Stefan said: Ok... 3579 defines it to be that way, simply pointing to dynauth; my draft could do so, too, of course. 5080 lists that it is done elsewhere but doesn't reference a particular RFC; looks to me like it could refer to RFC3579. [BA] Yes. Stefan also said: Interesting use. I don't recall Error-Cause = Invite being specified anywhere; it's not in the list of enumerated Error-Cause reasons in the IANA registry anyway. And it's one message on the list that was never replied to. Looks to me like it's one particular NAS sending weird things out-of-spec. [BA] Since the message was posted on the FreeRADIUS list, I was hoping that Alan could enlighten us. The meaning of Error-Cause=Invite wasn't obvious to me (e.g. it didn't look like there was an error involved), and as you mentioned, Invite isn't in the list of enumerated Error-Cause values. Stefan said: I would like to note however that ICMP Port Unreachable is a *very* coarse-grained way of NAKing accounting that is of little use anyway... That being said, I can change the spec to patch the situation with your suggestion of using Accounting-Response + Error-Cause. It may be the adequate thing to do since this specification is going for Experimental only. [BA] I agree that an ICMP Port Unreachable is not a useful way for a RADIUS server to tell a RADIUS client that it can't process a particular Accounting-Request. However, it does allow the destination to indicate that RADIUS accounting is not supported at all, in a way that can be distinguished from a server or network failure. That's the functionality missing in RADIUS over TLS. Stefan said: In the long run though, I think this solution is inadequate; if Accounting-NAK signalling is to be fixed, it should be fixed properly (i.e. on a per-packet basis) for all transports, not just this one. Maybe by updating 2866 with a consistent use of Error-Cause, or maybe by adding an Accounting-NAK packet type, analogous to the dynauth NAKs. It is definitely a useful thing to work on; but it's not for the RAIDUS/TLS draft to decide. That would need a wg chartered item (luckily radext is discussing rechartering right now; this might be worthwhile to include...) [BA] I agree that ICMP Port Unreachable or an equivalent in RADIUS/TLS is not a solution to the other problems you mention. Stefan said: Please let me know if you'd prefer the Error-Cause patch to be in this spec; I'll do as you say ;) [BA] Here is suggested text: (5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support reception and processing of RADIUS Accounting packets. Since RADIUS/TLS does not utilize a separate port for Accounting packets, this mechanism is not available. In the event that a client is misconfigured to send Accounting-Request packets to a RADIUS/TLS server which does not support accounting, the RADIUS/TLS server SHOULD reply with an Accounting-Response containing an Error-Cause attribute with value 406 Unsupported Extension. A RADIUS/TLS accounting client receiving such an Accounting-Response SHOULD log the error. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [radext] Review of draft-ietf-radext-radsec
Stefan said: My working copy has the following text in Security Considerations now: If peer communication between two devices is configured for both RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using shared secret security),and where the RADIUS/UDP transport is the failover option if the TLS session cannot be established, a down- bidding attack can occur if an adversary can maliciously close the TCP connection, or prevent it from being established. Situations where clients are configured in such a way are likely to occur during a migration phase from RADIUS/UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker can reduce the security of the packet payload from the selected TLS cipher suite packet encryption to the classic MD5 per-attribute encryption. The situation should be avoided by disabling the weaker RADIUS/UDP transport as soon as the new RADIUS/TLS transport is established and tested. Disabling can happen at either the RADIUS client or server side: o Client side: de-configure the failover setup, leaving RADIUS/TLS as the only communication option o Server side: de-configure the RADIUS/UDP client from the list of valid RADIUS clients I hope that makes my intended statement clearer. [BA] My issue is the use of a well known shared secret with RADIUS/UDP. This could be fixed by requiring that a server supporting RADIUS/TLS MUST check for a RADIUS/TLS connection before allowing use of the well known shared secret. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [radext] Review of draft-ietf-radext-radsec
Stefan said: That's true. As I went through your comments below, I realised that large parts of the texts you quoted should be moved to the dynamic-discovery draft altogether as they are are very specific to that draft. I'm thinking of taking out all the snippets you mentioned below, transfer them to dynamic-discovery and leaving nothing but a small pointer paragraph in the RADIUS/TLS document. [BA] That's a great idea. Stefan said: Indeed. I'll update the text to that end. Note though that adding Error-Cause is a MAY only in 5176, so it may very well be that an implementation which doesn't support dynauth would still send only a naked NAK, ignoring the MAY. [BA] It's a MAY in RFC 5176 because existing implementations didn't support Error-Cause at all. However, in this particular case, since you're requiring that RADIUS/TLS implementations support NAK in the first place, you can also say that they SHOULD send an Error-Cause attribute. So I'd suggest that the MAY be stronger, so as to remove a potential ambiguity about the meaning of the NAK. It is sufficient that upon receiving such a packet, an unconditional NAK is sent back to indicate that the action is not supported. [BA] The problem is that a NAK does NOT mean that the action is unsupported according to RFC 5176, unless there is an Error-Cause attribute present that indicates that. Stefan said: I'm slightly confused here. To my best knowledge, Error-cause is only specified in the context of DynAuth (RFC5176). That attribute is listed as only allowed in a NAK as per the attribute occurrence table in 5176. [BA] While RFC 5176 only mentions use of Error-Cause in dynamic authorization it can also be used in other contexts. For example, Error-Cause is referenced in the following other RFCs: RFC 3579: Error-Cause use in Access-Challenge and Access-Reject (see Section 3.3) RFC 5080: Error-Cause in Access-Reject (See Section 2.6.1) Stefan said: I would be hesitant to use Error-Cause in RADIUS Accounting packets - unless the corresponding RFCs get updated to specify that this attribute is now also to be used in Accounting semantics. [BA] Apparently, Error-Cause is being sent in Accounting-Request packets, see: http://lists.cistron.nl/pipermail/freeradius-users/2011-January/msg00255.html With respect to Accounting-Response, RFC 2866 does prohibit inclusion of attributes relating to a service, but not attributes like Proxy-State or Vendor-Specific. So I'd argue that Error-Cause fits within the category of attributes that would be permissible -- an Informational attribute that can be ignored without damage. Stefan said: The non-ability to indicate No accounting please has been discussed in a radext wg meeting. The conclusion was that auth and acct are two separate, unrelated items. RADIUS Accounting needs to be configured differently and explicitly; so there is little risk that accounting packets are sent by chance anyway. If they are sent to the wrong place, that is an administrative error: misconfigured on the sender-side. [BA] If a RADIUS over UDP packet is sent to the wrong place, an ICMP message will result that the RADIUS Accounting client can act on, such as by logging the error. In this case, you are mandating that the RADIUS over TLS server ignore the request, resulting in continuing connection attempts and retransmissions by the RADIUS over TLS client, who doesn't receive evidence of the misconfiguration. So I'd argue that RADIUS over TLS is creating a new problem. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-ietf-radext-radsec
This is a review of TLS Encryption for RADIUS draft-ietf-radext-radsec. Overall, this draft was a pleasant to read, and it is clear that a lot of thought as well as implementation experience has gone into it. Kudos to the authors. General Issues There is a considerable amount of text relating to dynamic discovery in this document, yet there is only an informational reference to it. Since inserting a normative reference to dynamic discovery could delay the publication of this document unnecessarily, my recommendation is to consolidate some of the dynamic discovery material into a single section in which you can discuss the implications, while clearly indicating the status of the dynamic discovery work (e.g. still under development, optional to implement along with RADSEC, etc.). For example, you might consider consolidating the following text from Sections 3.1 and 6 and placing it prior to the current Section 3.1: Section 3.X: Implications of Dynamic Peer Discovery One mechanism to discover RADIUS over TLS peers dynamically via DNS is specified in [I-D.ietf-radext-dynamic-discovery]. While this mechanism is still under development and therefore is not a normative dependency of RADIUS/TLS, the use of dynamic discovery has potential future implications that are important to understand. If dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery] is used, peer authentication alone is not sufficient; the peer must also be authorised to perform user authentications. In these cases, the trust fabric cannot depend on peer authentication methods like DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be properly authorised. Typically, this can be achieved by adding appropriate authorisation fields into a X.509 certificate. Such fields include SRV authority [RFC4985], subjectAltNames, or a defined list of certificate fingerprints. Operators of a RADIUS/TLS infrastructure should define their own authorisation trust model and apply this model to the certificates. The checks enumerated in Section 2.3 provide sufficient flexibility for the implementation of authorisation trust models. [BA] I think you need to be more prescriptive here. Are there specific fields that a RADSEC TLS certificate should contain? Having individual implementations/deployments defining their own authorization schemes seems like a bad idea. In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be able to accept connections from a large, not previously known, group of hosts, possibly the whole internet. In this case, the server's RADIUS/TLS port can not be protected from unauthorised connection attempts with measures on the network layer, i.e. access lists and firewalls. This opens more attack vectors for Distributed Denial of Service attacks, just like any other service that is supposed to serve arbitrary clients (like for example web servers). In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only proof of authorisation for a connecting RADIUS/TLS nodes. Special care needs to be taken that certificates get verified properly according to the chosen trust model (particularly: consulting CRLs, checking critical extensions, checking subjectAltNames etc.) to prevent unauthorised connections. Other comments Section 1 One mechanism to discover RADIUS over TLS peers with DNS is specified in [I-D.ietf-radext-dynamic-discovery]. [BA] Recommend moving this to a section devoted to dynamic discovery. Section 2.1 See section Section 3.3 (4) and (5) for considerations regarding separation of authentication, accounting and dynauth traffic. [BA] Recommend changing to: See Section 3.3 for considerations regarding separation of authentication, accounting and dynamic authorisation traffic. Section 2.3 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The shared secret to compute the (obsolete) MD5 integrity checks and attribute encryption MUST be radsec (see Section 3.3 (2) ). Section 3.1 (3) If dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery] is used, peer authentication alone is not sufficient; the peer must also be authorised to perform user authentications. In these cases, the trust fabric cannot depend on peer authentication methods like DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be properly authorised. Typically, this can be achieved by adding appropriate authorisation fields into a X.509 certificate. Such fields include SRV authority [RFC4985], subjectAltNames, or a defined list of certificate fingerprints. Operators of a RADIUS/TLS infrastructure should define their own authorisation trust model and apply this model to the certificates. The
Review of draft-ietf-nextext-radius-pmip6
The document appears to contain typos in sections 4.16 and 4.17. In section 4.16, it appears that Home LMA IPv6 address should be replaced by Home DHCPv6 server address: 4.16. PMIP6-Home-DHCP6-Server-Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home LMA IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In Section 4.17, it appears that Visited LMA IPv6 address should be replaced by Visited DHCPv6 server address: 4.17. PMIP6-Visited-DHCP6-Server-Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited LMA IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2. Table of Attributes The following table provides a guide to attributes that may be found in authentication and authorization RADIUS messages between MAG and the AAA Server. Request Accept Reject Challenge # Attribute 0-1 0-10-10-1 80 Message-Authenticator [BA] The Message-Authenticator attribute is mandatory-to-implement in a number of RADIUS usages, including EAP (RFC 3579). Leaving out Message-Authenticator could result in Access-Requests lacking authentication and integrity protection. RFC 6158 Section 3.1 states: While [RFC2865] did not require authentication and integrity protection of RADIUS Access-Request packets, subsequent authentication mechanism specifications, such as RADIUS/EAP [RFC3579] and Digest Authentication [RFC5090], have mandated authentication and integrity protection for certain RADIUS packets. [RFC5080], Section 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets, including Access-Request packets performing authorization checks. It is expected that specifications for new RADIUS authentication mechanisms will continue this practice. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-nextext-radius-pmip6
Message-Authenticator should be mandatory (1 1 1 1). On Jan 10, 2012, at 22:30, jouni korhonen jouni.nos...@gmail.com wrote: Bernard, Thank you for your review. See my comments inline. On Jan 10, 2012, at 8:37 PM, Bernard Aboba wrote: The document appears to contain typos in sections 4.16 and 4.17. In section 4.16, it appears that Home LMA IPv6 address should be replaced by Home DHCPv6 server address: Blimey.. we'll fix this. 4.16. PMIP6-Home-DHCP6-Server-Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home LMA IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In Section 4.17, it appears that Visited LMA IPv6 address should be replaced by Visited DHCPv6 server address: And the same here.. 4.17. PMIP6-Visited-DHCP6-Server-Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited LMA IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2. Table of Attributes The following table provides a guide to attributes that may be found in authentication and authorization RADIUS messages between MAG and the AAA Server. Request Accept Reject Challenge # Attribute 0-1 0-10-10-1 80 Message-Authenticator [BA] The Message-Authenticator attribute is mandatory-to-implement in a number of RADIUS usages, including EAP (RFC 3579). Leaving out Message-Authenticator could result in Access-Requests lacking authentication and integrity protection. RFC 6158 Section 3.1 states: Good point. So, you are saying that we should have: 1 0-10-10-1 80 Message-Authenticator or would 1 1 1 180 Message-Authenticator be even better as RFC3759 5090 do? - Jouni While [RFC2865] did not require authentication and integrity protection of RADIUS Access-Request packets, subsequent authentication mechanism specifications, such as RADIUS/EAP [RFC3579] and Digest Authentication [RFC5090], have mandated authentication and integrity protection for certain RADIUS packets. [RFC5080], Section 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets, including Access-Request packets performing authorization checks. It is expected that specifications for new RADIUS authentication mechanisms will continue this practice. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
I've seen many enterprise customers using RFC 1918 address space internally. This includes allocating 10/8 addresses for hosts, and 172.16/12 for isolated segments behind firewalls. Since 192.168/16 may be used by employees in their homes accessing the corpnet, often this block is avoided for use in address allocation on VPN servers. In terms of NAT usage in enterprise, it is very common: in branches, employee homes, campuses, even in data center load balancers (reverse NAT). It is quite common to see RFC 1918 space of all types in enterprise routing tables. Given the huge influx of mobile devices (many of which do not support IPv6 fully), there will be even more pressure to deploy RFC 1918 addresses and more efficiently use routable address space. In general, enterprise addressing plans are developed and changed deliberately and with considerable planning. Where things become more tricky is in Extranet design where connections can be made to partners with their own addressing complexities. To avoid routing issues fire gaping may be required. On Dec 4, 2011, at 21:24, Pete Resnick presn...@qualcomm.com wrote: On 12/4/11 8:22 AM, Hadriel Kaplan wrote: So you tell me how safe picking a specific RFC 1918 address space is. There are ~100,000 enterprises with over 100 employees just in the US, and ~20,000 with over 500 employees in the US. Obviously my company is a tech company so it's probably not normal, but still it seems obvious enterprises use random 10.x.x.x and 172.16/12. AFAICT, it *isn't* safe to use these addresses if and only if these enterprises *also* use equipment that can't deal with 1918 addresses on their external interface. For example, your machine taking a 10.2xx.xxx.xxx address isn't a problem in and of itself because the NAT in front of you is translating. The issue only arises if the Carrier Grade NAT in front of you is on the other side of equipment that *can't* handle that portion of address space on the outside. Now, I don't know if that means it *is* safe. I don't know how many enterprises talk to CGNs and wouldn't be able to deal with a particular block of 1918 addresses on the outside. That's the question I'd really like an answer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
The same thought occurred to me. A very large enterprise will not utilize this /10 on a whim; they'd talk to their ISP first. A consumer is unlikely to modify the settings of their home router, except if they download malware that does it for them :) and a consumer router vendor has such a low margin that the last thing they want is to utilize this forbidden /10, generating thousands of tech support calls they can't afford to answer. On Dec 3, 2011, at 20:54, Henning Schulzrinne h...@cs.columbia.edu wrote: Almost all residential customers will use a standard home router; as long as that home router does not make the new space available to customers, it will not be used. Almost all residential users get their home NAT box either from the ISP (who obviously won't ship such a box) or from one of a handful of retail consumer equipment vendors, who won't suddenly switch from RFC 1918 addresses, either (because they don't want to get the support calls). I don't think your consumer ISP will have much sympathy if you call them up and tell them that you decided to use 128.59.x.x internally, reconfigured the gateway and can no longer get to Columbia University. This is an economics issue: If one big corporate customer with a too-creative sysadmin calls up after finding this new address space, this can be dealt with. (Indeed, that large corporate customer probably has non-1918 outward-facing addresses to begin with and will keep them, so they are the least likely target of CGNs.) If 10,000 consumer customers call up because their Intertubes aren't working, the ISP has a problem. Thus, I'm having a hard time believing in the theory that the new space will be immediately appropriated for consumer ISPs. By whom, exactly, and on what scale and with what motivation? Henning On Dec 3, 2011, at 8:36 PM, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us This argument has been raised before, but IMO the value is exactly zero. The fact that you have a finger to wag at someone doesn't make the costs of dealing with the conflict any smaller. Perhaps. But I don't know the ISPs' business as well as they do. So I'd like to hear their views on this point. (They may well have considered this point before deciding to ask for CGN space, and decided the space was still enough use to be worth it.) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
[BA] My comment is that having guidelines for this could help make the advancement process more predictable. Thank you for working on this. Jari Arkko said: During the discussion of the two maturity levels change, a question was brought up about DISCUSSes appropriate for documents that advance on the standards track. We discussed this in the IESG and I drafted some suggested guidelines. Feedback on these suggestions would be welcome. The intent is to publish an IESG statement to complement the already existing general-purpose DISCUSS criteria IESG statement (http://www.ietf.org/iesg/statement/discuss-criteria.html). Here are the suggested guidelines for documents that advance to IS: http://www.arkko.com/ietf/iesg/discuss-criteria-advancing.txt Comments appreciated. Please send comments either on this list or to the IESG (i...@ietf.org) in time before our next telechat (Thursday, September 8, 2011). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Speaking for myself only, I believe that this proposal does attempt to address some issues relating to advancement, so that it is not entirely window dressing. For example, I believe that the changes with respect to down references (Section 4) and annual review (Section 3) are constructive, and long overdue. Implementation reports are a more difficult topic since they constitute both an obstacle to advancement as well as an important step on the road to development of interoperable standards. In particular, the development of implementation reports, while cumbersome, provides objective evidence of progress. It is difficult to simultaneously lower the barriers to advancement while keeping most of the value (and objectivity) that implementation reports provide. I am not sure that the document currently has this balance quite right. Section 2.2 states: Note that the distinct requirement from RFC 2026 [1] for reports of interoperability testing among two or more independent implementations is intentionally subsumed by the requirement for actual deployment and use of independent and interoperable implementations. The Last Call is intended to identify unused portions of the specification that greatly increase implementation complexity without burdensome implementation testing and documentation. Today it is quite common within WGs to see conflicting claims about protocol implementations and interoperability. IMHO one of the critical purposes served by implementation reports is to require proponents to produce the evidence backing their claims. The above paragraph left me wondering what the burden of proof would be in practice. For example, I would not want to see the IESG put in the position of adjudicating he said, she said arguments made during Last Call. As a result, I cannot endorse the approval of this ID as it exists today, but could see it being changed to address these concerns. To: ietf@ietf.org Subject: Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP Date: Thu, 5 May 2011 14:33:51 -0400 From: s...@harvard.edu CC: i...@ietf.org As I have stated before, I do not think that this proposal will achieve anything useful since it will not change anything related to the underlying causes of few Proposed Standards advancing on the standards track. I see it as window dressing and, thus, a diversion from the technical work the IETF should focus on. If it were up to me, I would not approve this ID for publication as a RFC (of any type) Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-ietf-ecrit-phonebcp
I reviewed the document draft-ietf-ecrit-phonebcp in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. The views represented here are those of the reviewer and do not represent the opinion of any other entity, including the Operations Directorate. Review Summary: Intended status: Best Current Practice This memo describes best current practice for how devices, networks, service providers and Public Safety Answering Points (PSAPs) should use IETF standards for emergency calling over IP networks. Is the document readable? In general the document is reasonably well organized. However, there are some requirements that do not seem easily translated into specific implementation or deployment guidance. See detailed comments for examples. Does it contain nits? Maybe. idnits 2.12.09 tmp/draft-ietf-ecrit-phonebcp-17.txt: tmp/draft-ietf-ecrit-phonebcp-17.txt(1142): Found possible FQDN 'test.sos.ambulance' in position 3; this doesn't match RFC 2606's suggested .example or .example.(com|org|net). tmp/draft-ietf-ecrit-phonebcp-17.txt(1143): Found possible FQDN 'test.sos.animal' in position 3; this doesn't match RFC 2606's suggested .example or .example.(com|org|net). tmp/draft-ietf-ecrit-phonebcp-17.txt(1144): Found possible FQDN 'test.sos.fire' in position 3; this doesn't match RFC 2606's suggested .example or .example.(com|org|net). tmp/draft-ietf-ecrit-phonebcp-17.txt(1145): Found possible FQDN 'test.sos.gas' in position 3; this doesn't match RFC 2606's suggested .example or .example.(com|org|net). tmp/draft-ietf-ecrit-phonebcp-17.txt(1146): Found possible FQDN 'test.sos.marine' in position 3; this doesn't match RFC 2606's suggested .example or .example.(com|org|net). tmp/draft-ietf-ecrit-phonebcp-17.txt(1147): Found possible FQDN 'test.sos.mountain' in position 3; this doesn't match RFC 2606's suggested .example or .example.(com|org|net). tmp/draft-ietf-ecrit-phonebcp-17.txt(1148): Found possible FQDN 'test.sos.physician' in position 3; this doesn't match RFC 2606's suggested .example or .example.(com|org|net). tmp/draft-ietf-ecrit-phonebcp-17.txt(1149): Found possible FQDN 'test.sos.poison' in position 3; this doesn't match RFC 2606's suggested .example or .example.(com|org|net). tmp/draft-ietf-ecrit-phonebcp-17.txt(1150): Found possible FQDN 'test.sos.police' in position 3; this doesn't match RFC 2606's suggested .example or .example.(com|org|net). Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) -- however, there's a paragraph with a matching beginning. Boilerplate error? IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii): This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license
RE: [paws] WG Review: Protocol to Access White Space database (paws)
When I hear the term device identity spoofing, IEEE 802.1ar comes to mind (see http://standards.ieee.org/getieee802/download/802.1AR.-2009.pdf). In addition to the liaisons with IEEE 802.19, 802.22 and IEEE 802.11af, is there a liaison contemplated to IEEE 802.1 relating to device identity? From: scott.proba...@nokia.com To: stephen.farr...@cs.tcd.ie; ietf@ietf.org Subject: RE: [paws] WG Review: Protocol to Access White Space database (paws) Date: Wed, 20 Apr 2011 14:41:23 + CC: p...@ietf.org; i...@ietf.org Hi Stephen, All, I believe the current wording Robust security mechanisms are required to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, ... is acceptable because mechanisms are required means they should be in the protocol, it does not mean they cannot be optional. PAWS should support Regulator requirements globally, and thus I believe there will be procedures or capabilities which are required to be in the protocol but will be optional during run time. Thus different or conflicting requirements from different regions of the world can be supported. (Several regulatory groups around the world are still developing their views and requirements). It's not the time to dig deep into proposed solutions, just my opinion is the current proposed wording is an acceptable definition to allow a Work Group to get started defining the details. Regards, Scott -Original Message- From: paws-boun...@ietf.org [mailto:paws-boun...@ietf.org] On Behalf Of ext Stephen Farrell Sent: Tuesday, April 19, 2011 4:28 PM To: IETF-Discussion Cc: p...@ietf.org; i...@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) I think this is a good and timely thing for the IETF to do. One part of this where I think it might be useful to get some broader input (which may have happened already, I'm not sure) is the following: On 19/04/11 17:56, IESG Secretary wrote: The protocol must protect both the channel enablement process and the privacy of users. That part is fine but it goes on to say: Robust security mechanisms are required to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, ... I'm told (and believe) this in response to (at least) US FCC requirements that call for a device ID and sometimes serial number to be (securely, for some value of securely) sent with the query. Those appear to be real regulatory requirements in the US, presumably so the regulator can stomp on someone who messes about in the wrong spectrum at the wrong time. (The link below [1] may be to the right or wrong bit of those US regulations, I'm not at all sure, not being from there;-) So my questions: Are there may be similar (or conflicting!) requirements elsewhere? Does this bit of the charter text need changes to work well for other regions? Separately, I'm not sure how to square those kinds of regulatory requirements with protecting privacy where the device is carried by a person and has some FCC device ID (which lots do I guess) and the person might not want the database operator to know who's asking. But I think that's ok as something for the WG to figure out since the charter already calls for respecting privacy. I'm more concerned in case e.g. some other regional regulation called for this protocol to be completely anonymous or something, in which case the current charter text might be problematic. Cheers, Stephen. [1] http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfrsid=3e9c322addf1f7e897d8c84a6c7aca78rgn=div8view=textnode=47:1.0.1.1.14.8.243.9idno=47 ___ paws mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/paws ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC
Overall, I think this is a useful document.
My suggestions below mostly relate to potential organizational improvements, as
well as as a bit more detail in some areas.
Section 2
This section talks about how white-listing works, but does not talk about
potential mechanisms by which the whitelist is determined. For example, in
addition to techniques for manually maintaining the whitelist, there have been
some suggestions that would involve automatic determinations (e.g. only
answering with RRs if the query comes in over IPv6). It might be useful
to cover some of the proposals, since they might have different implications.
Section 2.1
Is the term IP address here intended to include both IPv4 and IPv6 addresses?
Section 3
At least one highly-trafficked domain has noted that they have
received requests to not send DNS responses with resource
records to particular resolvers. In this case, the operators of
those recursive resolvers have expressed a concern that their IPv6
network infrastructure is not yet ready to handle the large traffic
volume which may be associated with the hosts in their network
connecting to the websites of these domains. This concern is clearly
a temporary consideration relating to the deployment of IPv6 network
infrastructure on the part of networks with end user hosts, rather
than a long-term concern. These end user networks may also have
other tools at their disposal in order to address this concern,
including applying rules to network equipment such as routers and
firewalls (this will necessarily vary by the type of network, as well
as the technologies used and the design of a given network), as well
as configuration of their recursive resolvers (though modifying or
suppressing resource records in a DNSSEC-signed domain on a
Security-Aware Resolver will be problematic Section 10.1).
[BA] This paragraph seems to be distinguishing blacklisting from
whitelisting as well as describing some of the implications of attempting to
suppress RRs in the recursive resolver. It might be worthwhile to
introduce the distinction between blacklisting and whitelisting earlier on.
Such a section might also include the following paragraph from Section 7.3.7:
It is unclear when and if it would be appropriate to change from
whitelisting to blacklisting, and whether or how this could feasibly
be coordinated across the Internet, which may be proposed or
implemented on an ad hoc basis when a majority of networks (or
allocated IPv6 address blocks) have been whitelisted. Finally, some
parties implementing DNS whitelisting consider this to be a temporary
measure. As such, it is not clear how these parties will judge the
network conditions to have changed sufficiently to justify disabling
DNS whitelisting and/or what the process and timing will be in order
to discontinue this practice.
Section 4
While in Section 1 the level of IPv6-related impairment has been
estimated to be as high as 0.078% of Internet users, which is a
primary motivation cited for the practice of DNS whitelisting, it is
not clear if the level of IPv4-related impairment is more or less
that this percentage (which in any case is likely to have declined
since its original citation). Indeed, as at least one document
reviewer has pointed out, it may simply be that websites are only
measuring IPv6 impairments and not IPv4 impairments, whether because
IPv6 is new or whether those websites are simply unable to or are
otherwise not in a position to be able to measure IPv4 impairment
(since this could result in no Internet access whatsoever). As a
result, it is worth considering that IPv4-related impairment could
exceed that of IPv6-related impairment and that such IPv4-related
impairment may have simply been accepted as background noise on the
Internet for a variety of reasons. Of course, this comparison of the
level of worldwide IPv6 impairments to IPv4 impairments is
speculation, as the author is not aware of any good measurement of
IPv4-related impairments which are comparable in nature to the IPv6-
related impairment measurements which have recently been conducted
around the world.
[BA] It seems to me that discussion of measurement issues should probably come
earlier in the document, possibly in its own section.
My suggestion is to move this paragraph as well other paragraphs referring to
measurement into its own section (Section 1.1?).
The following paragraph from Section 3.2 might be a candidate:
Finally, some domains, have run IPv6 experiments whereby they added
resource records and observed and measured errors [Heise Online
Experiment], which should be important reading for any domain
contemplating either the use of DNS whitelisting or simply adding
IPv6 addressing to their site.
Section 6
This section talks about
RE: Request for Operations Directorate Review of draft-ietf-payload-rfc4695-bis-01 by 2011-02-23
I reviewed the document draft-ietf-payload-rfc4695-bis in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Standards Track The document provides an updated specification for the RTP payload format for MIDI, suitable for applications such as musical performances. The primary reason for the update was to address errors found in RFC 4695 by reviewers. Is the document readable? Yes. Does it contain nits? Possibly: idnits 2.12.07: tmp/draft-ietf-payload-rfc4695-bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : -- The draft header indicates that this document obsoletes RFC4695, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: -- The document date (February 8, 2011) is 19 days in the past. Is this intentional? Checking references for intended status: Proposed Standard (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3986' is defined on line 7122, but no explicit reference was found in the text '[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, Uniform...' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIDI' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPEGSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPEGAUDIO' -- Possible downref: Non-RFC (?) normative reference: ref. 'DLS2' -- Possible downref: Non-RFC (?) normative reference: ref. 'RP015' Summary: 0 errors (**), 1 warning (==), 7 comments (--). Is the document class appropriate? Yes. Is the problem well stated? Yes. Is the problem really a problem? Yes. Does the document consider existing solutions? Yes. The document addresses issues found in RFC 4695. The differences are detailed in Appendix F, and there are no operational issues raised there (it's mostly ABNF corrections for SDP session management parameters). Does the solution break existing technology? No. This update is backward compatible with RFC 4695, other than the errors that were corrected. Does the solution preclude future activity? No. Is the solution sufficiently configurable? Yes. Negotiation is taken care of by SDP. Can performance be measured? How? Yes, using RTCP reporting. Does the solution scale well? Yes. The document defines both multicast and unicast transport. Is Security Management discussed? Security considerations are addressed in Section 9. Hello, As a member of the Operations Directorate you are being asked to review the following draft which is in IETF last call for it's operational impact. IETF Last Call: The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-payload-rfc4695-bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-payload-rfc4695-bis/ Please provide comments and review to the Ops-dir mailing list (ops-...@ietf.org) before 2011-02-23, and include the authors of the draft as well. A Check-list of possible questions/topics to address in an OPS-DIR review may be found in Appendix A of RFC 5706. Only include the questions that apply to your review. The status of Operations Directorate Review could be found http://trac.tools.ietf.org/area/ops/trac/wiki/Directorates or
Operations Directorate Review of draft-ietf-mpls-ip-options
I reviewed the document draft-ietf-mpls-ip-options in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Proposed Standard This document specifies how Label Edge Routers (LER) should behave when determining whether to MPLS encapsulate an IPv4 packet with header options. This document is motivated by the need to mitigate the existing risks of IP options-based security attacks against MPLS infrastructure. While this newly defined LER behavior is mandatory to implement, it is optional to invoke. Is the document readable? Yes. Does it contain nits? No: idnits 2.12.05 tmp/draft-ietf-mpls-ip-options-05.txt: -- The document date (May 2011) is 151 days in the future. Is this intentional? Summary: 0 errors (**), 0 warnings (==), 1 comment (--). Is the document class appropriate? Yes. Is the problem well stated? Yes. Is the problem really a problem? Yes. Does the document consider existing solutions? Yes. The document brings together existing practices into a single recommendation. Does the solution break existing technology? No. Does the solution preclude future activity? No. Is the solution sufficiently configurable? Yes. In a number of instances, the document recommends default policies, but allows other policies to be configured if necessary. Can performance be measured? How? Performance will be enhanced by avoiding potential DOS attacks described in Section 5.1 and 5.2. This can be measured via conventional metrics for packet forwarding and label switching. Does the solution scale well? Yes. Improving security and DOS attack avoidance enhances scaling. Is Security Management discussed? Yes. This document is focused on avoiding security threats to MPLS infrastructure. -Original Message- From: Tina Tsou [mailto:t...@huawei.com] Sent: Wednesday, November 24, 2010 3:18 PM To: bernard_ab...@hotmail.com Cc: 'Ronald Bonica'; 'Romascanu, Dan (Dan)' Subject: Request for Operations Directorate Review of draft-ietf-mpls-ip-options-05 by 2010-11-30 Hello, As a member of the Operations Directorate you are being asked to review the following draft which is in IETF last call for it's operational impact. IETF Last Call: The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ip-options/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ip-options/ Please provide comments and review to the Ops-dir mailing list (ops-...@ietf.org) before 2010-11-30, and include the authors of the draft as well. A Check-list of possible questions/topics to address in an OPS-DIR review may be found in Appendix A of RFC 5706. Only include the questions that apply to your review. The status of Operations Directorate Review could be found http://trac.tools.ietf.org/area/ops/trac/wiki/Directorates or http://merlot.tools.ietf.org/tools/art/opsdir/index.cgi/t=4904/welcome You could update the wiki page when you finish the review. Thank you, Tina http://tinatsou.weebly.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-zorn-radius-keywrap
There are two major issues remaining in this document. One issue is that in a number of places, the document appears to contradict IETF standards track documents. Examples: Section 3.1 If the client requires the use of the Keying-Material Attribute for keying material delivery and it is not present in the Access- Accept or Access-Challenge message, the client MAY ignore the message in question and end the user session. [BA] Presumbly the MAY is included here for security reasons, such as preventing the client from accepting a downlevel key from a server from which it has previously received keying material described in this document, thus preventing spoofing in the event that the RADIUS shared secret (or MD5) is compromised. However, in such a situation the key material itself would be compromised, so that some sort of warning should probably be raised. My recommendation is that this be rewritten to state the considerations underlying the MAY, as well as recommended behavior in line with RFC 2865 Section 5.26, which states: Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode. RFC 2865 is written this way to prevent the creation of proprietary RADIUS implementations that require the presence of vendor-specific information. Section 3.3 Any packet that contains an instance of the Message- Authentication-Code Attribute SHOULD NOT contain an instance of the Message-Authenticator Attribute [RFC3579]. [BA] Since the Message-Authenticator Attribute is mandated by RFC 3579, this represents a contradiction. My recommendation would be to remove this sentence, and require that the key used in computing the Message-Authentication-Code be cryptographically independent of the RADIUS shared secret. That way both attributes can be included without damage. Section 5 It is RECOMMENDED in this memo that two new keys, a key encrypting key and a message authentication key, be shared by the RADIUS client and server. If implemented, these two keys MUST be different from each other and SHOULD NOT be based on a password. These two keys SHOULD be cryptographically independent of the RADIUS shared secret used in calculating the Response Authenticator [RFC2865], Request Authenticator [RFC2866] [RFC5176] and Message-Authenticator Attribute [RFC3579]; otherwise if the shared secret is broken, all is lost. [BA] I believe that cryptgraphic independence of the RADIUS shared secret needs to be a MUST, since the goal of this document is to provide security even in a situation where the RADIUS shared secret could be compromised. Another issue is that there are a number of fields for which the content of this field is outside the scope of this document. The document needs to provide enough information on these fields to enable interoperability. Currently it is not clear if this is the case. Fields which are not adequately explained include the following: Section 3.1 Keying-Material KEK ID The KEK ID field is 16 octets in length and contains an identifier for the KEK. The KEK ID MUST refer to an encryption key of a type and length appropriate for use with the algorithm specified by the Enc Type field (see above). This key is used to protect the contents of the Data field (below). Further specification of the content of this field is outside the scope of this document. KM ID The KM ID field is 16 octets in length and contains an identifier for the contents of the Data field. The KM ID MAY be used by communicating parties to identify the material being transmitted. The combination of App ID and KM ID MUST uniquely identify the keying material between the parties utilizing it. The KM ID is assumed to be known to the parties that derived the keying material. If the KM ID is not used it is set to 0. Further specification of the content of this field is outside the scope of this document. Section 3.3 Message-Authentication-Code MAC Key ID The MAC Key ID field is 16 octets in length and contains an identifier for the key. The MAC Key ID MUST refer to a key of a type and length appropriate for use with the algorithm specified by the MAC Type field (see above). Further specification of the content of this field is outside the scope of this document. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Problem with draft-sheffer-emu-eap-eke
I just took a look at the EAP EKE document recently approved by the IESG for publication as an Informational RFC: http://tools.ietf.org/html/draft-sheffer-emu-eap-eke-09 The document does not define the following parameters required by RFC 5247: 1. Peer-Id 2. Server-Id 3. Session-Id In particular, the omission of the Session-Id is a significant problem, since this is required for EAP methods to be usable within IEEE 802.1X-2010. My suggestion is that ID_P be designated as the Peer-Id. Since the Server identity is not authenticated (just asserted), it is not clear to me whether ID_S is suitable for use as the Server-Id. My suggestion is that the Session-Id be defined as follows: Session-Id = Type-Code || Nonce_P || Nonce_S ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: BOF Attendance Minimization
Dave Crocker said: 1. Can you provide some rationale for the details of the experiment? 2. Is one goal to maximize the attendance conflicts among BOFs? 1. In terms of rationale, I am reminded of Kinky Freedman's slogan, when running for Governor or Texas: Why Not? (see http://www.foxnews.com/story/0,2933,146289,00.html for details). However, I do admit that this approach can sometimes backfire (see http://www.independentpoliticalreport.com/2010/07/kinky-friedman-endorses-do g-for-texas-governor/ ). 2. With experiments like this, the effects can be unpredictable. So it's possible that the experiment could *minimize* attendance conflicts at BOFs -- by minimizing attendance. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications
BTW, IAB documents are now included in TRAC, so that it is now possible to enter a comment or issue from the following link: http://trac.tools.ietf.org/group/iab/trac/newticket ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-gundavelli-v6ops-l2-unicast
(that IP and link-layer addressing are independent), I am not clear about the circumstances in which it would be valid to drop an IPv6 multicast packet because of its link-layer destination address. I would like to see this spelled out, so that it is clear why this is a MUST NOT. -Original Message- From: David Harrington [mailto:ietf...@comcast.net] Sent: Wednesday, September 22, 2010 9:35 AM To: Bernard Aboba; Bernard Aboba Subject: request: tsvdir for draft-gundavelli-v6ops-l2-unicast Hi Bernard, Can you do a tsvdir review for draft-gundavelli-v6ops-l2-unicast Last Call ends 9/27 Thanks, David Harrington Director, IETF Transport Area ietf...@comcast.net (preferred for ietf) dbharring...@huaweisymantec.com +1 603 828 1401 (cell) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Review of draft-saintandre-tls-server-id-check
So the statement that RFC 4985 appears to require matching of the source domain/service type to the SRV-ID in the certificate is correct, right? If the reference identifier is _Service.Name then the match is being done on the *input* to the SRV lookup process, not the output, and prohibition on DNS lookups would not apply (or even make any sense). -Original Message- From: Stefan Santesson [mailto:ste...@aaa-sec.com] Sent: Wednesday, September 08, 2010 7:21 AM To: Bernard Aboba; daedu...@btconnect.com; ietf@ietf.org; stpe...@stpeter.im Subject: Re: Review of draft-saintandre-tls-server-id-check My apology, I just realized that the document defines source domain as what I thought would be the target domain source domain: The fully-qualified DNS domain name that a client expects an application service to present in the certificate. Which makes my comments below a bit wrong. I think it would be better to discuss this in terms of reference identifier and presented Identifier. presented identifier: An identifier that is presented by a server to a client within the server's PKIX certificate when the client attempts to establish a secure connection with the server; the certificate can include one or more presented identifiers of different types. reference identifier: An identifier that is used by the client for matching purposes when checking the presented identifiers; the client can attempt to match multiple reference identifiers of different types. I see no problem in obtaining the reference identifier from a DNS lookup an the comparing it with a presented identifier in the certificate. Why would you require the reference identity to be provided by a human user? /Stefan On 10-09-08 3:40 PM, Stefan Santesson ste...@aaa-sec.com wrote: Being the author of RFC 4985 I agree with most of you say here. Comments in line; On 10-09-06 8:48 PM, Bernard Aboba bernard_ab...@hotmail.com wrote: That was in fact my original question. Section 5.1 states that the source domain and service type MUST be provided by a human user, and can't be derived. Yet in an SRV or DDDS lookup, it is not the source domain that is derived, it is the target domain. Given that, it's not clear to me what types of DNS resolutions are to be discouraged. This puzzled me as well. The domain of interest is the domain where the requested service is located = target domain. As noted elsewhere, RFC 4985 appears to require matching of the source domain/service type to the SRV-ID in the certificate. It is not. RFC 4985 says the following in section 2: _Service.Name snip Name The DNS domain name of the domain where the specified service is located. Such a process would be consistent with a match between user inputs (the source domain and service type) and the presented identifier (the SRV-ID). Since this is not the definition of SRVName, this type of matching does not apply. Yet, Section 5.1 states: When the connecting application is an interactive client, the source domain name and service type MUST be provided by a human user (e.g. when specifying the server portion of the user's account name on the server or when explicitly configuring the client to connect to a particular host or URI as in [SIP-LOC]) and MUST NOT be derived from the user inputs in an automated fashion (e.g., a host name or domain name discovered through DNS resolution of the source domain). This rule is important because only a match between the user inputs (in the form of a reference identifier) and a presented identifier enables the client to be sure that the certificate can legitimately be used to secure the connection. However, an interactive client MAY provide a configuration setting that enables a human user to explicitly specify a particular host name or domain name (called a target domain) to be checked for connection purposes. [TP] what I thought was about to be raised here was a contradiction that RFC4985 is all about information gotten from a DNS retrieval whereas the wording of s5.1 in this I-D the source domain name and service type ... MUST NOT be derived from the user inputs in an automated fashion (e.g., ... discovered through DNS resolution ... would appear to exclude DNS resolution. If DNS resolution is off limits, then RFC4985 would appear not to apply. RFC 4985 provides the client with a way to authenticate a host that it believes is authorized to provide a specific service in the target domain. It does not matter from where the client has obtained that authorization information or whether that information is trustworthy. A client may very well do an insecure DNS lookup to discover what host is providing the requested service. The client would then contact that host
RE: Review of draft-saintandre-tls-server-id-check
Peter said: Aha, I see the source of confusion. I think the first sentence of Section 5.1 is better written as follows: When the connecting application is an interactive client, construction of the reference identifier SHOULD be based on the source domain and service type provided by a human user (e.g. when specifying the server portion of the user's account name on the server or when explicitly configuring the client to connect to a particular host or URI as in [SIP-LOC]) and SHOULD NOT be based on a target domain derived from the user inputs in an automated fashion (e.g., a host name or domain name discovered through DNS resolution of the source domain). We want to make sure that the reference identifier is based on the source (user-provided) domain, not the target (automatically-derived) domain, except perhaps in several well-defined and carefully-limited scenarios. Peter [BA] IMHO, this text is much clearer. Thanks! -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [xmpp] Review of draft-saintandre-tls-server-id-check
Peter said: If that's the logic, I'd at the least like to see a 4985bis spec make that clear, because IMHO it's not spelled out now. RFC 4985 refers to authentication of service discovery in Sections 1 and 2. Section 1 states: This document specifies a name form for inclusion in X.509 certificates that may be used by a certificate relying party to verify that a particular host is authorized to provide a specific service within a domain. RFC 2782 [N3] defines a DNS RR (Resource Record) for specifying the location of services (SRV RR), which allows clients to ask for a specific service/protocol for a specific domain and get back the names of any available servers. Existing name forms in X.509 certificates support authentication of a host name. This is useful when the name of the host is known by the client prior to authentication. When a server host name is discovered through DNS RR lookup query based on service name, the client may need to authenticate the server's authorization to provide the requested service in addition to the server's host name. While DNS servers may have the capacity to provide trusted information, there may be many other situations where the binding between the name of the host and the provided service needs to be supported by additional credentials. Current dNSName GeneralName Subject Alternative name form only provides for DNS host names to be expressed in preferred name syntax, as specified by RFC 1034 [N4]. This definition is therefore not broad enough to allow expression of a service related to that domain. Section 2 states: Even though this name form is based on the service resource record (SRV RR) definition in RFC 2782 [N3] and may be used to enhance subsequent authentication of DNS-based service discovery, this standard does not define any new conditions or requirements regarding use of SRV RR for service discovery or where and when such use is appropriate. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Review of draft-saintandre-tls-server-id-check
That was in fact my original question. Section 5.1 states that the source domain and service type MUST be provided by a human user, and can't be derived. Yet in an SRV or DDDS lookup, it is not the source domain that is derived, it is the target domain. Given that, it's not clear to me what types of DNS resolutions are to be discouraged. As noted elsewhere, RFC 4985 appears to require matching of the source domain/service type to the SRV-ID in the certificate. Such a process would be consistent with a match between user inputs (the source domain and service type) and the presented identifier (the SRV-ID). Yet, Section 5.1 states: When the connecting application is an interactive client, the source domain name and service type MUST be provided by a human user (e.g. when specifying the server portion of the user's account name on the server or when explicitly configuring the client to connect to a particular host or URI as in [SIP-LOC]) and MUST NOT be derived from the user inputs in an automated fashion (e.g., a host name or domain name discovered through DNS resolution of the source domain). This rule is important because only a match between the user inputs (in the form of a reference identifier) and a presented identifier enables the client to be sure that the certificate can legitimately be used to secure the connection. However, an interactive client MAY provide a configuration setting that enables a human user to explicitly specify a particular host name or domain name (called a target domain) to be checked for connection purposes. [TP] what I thought was about to be raised here was a contradiction that RFC4985 is all about information gotten from a DNS retrieval whereas the wording of s5.1 in this I-D the source domain name and service type ... MUST NOT be derived from the user inputs in an automated fashion (e.g., ... discovered through DNS resolution ... would appear to exclude DNS resolution. If DNS resolution is off limits, then RFC4985 would appear not to apply. Does s5.1 of the I-D mean what it appears to say? Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Review of draft-saintandre-tls-server-id-check
Peter St. Andre said: an SRV record can be used for two quite different purposes: 1. To point from an application service name to a particular host/domain name in the same administrative domain (e.g., _imap._example.com points to mailhost.example.com for its IMAP service). 2. To delegate an application service name to a hosting provider outside in the administrative domain of the application service (e.g., example.com delegates its IMAP service to apps.example.net). As I see it, RFC 4985 glosses over the foregoing distinction. [BA] It took some adjustment for me, but as I understand it, the underlying assumption of RFC 4985 is that if the certificate is considered valid by RFC 5280 path validation (e.g. chains to a valid trust anchor, etc.) then delegations both within and outside the source administrative domain can be validated. This logic, if pursued, could apply beyond SRV RR validation, to things like NAPTR validation via a URI/IRI in the certificate. Scoping (EKUs, name constraints, etc.) is a different question. Peter also said: However, the question arises: what is the client supposed to check if an SRV lookup for _imap._example.com yields apps.example.net? My reading of RFC 4985 leads me to think that the certificate presented by apps.example.net is supposed to contain an SRV-ID of _imap.example.com, which means roughly this certificate indicates that this provider is authorized to provide IMAP service for the example.com domain. (How the certification authority determines that the delegation is indeed authorized is outside the scope of this I-D.) [BA] That's also my reading of RFC 4985, but I'll let others more knowledgeable (like the author) weigh in. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-saintandre-tls-server-id-check
I reviewed draft-saintandre-tls-server-id-check. In a number of instances, this document is vague on the verification of an SRV-ID, and in one instance, it appears to contradict RFC 4985, even though it does not update that document. Section 2.1 states: o An SRV-ID can be either direct (provided by a user) or more typically indirect (resolved by a client) and is restricted (can be used for only a single application). This is consistent with RFC 4985 Section 2.1 which states: The SRVName, if present, MUST contain a service name and a domain name in the following form: _Service.Name Yet, Section 5.1 states: When the connecting application is an interactive client, the source domain name and service type MUST be provided by a human user (e.g. when specifying the server portion of the user's account name on the server or when explicitly configuring the client to connect to a particular host or URI as in [SIP-LOC]) and MUST NOT be derived from the user inputs in an automated fashion (e.g., a host name or domain name discovered through DNS resolution of the source domain). This rule is important because only a match between the user inputs (in the form of a reference identifier) and a presented identifier enables the client to be sure that the certificate can legitimately be used to secure the connection. However, an interactive client MAY provide a configuration setting that enables a human user to explicitly specify a particular host name or domain name (called a target domain) to be checked for connection purposes. [BA] As I understand RFC 4985, the SRV-ID provided in the target certificate is to be matched against components (service name and domain name) of the SRV RR obtained via lookup within the source domain. As a result, I don't believe that RFC 4985 is consistent with this advice (e.g. the reference identifier is not matched against the SRV-ID). Section 4.1 is not as clear as it could be on this point, given that it talks about both matching of the source domain and the target domain: 4. When checking a reference identifier against a presented identifier, the client (a) MUST match the source domain (or, in some cases, target domain) of the identifiers and (b) MAY also match the service type of the identifiers. Implementation Note: Naturally, in addition to checking identifiers, a client might complete further checks to ensure that the server is authorized to provide the requested service. However, such checking is not a matter of verifying the application service identity presented in a certificate, and therefore methods for doing so (e.g., consulting local policy information) are out of scope for this document. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Review of draft-ietf-dna-simple
In that scenario, it makes sense to me. However, if the RA advertises the same prefixes would there be a reason to mark all addresses as inoperable? -Original Message- From: Ralph Droms [mailto:rdroms.i...@gmail.com] Sent: Thursday, August 19, 2010 2:50 PM To: Bernard Aboba Cc: IETF Discussion Subject: Re: Review of draft-ietf-dna-simple Bernard - this text is, in my opinion, intended to sync the internal data structures if the RA advertises different prefixes than the last time the host was attached to this link: On reception of a Router Advertisement the host MUST go through the SDAT and mark all the addresses associated with the router (both SLAAC and DHCPv6 acquired) as inoperable. - Ralph On Aug 18, 2010, at 6:19 PM 8/18/10, Bernard Aboba wrote: Overall, I think the document the document looks good. Some comments: Section 2.4 The host uses a combination of unicast Neighbor Solicitations (NSs), multicast Router Solicitations (RSs) and DHCPv6 message exchanges in order to determine whether previously encountered routers are present on the link, and if they are not, acquire the new configuration information. [BA] Since DHCPv6 operation isn't affected, it might be more accurate to say the following: The host uses a combination of unicast Neighbor Solicitations (NSs) and multicast Router Solicitations (RSs) in order to determine whether previously encountered routers are present on the link, in which case an existing configuration can be reused. If previously encountered routers are not present then either IPv6 Stateless Address Autoconfiguration and/or DHCPv6 is used for configuration. Section 5.3 o Sending of neighbor discovery and/or DHCPv6 probes [BA] When Simple DNA is used, neighbor discovery probes are always sent, and DHCPv6 operation is not affected. So I'd change this to: . Sending of neighbor discovery probes. 5.7.2. Receiving Router Advertisements On reception of a Router Advertisement the host MUST go through the SDAT and mark all the addresses associated with the router (both SLAAC and DHCPv6 acquired) as inoperable. The host MUST then process the Router Advertisement as specified in Section 6.3.4. of [RFC4861]. [BA] I don't understand why the first sentence is necessary in the case where the addresses have already been confirmed via Neighbor probes. Section 5.11 If a response is received to any unicast Neighbor Solicitation or Router Solicitation message, pending retransmissions MUST be canceled. [BA] Why should receipt of a response to a Neighbor Solicitation cancel pending retransmissions of a Router Solicitation? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-ietf-dna-simple
Overall, I think the document the document looks good. Some comments: Section 2.4 The host uses a combination of unicast Neighbor Solicitations (NSs), multicast Router Solicitations (RSs) and DHCPv6 message exchanges in order to determine whether previously encountered routers are present on the link, and if they are not, acquire the new configuration information. [BA] Since DHCPv6 operation isn't affected, it might be more accurate to say the following: The host uses a combination of unicast Neighbor Solicitations (NSs) and multicast Router Solicitations (RSs) in order to determine whether previously encountered routers are present on the link, in which case an existing configuration can be reused. If previously encountered routers are not present then either IPv6 Stateless Address Autoconfiguration and/or DHCPv6 is used for configuration. Section 5.3 o Sending of neighbor discovery and/or DHCPv6 probes [BA] When Simple DNA is used, neighbor discovery probes are always sent, and DHCPv6 operation is not affected. So I'd change this to: . Sending of neighbor discovery probes. 5.7.2. Receiving Router Advertisements On reception of a Router Advertisement the host MUST go through the SDAT and mark all the addresses associated with the router (both SLAAC and DHCPv6 acquired) as inoperable. The host MUST then process the Router Advertisement as specified in Section 6.3.4 http://tools.ietf.org/html/draft-ietf-dna-simple-16#section-6.3.4 . of [RFC4861 http://tools.ietf.org/html/rfc4861 ]. [BA] I don't understand why the first sentence is necessary in the case where the addresses have already been confirmed via Neighbor probes. Section 5.11 If a response is received to any unicast Neighbor Solicitation or Router Solicitation message, pending retransmissions MUST be canceled. [BA] Why should receipt of a response to a Neighbor Solicitation cancel pending retransmissions of a Router Solicitation? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-housley-two-maturity-levels-00
Overall, I'd suggest that the goal should be to merely recognize and document the maturity levels that already exist in practice, not to change them. My understanding is that the process for advancing from Experimental to Proposed today largely involves review of implementation experience (e.g. the results of the experiment), and in Transport, a demonstration that the proposal is not catastrophic to the Internet. Sometimes the changes required can be substantial (e.g. changes made in EAP going from RFC 2284 to 3748, and in SIP going from 2543 to 3261), but I don't think this should hinder advancement to Proposed. Problems in interoperability are often addressed in bis documents, so we shouldn't require a detailed interop assessment either (that's for Draft level). I can imagine blocking advancement of a bis to Proposed in only a limited number of situations, such as where there was no implementation experience. Today recycling at Experimental is pretty rare -- if there is motivation for a bis typically this implies that there was interest/usefulness. From: Yoav Nir [mailto:y...@checkpoint.com] Sent: Tuesday, June 22, 2010 1:00 AM To: Bernard Aboba Cc: ietf@ietf.org Subject: Re: draft-housley-two-maturity-levels-00 I like this proposal, but there should be a (relatively) easy process to advance from Experimental to Proposed, especially if implementation experience shows no need for bits-on-the-wire changes. We should be able to say that for a particular experimental RFC there have been this many independent implementation, and they interoperate OK, and only so-and-so clarifications need to be added, and the document is ready for Proposed. On Jun 21, 2010, at 9:09 PM, Bernard Aboba wrote: Russ, I'd also like to think you for revisiting this topic. I support the recommendation to eliminate the Standard maturity level, and also agree with your recommendation on Maturity Level 2 (similar to Draft Standard). We need more thought on what to do with the other levels though. In practice, we often see a document initial go to Proposed Standard, then go through a bis to enable clarifications and interop improvements. Often these changes are too substantial to enable advancement to Draft, but they nevertheless represent an important advancement in status. I'd like to see some way that this advancement can be recognized formally. Also, in some areas (e.g. Transport) the first stage is publication of an Experimental RFC. These documents are published with the understanding that implementation experience will be incorporated into a future revision. So perhaps the hierarchy should be: a. Experimental. b. Proposed Standard (e.g. a bis). c. Interoperable Standard/Draft Standard. ATT1..txt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-00
Russ, I'd also like to think you for revisiting this topic. I support the recommendation to eliminate the Standard maturity level, and also agree with your recommendation on Maturity Level 2 (similar to Draft Standard). We need more thought on what to do with the other levels though. In practice, we often see a document initial go to Proposed Standard, then go through a bis to enable clarifications and interop improvements. Often these changes are too substantial to enable advancement to Draft, but they nevertheless represent an important advancement in status. I'd like to see some way that this advancement can be recognized formally. Also, in some areas (e.g. Transport) the first stage is publication of an Experimental RFC. These documents are published with the understanding that implementation experience will be incorporated into a future revision. So perhaps the hierarchy should be: a. Experimental. b. Proposed Standard (e.g. a bis). c. Interoperable Standard/Draft Standard. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Operations Directorate Review of draft-ietf-hip-hiccups-02
I reviewed the document draft-ietf-hip-hiccups-02.txt in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Experimental This document defines a new HIP (Host Identity Protocol) packet type called DATA. HIP DATA packets are used to securely and reliably convey arbitrary protocol messages over the Internet and various overlay networks, without running the HIP base exchange beforehand. This results in the HIP DATA packet requiring less overhead but without the DoS protection afforded by the base exchange. Is the document readable? Yes. Does it contain nits? idnits 2.12.04 tmp/draft-ietf-hip-hiccups-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): == You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/) Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : No issues found here. Miscellaneous warnings: -- The document date (March 4, 2010) is 97 days in the past. Is this intentional? Checking references for intended status: Experimental No issues found here. Summary: 0 errors (**), 1 warning (==), 1 comment (--). Is the document class appropriate? Yes. Is the problem well stated? Section 6 describes the rationale for use of the HIP DATA packet: HIP currently requires always that the four-message base exchange is executed at the first encounter of hosts that have not communicated before. This may add additional RTTs (Round Trip Time) to protocols based on a single message exchange. However, the four-message exchange is essential to preserve the half-stateless DoS protection nature of the base exchange. The use of the HIP DATA packet defined in this document reduces the initial overhead in the communications between two hosts at the expense of decreasing DoS protection. Therefore, applications SHOULD NOT use HIP DATA packets in environments where DoS attacks are believed to be an issue. For example, a HIP-based overlay may have policies in place to control which nodes can join the overlay. Any particular node in the overlay may want to accept HIP DATA packets from other nodes in the overlay given that those other were authorized to join the overlay. However, the same node may not want to accept HIP DATA packets from random nodes that are not part of the overlay. The type of data to be sent is also relevant to whether the use of a HIP DATA packet is appropriate. HIP itself does not support fragmentation but relies on underlying IP-layer fragmentation. This may lead to reliability problems in the case where a message cannot be easily split over multiple HIP messages. Therefore, applications in environments where fragmentation could be an issue SHOULD NOT generate too large HIP DATA packets that may lead to fragmentation. The implementation SHOULD check the MTU of the link before sending the packet and if the packet size is larger than MTU it SHOULD signal to the upper-layer protocol if the packet results in to a ICMP error message. Note that there are environments where fragmentation is not an issue. For example, in some HIP-based overlays, nodes can exchange HIP DATA packets on top of TCP connections that provide transport-level fragmentation and, thus, avoid IP-level fragmentation. Is the problem really a problem? Yes. In situations where a host will be intiating transactions with hosts it has
Review of draft-ietf-sip-domain-certs-06
I reviewed the document draft-ietf-sip-domain-certs-06 in general and for its operational impact. -- Review Summary: Intended status: Proposed Standard This document describes how to construct and interpret certain information in a X.509 PKIX-compliant certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of a SIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of certificates. Is the document readable? Yes. Does it contain nits? idnits 2.12.02 tmp/draft-ietf-sip-domain-certs-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): == You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/) Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: == The document date (March 22, 2010) is 19 days in the past. Is this intentional? Checking references for intended status: Proposed Standard (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4366 (ref. '4') (Obsoleted by RFC 5246) == Outdated reference: A later version (-04) exists of draft-drage-sip-essential-correction-03 Summary: 1 error (**), 4 warnings (==), 0 comments (--). Is the document class appropriate? Yes. Is the problem well stated? Yes. Section 3 describes what the extent of guidance provided in RFC 3261 with respect to identity placement, as well as issues that have been encountered, not just within SIP, but also within other usages: With respect to certificates for TLS, RFC3261 (Section 26.3.1) says: Proxy servers, redirect servers and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname. . . . However, the lack of guidelines in RFC3261 on exactly where to put identities -- in the subjectAltName field or carried as a Common Name (CN) in the Subject field -- of a X.509 certificates created ambiguities. Following the accepted practice of the time, legacy X.509 certificates were allowed to store the identity in the CN field of the certificate instead of the currently specified subjectAltName extension. Lack of further guidelines on how to interpret the identities, which identity to choose if more than one identity is present in the certificate, the behavior when multiple identities with different schemes were present in the certificate, etc. lead to ambiguities when attempting to interpret the certificate in a uniform manner for TLS use. Is the problem really a problem? Yes. Does the document consider existing solutions? Not sufficiently. RFC 3261 was published in June 2002, and RFC 3280 was published in April 2002, nearly eight years ago. In the meantime, thousands of SIP proxies and servers have been deployed utilizing TLS along with certificate authentication. Given the extensive existing deployment, backward compatibility is a major issue. Since RFC 3261 did not provide much guidance, implementers typically followed the general guidance in RFC 3280. The best advice for interoperability is be liberal in what you accept, conservative in what you send. The document does not always follow this advice. For example, Section 6 of the document allows SSPs to place the identity in either the subjectAltName or Subject fields (e.g. liberal in what you send): When assigning certificates to authoritative servers, a SIP service provider MUST ensure that the SIP domain used to reach the server appears as an identity in the subjectAltName field, or for compatibility with existing certificates, the Subject field of the certificate. Yet at the same time, Section 7.1 makes acceptance of identities in the CN field optional (e.g. conservative in what
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
Hadriel Kaplan said: Howdy, This may not be within the normal rules of etiquette, but I will re-iterate my issues with this draft which I raised when it was discussed in RAI. 1) The mechanism does not scale, for large SSP's. (is this only meant for small deployments?) Expecting every UA to keep a permanent SIP Subscription to config change servers is unreasonable. Either the UA makes this Subscription directly to the Server(s), in which case there will be a large volume of keep-alives just to keep NAT pinholes alive; or it makes it through edge proxies, in which case it's a lot of SIP messaging both in the sense of keeping the Subscribe dialog alive but more importantly at the worst possible time: during avalanche restarts. Either way, it's not good. All this state and signaling is to achieve what? So that once a year or so we can tell UA's to do another HTTP Get so they change one of their config settings, or upgrade their firmware?? How is that cost-burden justified? Do most other applications keep permanent connections for such changes? Not as far as I can tell. They poll on a (very) infrequent interval. 2) I would be ok with (1) if it was optional, so only providers that wanted it had to pay for it, but as far as I can tell the mechanism *requires* implementation of this SIP Subscription service. Maybe I'm reading it wrong? Section 2.5.1 says the HTTP response MUST have the Link header, with a SIP URI, and if the Subscription attempt fails then it has to start again, etc. Seems to me you're requiring/mandating a nice-to-have-feature, and an expensive and complicated one at that. Why? -hadriel [BA] I agree with your assessment. This is one of those situations where (infrequent) polling scales better. That is how currently most OS update mechanisms work; they poll the update servers at intervals orders of magnitude longer than NAT refresh times (e.g. weekly or daily at most), with randomized polling times. That way there is no need to maintain NAT bindings, and no danger of flash crowds. Yes, it might take a while to bring all the clients up to the latest version, but if you've got any substantial client population, then you need to spread out the updates anyway to control the load on the update servers. In my experience, even where NOTIFY is used to provide update notifications today, SUBSCRIBE is not. Yes, that is non-standard, but I think it demonstrates concern about the overhead relating to SIP subscription/refresh. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-radext-status-server (Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol) to Informational RFC
An editorial comment on Section 2. Section 2 Status-Server packets are sent by a RADIUS client to a RADIUS server in order to test the status of that server. A Message-Authenticator attribute MUST be included so as to provide per-packet authentication and integrity protection. A single Status-Server packet MUST be included within a UDP datagram. RADIUS proxies MUST NOT forward Status-Server packets. Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy or server, the destination of a Status-Server packet is set to the IP address of the server which is being tested. As a result, the client is provided with an indication of the status of that server only, since no RADIUS proxies are on the path between the RADIUS client and server. Since servers respond to a Status-Server packet without examining the User-Name attribute, the response to a Status-Server packet cannot be used to infer any information about the reachability of specific realms. A RADIUS server or proxy implementing this specification SHOULD respond to a Status-Server packet with an Access-Accept (authentication port) or Accounting-Message (accounting port). An Access-Challenge response is NOT RECOMMENDED. An Access-Reject response MAY be used. The list of attributes that are permitted in Status-Server and Access-Accept packets responding to Status-Server packets are provided in the Section 6. [BA] These three paragraphs are a bit disjoint. Recommend changing it to the following: Status-Server packets are sent by a RADIUS client to a RADIUS server in order to test the status of that server. The destination of a Status-Server packet is set to the IP address of the server that is being tested. A single Status-Server packet MUST be included within a UDP datagram. A Message-Authenticator attribute MUST be included so as to provide per-packet authentication and integrity protection. RADIUS proxies or servers MUST NOT forward Status-Server packets. A RADIUS server or proxy implementing this specification SHOULD respond to a Status-Server packet with an Access-Accept (authentication port) or Accounting-Response (accounting port). An Access-Challenge response is NOT RECOMMENDED. An Access-Reject response MAY be used. The list of attributes that are permitted in Status-Server and Access-Accept packets responding to Status-Server packets are provided in the Section 6. Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy or server, the client is provided with an indication of the status of that server only, since no RADIUS proxies are on the path between the RADIUS client and server. Since servers respond to a Status-Server packet without examining the User-Name attribute, the response to a Status-Server packet cannot be used to infer any information about the reachability of specific realms. To: ietf-annou...@ietf.org From: iesg-secret...@ietf.org CC: radius...@ops.ietf.org Subject: Last Call: draft-ietf-radext-status-server (Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol) to Informational RFC Date: Mon, 15 Mar 2010 12:42:32 -0700 The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol ' draft-ietf-radext-status-server-06.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-03-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17334rfc_flag=0 -- to unsubscribe send a message to radiusext-requ...@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: http://psg.com/lists/radiusext/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-ietf-isms-dtls-tm-09.txt
I reviewed the document draft-ietf-isms-dtls-tm-09.txt in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Proposed Standard This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. Is the document readable? Yes. Does it contain nits? idnits 2.12.01 tmp/draft-ietf-isms-dtls-tm-09.txt: tmp/draft-ietf-isms-dtls-tm-09.txt(532): Line has weird spacing: '...patcher v ...' Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): == You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : No issues found here. Miscellaneous warnings: -- The document has a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. Does it really need the disclaimer? Checking references for intended status: Proposed Standard (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246) Summary: 0 errors (**), 1 warning (==), 2 comments (--). Is the document class appropriate? Yes. Is the problem well stated? Yes. Is the problem really a problem? Yes. Does the document consider existing solutions? The ISMS WG has considered approaches other than (D)TLS, such as SSH. Does the solution break existing technology? No. Does the solution preclude future activity? No. Is the solution sufficiently configurable? Yes. Section 7 defines a MIB for the TLS transport model which supports configuration. Can performance be measured? How? The MIB defined in Section 7 should enable monitoring of aspects of TLS transport model performance. Does the solution scale well? (D)TLS should scale well as long as the server has a session cache of sufficient size. Is Security Management discussed? The entire document is about security management. From: Tina TSOU [mailto:t...@huawei.com] Sent: Monday, March 15, 2010 2:41 AM To: bernard_ab...@hotmail.com Cc: Ron Bonica; Dan Romascanu Subject: Operations Directorate Review Hello, As a member of the Operations Directorate you are being asked to review the following IESG work item for it's operational impact. IETF Last Call: http://www.ietf.org/internet-drafts/draft-ietf-isms-dtls-tm-09.txt Please provide comments and review to the Ops-dir mailing list (ops-...@ietf.org) before the next IESG telechat, and include the authors of the draft as well. The IESG telechat agenda is below, you could find the exact date, i.e. the expected deadline for the feedback of your review. https://datatracker.ietf.org/iesg/agenda/ For a list of questions to be answered in an OPS-DIR review see Appendix A in RFC 5706. Note that not all questions may apply to all documents, and some other items may be identified by the OPS-DIR reviews. The status of Operations Directorate Review could be found http://trac.tools.ietf.org/area/ops/trac/wiki/Directorates You could wiki it when you finish the review. Thank you, Tina
Review of draft-ietf-l3vpn-mvpn-considerations
I reviewed the document draft-ietf-l3vpn-mvpn-considerations in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Doesn't say More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks. To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. Is the document readable? Yes. Does it contain nits? While there were no errors, idnits did spit out quite a few warnings: idnits 2.12.01 tmp/draft-ietf-l3vpn-mvpn-considerations-06.txt: tmp/draft-ietf-l3vpn-mvpn-considerations-06.txt(366): Found possible IPv4 address '3.4.1.1' in position 8; this doesn't match the suggested documentation address ranges specified in RFC 3330 (or successor): blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3); or the suggested 233.252.0.0/24 example multicast address range. tmp/draft-ietf-l3vpn-mvpn-considerations-06.txt(369): Found possible IPv4 address '3.4.1.2' in position 8; this doesn't match the suggested documentation address ranges specified in RFC 3330 (or successor): blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3); or the suggested 233.252.0.0/24 example multicast address range. tmp/draft-ietf-l3vpn-mvpn-considerations-06.txt(372): Found possible IPv4 address '3.4.1.3' in position 8; this doesn't match the suggested documentation address ranges specified in RFC 3330 (or successor): blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3); or the suggested 233.252.0.0/24 example multicast address range. tmp/draft-ietf-l3vpn-mvpn-considerations-06.txt(531): Line has weird spacing: '... or the us...' Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): == You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to http://www.ietf.org/id-info/checklist : == There are 3 instances of lines with non-RFC3330-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: No issues found here. Checking references for intended status: Proposed Standard (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4364' is mentioned on line 747, but not defined 'Options A, B and C (as described in section 10 of [RFC4364]) are...' == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-09 == Outdated reference: A later version (-13) exists of draft-rosen-vpn-mcast-12 == Outdated reference: A later version (-10) exists of draft-ietf-pim-sm-linklocal-08 Summary: 0 errors (**), 7 warnings (==), 0 comments (--). Is the document class appropriate? No class is stated, so I can't tell. Is the problem well stated? Yes. Is the problem
Re: WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)
I agree with Dan. The added complexity seems to have very little if any benefit. Moreover, the existing IKEv2/EAP design has some very desirable cryptographic properties (such as the ability to support PFS even in situations where weak EAP methods are used) that could go by the wayside. Dan Harkins said: Hi Jari, I don't believe the simpler solution will increase code size or complexity when compared to the the reuse EAP solution. In fact, it will be less on both counts. In both cases the core key exchange will have to be implemented and in both cases some configuration glue will be needed. But in the reuse EAP solution there is the added code to implement an EAP client and its accompanying state machine, which no IKEv2 gateway currently needs to implement. In addition, a true EAP server, and accompanying state machine, will need to be implemented and IKEv2 gateways will no longer get away with just being a pass through authenticator. The reuse EAP solution will also have to implement some new fragmentation/reassembly code since EAP methods (like ones supporting weak shared secrets) have to roll-their-own. The reuse EAP solution will also have to implement other, unneeded, exchanges (which is why the roundtrips/overhead are greater). When you compare the two, it really is obvious that trying to use EAP in this case increases code size and complexity versus just doing the exchange as part of IKE. EAP is attractive because it provides a generic authentication solution, but here there is really only one type of authentication to do-- using a weak shared secret. It is also attractive because authentication can be centralized with one server serving many network access points. But in this case both sides must have possession of the shared secret and both sides must be capable of initiating the exchange so use of a centralized server is not possible. So all of the attractive features of EAP do not apply and we're left with the undesirable features of EAP-- duplicate identity exchanges, yet more fragmentation/reassembly code, and pointless overhead. I don't think it's better architecturally to reuse EAP in this situation. EAP is a network access protocol where one side attempts to obtain network access from another. There are strict roles played in EAP. In this situation there are no roles and creating a host-to-host SA or network- to-network SA is not really the same thing as obtaining network access. There are some things that EAP is not appropriate for and this is one of them. regards, Dan. On Fri, February 19, 2010 5:39 am, Jari Arkko wrote: Pasi, (Adding the working group mailing list to the discussion; previous discussion has been at i...@ietf.org.) You're right that implementing a weak shared secret EAP method (both the EAP peer and EAP server roles) on both IPsec nodes, combined with the EAP mutual authentication work item (also in the new charter) could be used in this situation, and would result in roughly the same functionality (perhaps with slightly more roundtrips/other overhead -- but that's probably not a critical factor here). OK. And yes, I agree about the significance of roundtrips. NEW: However, user-configured shared secrets are still useful for many other IPsec scenarios, such as authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either peer can initiate an IKEv2 SA. While it would be possible to use EAP in such situations (by having both peers implement both the EAP peer and the EAP server roles of an EAP method intended for weak shared secrets) with the mutual EAP-based authentication work item (above), a simpler solution may be desirable in many situations. This formulation is better than what we had previously. I can live with this. But for the record, I am still surprised that I am the only one worried about this. In my view this additional solution, while perhaps simpler on its own, will increase code size and complexity for most implementations. For instance, a device that serves remote access clients has to implement at least parts of EAP. To support gateway-gateway weak secrets it now has to add support for another, completely different authentication mode and associated configuration mechanisms policies. Architecturally, it would be better to rely on few general solutions than to build special case simpler solutions that taken together, actually become more complex. Not to mention the impact on interoperability. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list
Review of draft-jabley-reverse-servers-01
I reviewed the document draft-jabley-reverse-servers-01 in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Standards Track This document specifies a naming scheme for the nameservers which serve the zones IN-ADDR.ARPA and IP6.ARPA in the DNS. Is the document readable? Yes. Does it contain nits? Output of IDNITS: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: No issues found here. Checking nits according to http://www.ietf.org/ID-Checklist.html: ** There are 12 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: == The copyright year in the IETF Trust and authors Copyright Line does not match the current year Checking references for intended status: Proposed Standard (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3152 (Obsoleted by RFC 3596) Summary: 1 error (**), 1 warning (==), 1 comment (--). Is the document class appropriate? Not sure. The naming scheme for servers that host the IN-ADDR.ARPA and IP6.ARPA seems like an operational issue, that might be more appropriate for a BCP than a Proposed Standard. Is the problem well stated? Yes. Section 1 states: The naming scheme specified in this document allows IN-ADDR.ARPA and IP6.ARPA be delegated to two different sets of nameservers, to facilitate operational separation of the infrastructure used to serve each zone. This separation might help ensure that an operational failure of IN-ADDR.ARPA servers does not impact IPv6 reverse lookups as collateral damage, for example. Is the problem really a problem? Yes. As noted in Section 1: The secure and stable hosting of the IN-ADDR.ARPA and IP6.ARPA zones is critical to the operation of the Internet, since many applications rely upon timely responses to reverse lookups to be able to operate normally. Does the document consider existing solutions? Yes. As noted in Section 1: At the time of writing, the IN-ADDR.ARPA zone is served by a subset of the DNS root servers, and IP6.ARPA by servers operated by APNIC, ARIN, ICANN, LACNIC and the RIPE NCC (see Appendix A). Does the solution break existing technology? No. Does the solution preclude future activity? No. Is the solution sufficiently configurable? Yes. Can performance be measured? How? Yes. Presumably existing DNS performance measurement techniques can be used to determine how well the scheme is working. Does the solution scale well? Yes. As noted in Section 2, the authors have thought through issues such as fate sharing, compression and points of failiure: The IN-ADDR-SERVERS.ARPA zone will be delegated to the same set of servers as IN-ADDR.ARPA. IPv4 and IPv6 glue records for each of those servers will be added to the ARPA zone. The IN-ADDR-SERVERS.ARPA and IN-ADDR.ARPA zones are delegated to the same servers since they are both dedicated for a single purpose and hence can reasonably share fate. All servers in the set are named under the same domain to facilitate label compression. Since glue for all servers will exist in the ARPA zone, the use of a single domain does not present a practical single point of failure. Is Security Management
RE: WG Review: Internet Wideband Audio Codec (codec)
Roni Even said: I do not think that the IETF should accept any work because people want to do it, if this is the case a group of people can come and ask to start working on any idea they have that has some relation to the Internet. IETF should accept work that is in scope for of the IETF and for which there is enough knowledge to evaluate the work by the participants. I would like to suggest two principles that appear to have guided decisions of this kind in the past: 1. The scope of the Internet Engineering Task Force (IETF) is work relating to Internet Engineering. 2. Standards work is best carried out within the organization that potential active participants prefer to work in. These principles suggest that if proposed work relates to Internet Engineering and a group of people are both interested in doing work in the IETF and have demonstrated competence, then that work can be chartered within the IETF. Witness the chartering of the TRILL and CAPWAP WGs. In these cases, participants expressed a preference to do the work within the IETF, and demonstrated the competence to take it on. Those WGs were chartered within IETF. Similar decisions were made with respect to WGs that subsequently landed in the Sub-IP Area. There have also been situations where work was clearly related to Internet Engineering, but it was also clear that participants preferred to do that work elsewhere. In that case, the IETF transferred the work to another SDO (see RFC 4663). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Internet Wideband Audio Codec (codec)
+1 On 5 Jan 2010 Patrik Falstrom wrote: I agree with this. On 4 jan 2010, at 23.40, Sam Hartman wrote: I've been thinking about the codec issue for a while. I think it is really desirable for the IETF to charter this group. I don't think the charter should prohibit the working group from selecting some existing codec nor should it prohibit doing new work in this space. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-lha-gssapi-delegate-policy
I reviewed the document draft-lha-gssapi-delegate-policy-04 in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Standards Track Delegating user credentials to an insufficiently trusted party is problematic. Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator of a Kerberos realm to indicate that a particular service is trusted for delegation. This specificatinon adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC 2743). 1. Is the document readable? Yes. 2. Does it contain nits? Yes. Some grammatical nits: Section 2 to allow and administrator - to allow an administrator It would is desirable - It would be desirable Idnits complains of a potential boilerplate error: idnits 2.11.15 tmp/draft-lha-gssapi-delegate-policy-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ** The document seems to lack an IETF Trust Provisions (12 Sep 2009) Section 6.b License Notice -- however, there's a paragraph with a matching beginning. Boilerplate error? trust-12-sep-2009 Section 6.b paragraph 3 text: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. ... text found in draft: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. ^ Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: No issues found here. Checking nits according to http://www.ietf.org/ID-Checklist.html: No issues found here. Miscellaneous warnings: == The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.). trust-12-sep-2009 Section 6.c.iii text: This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Checking references for intended status: Proposed Standard (See RFCs 3967 and 4897 for information about using normative references to
RE: Review of draft-ietf-dna-simple-09
Suresh said: I will swap the text regarding SLLAO for 4.5.1 and 4.5.2. Does this work? Yes. I think the changes got swapped, somehow. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-ietf-dna-simple-09
Review of draft-ietf-dna-simple-09 I have reviewed draft-ietf-dna-simple. Overall, I believe this document still contains significant technical issues that need to be addressed before it would be suitable for publication as a Proposed Standard. In particular, the version of the document sent to IETF last call does not incorporate fixes to issues listed in the WG issue tracker as fixed. This raises the possibility that changes from WG last call were not properly applied or even that the wrong version of the document may have been sent to IETF last call. Given the potential problems, a careful check needs to be made of the changes between -08 and -09 to make sure that resolutions to WG last call and AD review comments were properly applied. Technical Abstract This document provides simple procedures for detecting network attachment in IPv6 hosts, and procedures for routers to support such services. [BA] My understanding was that the goal of Simple DNA was to avoid changes to routers. Given that, what router procedure need to be specified? Section 2.4 2.4. DNA Roles Detecting Network Attachment is performed by hosts by sending IPv6 neighbor discovery and router discovery messages to routers after connecting to a network. It is desirable that routers adopt procedures which allow for fast unicast Router Advertisement (RA) messages. Routers that follow the standard neighbor discovery procedure described in [RFC4861] will delay the router advertisement by a random period between 0 and MAX_RA_DELAY_TIME (defined to be 500ms) as described in Section 6.2.6 of [RFC4861]. This delay can be significant and may result in service disruption. Please note that support for fast unicast RAs is not necessary since the simple dna procedure can continue to work using the NS/NA exchange, which will complete earlier than the RA arrives. The host detects that the link-layer may have changed, and then simultaneously probes the network with Router Solicitations (RSs) and Neighbor Solicitations (NSs). The host uses advertisements to determine if the routers it currently has configured are still available. Additionally, on links with no statelessly configured addresses, the host may make use of DHCPv6 procedures to identify an operable address. [BA] This paragraph does not describe the situations in which RA delays will be significant. Clarity would be enhanced by describing this. The description of the role of DHCPv6 in this section appears to conflict with the description in Section 4.6. Section 4.6 discusses use of Neighbor Discovery probing in parallel with DHCPv6 probing, implying that RS probing is not used. This section implies that DHCPv6 probing is only done after a combination of RS and NS probing does not result in a statelessly configured address. Perhaps the best way to explain the interaction is to think of simple DNA as independent of DHCPv6. That is, implementation of simple DNA does not change the DHCPv6 state machine or timers; implementations continue to send the same DHCPv6 packets in the same situations and with the same timing as they did without simple DNAv6. The only new wrinkle is the potential for conflicts between simple DNA and DHCPv6, in which case the information obtained via DHCPv6 wins. This is true regardless of whether an implementation waits for an RA before deciding whether to use DHCPv6, or whether it sends DHCPv6 packets regardless of the state of the 'M' and 'O' bits in the RA. My suggested text is as follows: 2.4. DNA Overview Detecting Network Attachment is performed by hosts after detecting a link-layer up indication. The host simultaneously sends multicast Router Solicitations (RSs) and unicast Neighbor Solicitations (NSs) in order to determine whether previously encountered routers are present on the link. Hosts implementing simple DNA may also send DHCPv6 packets, as described in Section 4.6. Since simple DNA does not modify the DHCPv6 protocol or state machine, the operation of DHCPv6 is unchanged. Routers that follow the standard neighbor discovery procedure described in [RFC4861] will delay the router advertisement by a random period between 0 and MAX_RA_DELAY_TIME (defined to be 500ms) as described in Section 6.2.6 of [RFC4861]. Hosts implementing simple DNA can detect the presence of a previously encountered router using unicast Neighbor Solicitations. As a result, where the host with a valid configuration is returning to a previously encountered link, delays in the sending of a Router Advertisement (RA) will not delay configuration as long as NS probing is successful. However in situations where the host is attaching to a link for the first time, or where it does not have a valid IP address on the link, it will be dependent on the receipt of an RA for stateless
Review of draft-ietf-idnabis-defs
I have reviewed draft-ietf-idnabis-defs.Overall, I found the document clear and easy to read. Some specific comments below. Technical Section 2.2 When discussing the DNS, this document generally assumes the terminology used in the DNS specifications [RFC1034] [RFC1035] as modified by [RFC1123] and [RFC2181]. The term lookup is used to describe the combination of operations performed by the IDNA2008 protocol and those actually performed by a DNS resolver. The process of placing an entry into the DNS is referred to as registration, similar to common contemporary usage in other contexts. [BA] Does the term registration apply to DNS dynamic update, or only to the initial process of placing an entry? Section 2.3.1 Labels within the class of R-LDH labels that are not prefixed with xn-- are also not valid IDNA-labels. To allow for future use of mechanisms similar to IDNA, those labels MUST NOT be processed as ordinary LDH-labels by IDNA-conforming programs and SHOULD NOT be mixed with IDNA-labels in the same zone. [BA] If one were to write a conformance test based on this statement, what kinds of behavior would be prohibited in an IDNA-conforming program? For example, does not processed as ordinary LDH-labels imply that an that these labels are not looked up? Is there also an implication that these labels should not be registered? Section 2.3.2.3 Clients issuing queries or interpreting responses cannot be assumed to have any knowledge of zone-specific restrictions or conventions. [BA] Does this statement also extend to clients issuing DNS dynamic updates? Editorial Section 2.3.2.1 Specifically, for IDNA-aware applications, the three allowed categories are A-label, U-label, and NR-LDH-label. Of the reserved LDH labels (R-LDH-labels) only A-labels are valid for IDNA use. [BA] A similar statement is made in Section 2.3.1; you might consider consolidating this paragraph into that section. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-ietf-idnabis-tables
I reviewed draft-ietf-idnabis-tables-07.My comments are enclosed below. Technical Section 5.1 IANA is to keep a list of the derived property for the versions of Unicode that is released after (and including) version 5.1. The derived property value is to be calculated according to the specifications in sections Section 2 and Section 3 and not by copying the non-normative table found in Appendix B. [BA] This seems to imply that IANA will do the calculation itself, rather Than just registering the results of a calculation made by someone else. Is that correct? Editorial Section 1 For example, a character can have its Unicode General_Category value change from So to Sm, or from Lo to Ll, without affecting the algorithm results. Moreover, even if such changes were to result, the BackwardCompatible list (Section 2.7) can be adjusted to ensure the stability of the results. [BA] Lo and L1 are not defined until the next section. Would it make sense to define these terms earlier on? Some code points need to be allowed in exceptional circumstances, but should be excluded in all other cases; these rules are also described in other documents. The most notable of these are the the Join [BA] the the - the Section 5.1 in sections Section 2 and Section 3 [BA] Should this be Sections 2 and 3? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-ietf-dime-diameter-cmd-iana
I reviewed the document draft-ietf-dime-diameter-cmd-iana-01.txt in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Standards Track This document aligns the rules for allocation of Diameter commands with those for allocation of Diameter application IDs. Is the document readable? [BA] There is considerable text duplicated between the Abstract and Section 1. The repetition makes the document less readable than it should be. My recommendation is to provide a shortened abstract, leaving most of the material now in the Abstract to Secton 1. Does it contain nits? There are a number of grammar and spelling issues, but only 1 warning found in the NIT checker: idnits 2.11.14 tmp/draft-ietf-dime-diameter-cmd-iana-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: No issues found here. Checking nits according to http://www.ietf.org/ID-Checklist.html: No issues found here. Miscellaneous warnings: No issues found here. Checking references for intended status: Proposed Standard (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-19) exists of draft-ietf-dime-rfc3588bis-18 Summary: 0 errors (**), 1 warning (==), 0 comments (--). Is the document class appropriate? [BA] Yes. Does the document consider existing solutions? [BA] Yes. The abstract of the document describes the problem, which is that allocation of Diameter Application IDs does not require IETF consensus, while defining new Diameter commands does, per RFC 3588. This creates an incentive for SDOs to define new applications on existing commands rather than requesting assignment of new command codes. The document revises RFC 3588 allocation procedures, in order to align the allocation procedures. Does the solution break existing technology? [BA] The document argues that the disparity in allocation procedures for Diameter Application IDs and commands creates incentives for utilizing new Application IDs, rather than new Diameter commands. By making aligning the allocation of Diameter commands to Application IDs, the incentives for poor design choices might be addressed. However, my take is that the underlying problem is that Diameter contains too many extensibility mechanisms that aren't well enough defined. We have extensibility via Attributes (which can have the M bit set), Application IDs, and commands. RADIUS has somehow gotten by largely with Attribute extensibility, with additional commands defined on occasion. By creating so many extensibility mechanisms, it seems to me that Diameter has invited upon itself a host of interoperability problems that have not plagued its predecessor. Given this, it's hard for me to tell whether the proposed changes will really help without first understanding how RFC 3588bis plans to clarify the issues with Diameter extensibility. IMHO, neither Diameter Application IDs nor new commands should be requested unless they are absolutely necessary, due to their effects on interoperability. Does the solution preclude future activity? [BA] I found the allocation procedures for vendor-specific command codes somewhat odd. While command code allocations are handled on a First Come, First Served basis, the request SHOULD include a reference to a publicly available specification. Not all SDOs make their specifications publicly available immediately upon publication, so it is not clear that they can satisfy this requirement. Also, if the allocation is to a vendor, then
Re: Local Beijing people response - RE: Request for community guidance on issue concerning a future meeting of the IETF
Steve Crocker said: Are you suggesting the IETF is not mature enough to meet in China? After watching this thread for a while, I am beginning to be convinced. The IETF as an organization is mature enough to meet anywhere. However, IETF participation is open, so that attempting to predict the behavior of IETF participants is as difficult as predicting the behavior of anyone on the planet. In the past (at a Washington DC meeting), IETF participants were detained after wandering into a restricted area. After their release, the story warranted little more than a chuckle from those involved, and had no ramifications for the IETF or its leadership. A good test for a potential site is to contemplate the ramifications were such an incident to be repeated at the proposed location. IETF participants are responsible for their own words and actions. The IETF makes no effort (and has no mechanism) to control their conformance to local laws or customs, and the host and IETF cannot assume any associated risks. Further evidence of the potential behavior exhibited by IETF participants is available on the appeals page: http://www.iab.org/appeals/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Request for community guidance on issue concerning a future meeting of the IETF
The IETF does not and cannot make any warranties relating to the political views, manners or behavior of attendees. The attendees are responsible for their own actions, and the IETF has no ability ensure their conformance to local laws or customers. If attendees violate the laws or customs of the host country, they may face consequences -- but they're on their own. So if the question is whether the IETF should sign any agreement that takes responsibility for the behavior attendees, I'd say that this is a bad idea. It's not really an issue of politics -- I'd say the same thing if the meeting were being held in Palm Beach and the city requested that the IETF take responsibility for ensuring that participants conformed to the dress code (no white after labor day!). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-zorn-radius-pkmv1-05.txt
Yes, this looks good. Date: Wed, 26 Aug 2009 22:36:42 -0400 Subject: Re: draft-zorn-radius-pkmv1-05.txt From: d3e...@gmail.com To: g...@net-zen.net CC: bernard_ab...@hotmail.com; ietf@ietf.org; sec...@ietf.org Looks OK to me, Donald On Wed, Aug 26, 2009 at 9:24 PM, Glen Zorng...@net-zen.net wrote: … PKMv1 has some fairly serious security problems that are described here: http://www2.computer.org/portal/web/csdl/doi/10.1109/SNPD.2008.138 So I think the question is whether this document can make those serious security problems even worse, in a way that has not already been documented. AFAICT, this is not the case. The use of RADIUS doesn’t improve the security of PKMv2 but it doesn’t seem to reduce it either . The suggested use of the MS-MPPE-Send-Key Attribute may be problematic but seems pretty much unavoidable at present. I'd suggest that the document reference the known security issues that are covered in other documents, such as the ones above and others (such as RFC 3579) that describe weaknesses in the MPPE-Key attributes. OK The Security Considerations section now looks like this: 7. Security Considerations Section 4 of RFC 3579 [RFC3579] discusses vulnerabilities of the RADIUS protocol. Section 3 of the paper Security Enhancements for Privacy and Key Management Protocol in IEEE 802.16e-2005 [SecEn] discusses the operation and vulnerabilities of the PKMv1 protocol. If the Access-Request message is not subject to strong integrity protection, an attacker may be able to modify the contents of the PKM-Cryptosuite-List Attribute, weakening 802.16 security or disabling data encryption altogether. If the Access-Accept message is not subject to strong integrity protection, an attacker may be able to modify the contents of the PKM-Auth-Key Attribute. For example, the Key field could be replaced with a key known to the attacker. Although it is necessary for a plaintext copy of the Key field in the PKM-AUTH-Key Attribute to be transmitted in the Access-Accept message, this document does not define a method for doing so securely. In order to transfer the key securely, it is RECOMMENDED that it be encapsulated in an instance of the MS-MPPE-Send-Key Attribute [RFC2548]; however, see section 4.3.4 of RFC 3579 [RFC3579] for details regarding weaknesses in the encryption scheme used. Is that OK? … ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-zorn-radius-pkmv1-05.txt
Donald Eastlake said: Doing a little more research, 802.16e-2005, which you don't reference, does begin to touch on this by at least specifying how EAP fits into 802.16. [BA] As I understand it, this document is focused entirely on PKMv1, which does not support EAP. So it does not apply to IEEE 802.16e-2005. That's quite an important point, since there are existing specifications (from WiMAX forum) that deal extensively with IEEE 802.16e/AAA interactions. If that point is not very clear from the document, then it needs to be. [Donald Eastlake] If above you are saying that the security of these new RADIUS attributes can be evaluated entirely based on a knowledge of RADIUS, I do not agree with this. [BA] PKMv1 has some fairly serious security problems that are described here: http://www2.computer.org/portal/web/csdl/doi/10.1109/SNPD.2008.138 So I think the question is whether this document can make those serious security problems even worse, in a way that has not already been documented. I'd suggest that the document reference the known security issues that are covered in other documents, such as the ones above and others (such as RFC 3579) that describe weaknesses in the MPPE-Key attributes. [Donald Eastlake] If above, you are saying is that there is no need for there to be some explanation, in your draft or in some document referenced by it, of how RADIUS fits into 802.16 and that people who don't have an a priori knowledge of this should just keep their noses out of your document, I don't agree with that either. [BA] I would suggest that the document could reference the RADIUS specifications from WiMAX forum that relate to IEEE 802.16e-2005 to make it clear that operation with that updated specification is out of scope. [Donald Eastlake] RADIUS can be used by an IEEE 802.16 Base Station, acting as an EAP Authenticator, to communicate with a remote Authentication Server to authenticate 802.16 Subscriber Stations and support 802.16 Privacy Key Management Version 1. This document defines a set of additional RADIUS Attributes which are designed to enable this support. [BA] Since PKMv1 does not support EAP, mentioning EAP in the abstract doesn't make sense. [Donald Eastlake] Is it really such a burden, to provide some security context for what you are doing, to say something like: Security consideration for IEEE 802.16 appear in Section 7 of 802.16-2004 and of 802.16e-2005. Security considerations for RADIUS extensions appear in RFC 2869. or the like? [BA] Since this document applies only to PKMv1, mentioning IEEE 802.16e would probably be confusing. Mentioning RFC 3579 (which supercedes RFC 2869 with respect to EAP/RADIUS) might make sense. EMAILING FOR THE LEAST WORST BAD Join me___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Comments on draft-peterson-rai-rfc3427bis-02.txt
Section 2.1 All SIP extensions considered in SIPCORE must be standards track. Is this statement will really necessary in this document, or would it be better suited for inclusion in the SIPCORE WG charter? Typical IETF working groups do not live forever; SIPCORE's charter is however open-ended in order to allow it to remain the place where core SIP development will continue. In the event that the SIPCORE working group has closed and no suitable replacement or follow-on working group is active (and this specification also has not been superseded), then when modifications to the core SIP protocol are proposed the RAI Area Directors will the use the non-working group standards track document process (described in Section 6.1.2 of RFC 2026 [RFC2026]) using the SIPCORE mailing list and designated experts from the SIP community for review. The IETF will remain the home of extensions of SIP and the rest of this document. The rate of growth of extensions of any protocol in the IETF is hoped to be low. It would be helpful for this paragraph to explicitly state that the ADs have the ability to specify a successor to SIPCORE with respect to the above responsibilities. That would allow a new WG to take on these responsibilities without requiring a revision to RFC3427bis. While it does not have the traditional deliverables of a working group, DISPATCH may at the discretion of its chairs adopt milestones such as the production of charter text for a BoF or working group, Is this really at the discretion of the chairs of DISPATCH? Typically, production of charter text for a BoF or WG is handled by the chairs of that BoF or WG, not some other WG. Instead, the registration of SIP headers in Informational IETF specifications, or in documents outside the IETF, is now permitted under the Designated Expert (per RFC5226) criteria. Good idea. Note that the deprecation of the P- header process does not alter processes for the registration of SIP methods, URI parameters, response codes, or option tags. Do all option tags really need to be standards track? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard
I also support publication of this document as a Standards Track RFC. A substantial number of existing protocols (including TLS, EAP-TLS, PEAP, EAP-TTLSv0, DTLS/SRTP and EAP FAST) already utilize the technology in this document, which has proven quite useful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication UsingOnly A Password) to Proposed Standard
Some technical comments on the document. Overall, I noticed that two important capabilities are not currently supported: 1. Support for identity privacy. Currently the specification does not support this, which could be a concern, particularly in Europe. Privacy implies the negotiation of a secure channel prior to the EAP method-specific identity exchange. In the case of EAP-PWD addressing this would seem to imply the need to do two key exchanges, which leads to another issue: 2. Fast reconnect. The protocol as currently designed does not support fast reconnect, the ability to reauthenticate using an exchange that is faster and computationally lighter weight. Where the administrative domain contains a substantial number of users, the existing specification could impose a heavy computational load on the server requiring acceleration hardware, as well as imposing substantial delays on embedded clients. This would be particularly apparent in situations where privacy is desired, which could potentially double the computational load. One way to address this (at the expense of PFS) would be to support fast reconnect, where the previously negotiated master key is refreshed via an exchange of nonces, and mutual proof of possession is demonstrated. An example of this approach is the session resume functionality in TLS. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard
I also support publication of this document as a Standards Track RFC. A substantial number of existing protocols (including TLS, EAP-TLS, PEAP, EAP-TTLSv0, DTLS/SRTP and EAP FAST) already utilize the technology in this document, which has proven quite useful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard
RMS said: How should an SDO respond? I'm not sure. I'm only sure that I don't like getting DoSed, either into dropping a standard or into not implementing it for fear of infringing. [BA] A bit of history. While this draft generalizes the notion of a TLS key material exporters, the concept is basic to key derivation within TLS, as well as within applications depending on TLS. As an example, DTLS/SRTP as well as TLS-based EAP methods (including EAP-TLS, PEAP, EAP-TTLSv0, EAP-FAST, etc.) utilize TLS key material export. So if we only have the option of dropping the standard or not implementing it then we are left with an unpleasant choice indeed. [RMS] It is better to have no standard than have a standard that invites people into danger. Outstanding! Some corollaries: It is better to sleep in the outdoors than to live in a house that could fall down in an earthquake. It is better to starve than to eat food that could make you sick. It is better to walk with bare feet than to wear shoes that could cause blisters. It is better to ride a horse than to drive a car that could crash. It is better to be wear a blindfold than to watch a movie that could turn out to be unpleasant. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: review of draft-zorn-radius-pkmv1-04.txt
I believe the intent was related to RADIUS security. The guidelines document could be updated to address this. The rationale behind the original exemption was that security required changes on both the RADIUS client and server. Therefore the RADIUS server would need a code change anyway, regardless of whether the attributes were complex or simple. That rationale applies not just to RADIUS security but also to authentication mechanisms, many of which were previously implemented with complex attributes (e.g. CHAP). So I'm not clear that we're talking about a loophole here. encapsulation using RFC 2548 MPPE-Key attributes... I was unclear about how this is supposed to work. Is the idea to apply the MPPE-Key encryption mechanism to the attribute specified in the draft, or is the idea to actually use the MPPE-Key attributes themselves? If the former, more detail should be provided. If the latter, is it necessary to define two attribute formats or would it be simpler to go with one? If the RFC 2548 MPPE-Key attributes are used, is the format the same as that defined in RFC 2548 (just a wrapped key) or is the wrapping applied to a complex attribute? a four octet Integer should be used instead of a two octet data type (which doesn't exist in RADIUS) As I recall, the security exemption didn't apply to creation of new RADIUS data types, correct? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using Only A Password) to Proposed Standard
I would like to comment on the process aspect of this IETF last call. A subsequent post will provide comments on the protocol. Overall, I believe that the appropriate process for handling this document is not to bring it to IETF last call as an individual submission, but rather to charter a work item within an IETF WG. There are two current EAP method drafts that are based on zero-knowledge algorithms: 1. http://tools.ietf.org/html/draft-harkins-emu-eap-pwd (this document) 2. http://tools.ietf.org/html/draft-sheffer-emu-eap-eke Previously there was also an EAP method submission utilizing SRP: 3. http://tools.ietf.org/html/draft-ietf-pppext-eap-srp-03 All three of these documents were slated for inclusion on the IETF standards track. Given the number of EAP method RFCs that have already been published, I do not believe that it serves the Internet community for the IETF to publish multiple EAP method specifications of a similar genre on the Standards Track, while bypassing the WG process. If the standardization of zero-knowledge algorithms is an important area of work for the IETF (and I believe this to be true), then work in this area should be chartered as a working group work item, with the goal to select a single method for standardization. Prior to the EMU WG re-charter, Dan Harkins made an argument for chartering of work in this area. His arguments were sound then, and they are (even more) sound today. However, Dan did not succeed in getting the work added to the EMU WG charter. It is time for the IESG to re-consider its decision to delay standardization of zero knowledge algorithms, which was made in the earlier part of the decade. If the EMU WG is not suitable for handling this work, then another security area WG should be created for the purpose. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-ietf-sip-eku
I reviewed the document draft-ietf-sip-eku in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Proposed Standard This specification documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with SIP. 1. Is the document readable? Yes. 2. Does it contain nits? 3. Is the document class appropriate? Previous EKU extensions (such as [RFC 4334]) have not been widely deployed, due to the additional operational complexity they would have introduced, and the limited benefits. Given this, and the potential interoperability impact of this document, the Experimental classification would probably be more appropriate. 4. Does the document consider existing solutions? I don't believe that the document adequately discusses transition issues, or existing practices. See below for detailed comments. 5. Does the solution break existing technology? In situations where there are pre-existing certificates without the EKU extensions, this specification could result in interoperability problems if the local policy is not carefully implemented. One concern is that the language on local policy could be used by implementers to justify refusing to support existing certificate formats. I do not think that the document adequately addresses how to manage the transition. For example, during an interim period, it would be necessary for implementations to support both legacy certificates as well as certificates with the new extensions. At some point, once the legacy certificates have expired, local policy could be changed to require only certificates with extensions. At various points in the document, I was unsure whether the term implementations was referring to implementations of this specification, or pre-existing implementations. See below for detailed comments. 6. Does the solution preclude future activity? Adding this EKU extension on the Standards Track is likely to create a need for backward compatibility in the future. 7. Is the solution sufficiently configurable? The document does not discuss what kinds of local policy are appropriate in various situations or how the local policy can be configured or managed. Some additional discussion in this area would be helpful. 8. Can performance be measured? The document does not address performance measurement. 9. Does the solution scale well? Introducing this extension into an existing large scale certificate deployments would require a lot of care, to avoid interoperability problems. 10. Is Security Management discussed? The document does not discuss how certificate interoperability issues can be dealt with, or how operational problems could be diagnosed. Detailed comments Section 3 A Certificate Authority issuing a certificate whose purpose is to bind a SIP domain identity without binding other non-SIP identities MUST include an id-kp-SIPdomain attribute in the Extended Key Usage extension value (see Section 3.1). [BA] Question: What is the definition of SIP domain identity? This is not included in the terminology section. Section 4 Section 7.1 of Domain Certificates in the Session Initiation Protocol [8] contains the steps for finding an identity (or a set of identities) in an X.509 certificate for SIP. In order to determine whether the usage of a certificate is restricted to serve as a SIP certificate only, implementations MUST perform the step given below as a part of the certificate validation: [BA] Not sure how the first sentence relates to the rest of the paragraph. Is the intent to suggest that the process for finding the identity needs to be carried out in order to make the determination? If so, then [8] would be a normative reference. o If the certificate does not contain any EKU values (the Extended Key Usage extension does not exist), it is a matter of local policy whether or not to accept the certificate for use as a SIP certificate. [BA] There are a large number of existing certificates issued without these EKUs. In situations in
Review of draft-ietf-sip-eku
I reviewed the document draft-ietf-sip-eku in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Proposed Standard This specification documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with SIP. 1. Is the document readable? Yes. 2. Does it contain nits? 3. Is the document class appropriate? Previous EKU extensions (such as [RFC 4334]) have not been widely deployed, due to the additional operational complexity they would have introduced, and the limited benefits. Given this, and the potential interoperability impact of this document, the Experimental classification would probably be more appropriate. 4. Does the document consider existing solutions? I don't believe that the document adequately discusses transition issues, or existing practices. See below for detailed comments. 5. Does the solution break existing technology? In situations where there are pre-existing certificates without the EKU extensions, this specification could result in interoperability problems if the local policy is not carefully implemented. One concern is that the language on local policy could be used by implementers to justify refusing to support existing certificate formats. I do not think that the document adequately addresses how to manage the transition. For example, during an interim period, it would be necessary for implementations to support both legacy certificates as well as certificates with the new extensions. At some point, once the legacy certificates have expired, local policy could be changed to require only certificates with extensions. At various points in the document, I was unsure whether the term implementations was referring to implementations of this specification, or pre-existing implementations. See below for detailed comments. 6. Does the solution preclude future activity? Adding this EKU extension on the Standards Track is likely to create a need for backward compatibility in the future. 7. Is the solution sufficiently configurable? The document does not discuss what kinds of local policy are appropriate in various situations or how the local policy can be configured or managed. Some additional discussion in this area would be helpful. 8. Can performance be measured? The document does not address performance measurement. 9. Does the solution scale well? Introducing this extension into an existing large scale certificate deployments would require a lot of care, to avoid interoperability problems. 10. Is Security Management discussed? The document does not discuss how certificate interoperability issues can be dealt with, or how operational problems could be diagnosed. Detailed comments Section 3 A Certificate Authority issuing a certificate whose purpose is to bind a SIP domain identity without binding other non-SIP identities MUST include an id-kp-SIPdomain attribute in the Extended Key Usage extension value (see Section 3.1). [BA] Question: What is the definition of SIP domain identity? This is not included in the terminology section. Section 4 Section 7.1 of Domain Certificates in the Session Initiation Protocol [8] contains the steps for finding an identity (or a set of identities) in an X.509 certificate for SIP. In order to determine whether the usage of a certificate is restricted to serve as a SIP certificate only, implementations MUST perform the step given below as a part of the certificate validation: [BA] Not sure how the first sentence relates to the rest of the paragraph. Is the intent to suggest that the process for finding the identity needs to be carried out in order to make the determination? If so, then [8] would be a normative reference. o If the certificate does not contain any EKU values (the Extended Key Usage extension does not exist), it is a matter of local
OPS-DIR review of draft-ietf-speermint-requirements
I reviewed the document draft-ietf-speermint-requirements-07.txt in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Informational This document discusses requirements for session peering in voice, presence, instant messaging and multimedia. 1. Is the document readable? In general, the document provides a readable listing of requirements. However additional background on the requirements could have been provided, which would make the document easier to understand. 2. Does it contain nits? Yes. See below. 3. Is the document class appropriate? Yes. 4. Does the document consider existing solutions? This is a requirements document, so it largely focuses on requirements rather than solutions. However, there are instances where the document does not sufficiently discuss existing practices. For example, in Section 3.2 the document refers to limitations of DNS in providing different responses based on the querier: However, this DNS-based solution may be limited in cases where the DNS response varies based on who sends the query (peer-dependent SBEs, see below) Notes on solution space: For advertising peer-dependent SBEs (peer variability), the solution space based on [RFC3263] is under specified and there are no know best current practices. Is DNS the right place for putting data that varies based on who asks? Content Distribution Networks (CDNs) have quite a bit of operational experience with use of DNS to provide data that varies based on who asks. Information on existing approaches is provided in RFCs 3466, 3568, and 3570. CDNs also have experience in use of application re-direct for global load balancing. I was therefore somewhat surprised that this document did not discuss or reference work on CDNs. While the document focuses on layer 5 peering, it does seem like it would be worthwhile to at least have some discussion of lower layer load balancing techniques such as anycast (e.g. RFC 4786), which when combined with DNS can be used to provide data that varies based on who asks. 5. Does the solution break existing technology? This is a requirements document, so that it doesn't specify solutions. However, as described above I would like to see a more in-depth discussion of the capabilities and limitations of existing technology. 6. Does the solution preclude future activity? As a requirements document, the goal is to guide future activity. 7. Is the solution sufficiently configurable? While the document focuses on requirements rather than solutions, I do think it would be valuable to discuss the potential service provider objectives in more detail. For example, specifying exit and entry points is a means, not an end. Within the CDN space, we have come to understand that the best server may depend on whether the goal is to optimize latency or throughput. 8. Can performance be measured? Performance metrics are discussed in Appendix A.1. 9. Does the solution scale well? Given that the document focuses on requirements, the scalability of the (as yet to be determined) solution is out of scope. 10. Is Security Management discussed? Section 5 discusses security requirements. Note that since the publication of RFC 3263, a number of additional documents have been dealt with the issue of TLS session establishment. These documents (such as draft-ietf-sip-sips) may be worth referencing in addition to RFC 3263 within Section 3.2: The mechanisms recommended for locating a peer's SBE MUST be able to convey how a peer should initiate secure session establishment. Notes : some mechanisms exist. For example, the required protocol use of SIP over TLS may be discovered via [RFC3263]. idnits 2.11.11 tmp/draft-ietf-speermint-requirements-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License
RE: Review of draft-ietf-geopriv-http-location-delivery
New (Barnes): A Device that conforms to this specification MAY omit support for HTTP authentication [RFC2617] or cookies [RFC2965]. Because the Device and the LIS may not necessarily have a prior relationship, it is RECOMMENDED that that the LIS not require a Device to authenticate, either using the above HTTP authentication methods or TLS client authentication. The previous text related to LIS behavior (e.g. not refusing authorization based on lack of authentication). This suggested text relates to the client (e.g. that it may omit support for HTTP authentication, TLS client auth or cookies). In the previous text, the LIS could challenge the client, but was restricted in its options if the client failed authentication. In this text, the LIS is recommended not to even try to authenticate the client. A compromise approach would be for the LIS to make the choice on whether to challenge the device based on the nature of the request. Devices only supporting requests that cannot be challenged (e.g. requests utilizing implicit IP address identification) could omit support for HTTP authentication. However, if a device were to make a request of another type (e.g. utilizing HELD extensions), the LIS could challenge it and therefore the device would need to support HTTP authentication. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC Review ofdraft-ietf-geopriv-http-location-delivery-14.txt
Martin Thomson said: Regarding client authentication, there are a number of constraints on the solution that lead to the current choice. The most relevant constraint is that there may be no prior relationship between LIS (network operator) and device. In designing for arbitrary access networks, this constraint was considered important. This prevents use of pre-shared keys such as would be required for digest/basic [1] [2]. Thus we come to the choice of IP address and return reachability. I believe that the draft addresses the impact of this choice adequately; Section 9.3 seems most directly applicable here, but other places touch on this choice where it’s relevant. If you do not believe that there are relevant points that are not brought up, I’d encourage you to send text.[BA] I understand that the IP address is being used as an identifier. With respect to the lack of no prior relationship between the access network and the device, presumably this is to acommodate situations of anonymous access and/or no authentication (e.g. non-authenticated Ethernet). If so, it might be useful to add a sentence to that effect. Regarding alternative identifiers, there is an extension document that talks about use of alternative identifiers, and I do believe that this particular point CAN be addressed in an extension. For those, authentication (other than return reachability, if you consider that to be a form of authentication) can be made a requirement.[BA] I'm trying to understand how the mechanics of authentication could be accomodated. Since authentication can't be required for authorization where an IP address is used for identification, does this imply that a 407 response is not permissible in that situation? Or is it just saying that if a 407 is returned in that situation, then authorization needs to be provided? Does that imply that a 407 could be returned in other situations (e.g. an alternative identifier)? Just trying to understand the scope of the prohibition and how implementations are expected to behave. I’ll address the other more substantive point regarding identity in PIDF-LO in another (longer) mail. --Martin [1] The document is clear on its use of digest/basic: the LIS MUST NOT rely on it being used. That’s in recognition of the above constraint. In other words, the LIS MUST NOT fail a request because the device did not provide authentication. That doesn’t prevent it from being used in an extension to the protocol. [2] Of course, there are networks where the constraint might not be applicable. For instance, access to the network could be restricted using some form of authentication. However, a device that accesses a LIS within those networks must also be aware that it needs to present this same authentication information when talking to a LIS. We cannot guarantee that a device will do this, since compliance would need to be a prerequisite of network access; designers of future access networks might choose to add this to their network design. From: Bernard Aboba Sent: Tuesday, 9 June 2009 5:48 AM To: b...@estacado.net; ietf@ietf.org Subject: Re: Gen-ART LC Review ofdraft-ietf-geopriv-http-location-delivery-14.txt Mary Barnes said: It doesn't explicitly forbid the use of digest authn, but if it can't depend on client support, then it can't really base any decision on it. The question isn't just about an authorization decision. There is also the issue about what the LIS is supposed to do with client authentication information if it is provided. How is this information reflected in the PIDF-LO that is returned in a HELD response? Ben Campbell said: The part I was trying to highlight was the lack of client device authentication, not LIS authentication. If I read 9.1 right, it only covers authentication of the LIS. I assume there is no expectation that client devices present TLS certs to the LIS, right? There are multiple potential identities that a device (and a user of that device) could assert and authenticate against. Currently the document only talks about use of the IP address as an identity, and says little about authentication. However, the PIDF-LO objects that are returned in HELD responses contain multiple identification fields. Currently the document says very little about how these fields are filled in. That leaves the protocol under-specified. Issues of protocol behavior that are this basic shouldn't be left to an extensions document. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited
Re: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14.txt
Mary Barnes said: It doesn't explicitly forbid the use of digest authn, but if it can't depend on client support, then it can't really base any decision on it. The question isn't just about an authorization decision. There is also the issue about what the LIS is supposed to do with client authentication information if it is provided. How is this information reflected in the PIDF-LO that is returned in a HELD response? Ben Campbell said: The part I was trying to highlight was the lack of client device authentication, not LIS authentication. If I read 9.1 right, it only covers authentication of the LIS. I assume there is no expectation that client devices present TLS certs to the LIS, right? There are multiple potential identities that a device (and a user of that device) could assert and authenticate against. Currently the document only talks about use of the IP address as an identity, and says little about authentication. However, the PIDF-LO objects that are returned in HELD responses contain multiple identification fields. Currently the document says very little about how these fields are filled in. That leaves the protocol under-specified. Issues of protocol behavior that are this basic shouldn't be left to an extensions document. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-ietf-geopriv-http-location-delivery
Review of HTTP Enabled Location Delivery (HELD) http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery As stated in Section 1 of the document: This document describes a protocol that can be used to acquire Location Information (LI) from a LIS within an access network. This specification identifies two types of location information that may be retrieved from the LIS. Location may be retrieved from the LIS by value, that is, the Device may acquire a literal location object describing the location of the Device. The Device may also request that the LIS provide a location reference in the form of a location URI or set of location URIs, allowing the Device to distribute its LI by reference. Both of these methods can be provided concurrently from the same LIS to accommodate application requirements for different types of location information. In the case of location by value, the object returned in the HELD response (a PIDF-LO) is subsequently conveyed using a protocol such as that defined in draft-ietf-sip-location-conveyance In the case of location by reference, the reference will be to a PIDF-LO object. While this document does define the protocol by which the PIDF-LO or reference is conveyed, it does not provide much in the way of guidance as to how identity-related fields within the PIDF-LO are filled in, or how those fields potentially relate to aspects of the protocol identification and/or authentication mechanisms. As a result, it seems difficult to analyze the protocol with respect to its security properties, or even with respect to conformance to requirements established in [RFC3693] and [RFC4119]. Specifically, Section 10 Examples does not include any examples that utilize the identification fields supported by the PIDF-LO object format as indicated by [RFC4119] and [RFC5491], such as entity, device or deviceID. Section 9 does not talk about the linkage between these parameters and the security authentication mechanisms, leaving it unclear as to whether it is possible to launch a cut and paste attack -- insertion of a PIDF-LO returned to entity A into a message sent by another entity B. Even if the returned PIDF-LO object or reference were to be signed by the LIS and subsequently verified, such an attack would not appear to be precluded unless the identity of requester A were to be bound to the returned PIDF-LO in some way. Identification and Authentication facilities Section A.1 describes the use of the IP address as the primary source of identity: HELD uses the IP address of the location request message as the primary source of identity for the requesting device or target. This identity can be used with other contextual network information to provide a physical location for the Target for many network deployments. There may be network deployments where an IP address alone is insufficient to identify a Target in a network. However, any necessary identity extensions for these networks is beyond the scope of this document. Based on this, one might assume that the IP address would be placed into the deviceID field of the PIDF-LO object, but the document does not say this explicitly. Section 8 of the document states: The LIS MUST NOT rely on device support for cookies [RFC2965] or use Basic or Digest authentication [RFC2617]. The logic relating to the prohibition on the use of HTTP authentication is not explained. Does this prohibition apply to all forms of identity that can be used by HELD, or only to deployments utilizing IP address identification? Is the prohibition related to the need to support unauthenticated emergency calling? If so, then it's worth noting some of the issues that have arisen: http://www.ietf.org/mail-archive/web/ecrit/current/msg06378.html Requirements A Presence-based GEOPRIV Location Object Format [RFC4119] Section 2.1 states: The GEOPRIV requirements [10] (or REQ for short) specify the need for a name for the person, place or thing that location information describes (REQ 2.1). PIDF has such an identifier already: every PIDF document has an entity attribute of the 'presence' element that signifies the URI of the entity whose presence the document describes. Consequently, if location information is contained in a PIDF document, the URI in the entity attribute of the 'presence' element indicates the target of that location information (the 'presentity'). The URI in the entity attribute generally uses the pres URI scheme defined in [3]. Such URIs can serve as unlinkable pseudonyms (per REQ 12). PIDF optionally contains a 'contact' element that provides a URI where the presentity can be reached by some means of communication. Usually, the URI scheme in the value of the 'contact' element gives some sense of how the presentity can be reached; if it uses the SIP URI scheme, for example, SIP can be used, and so on. Location information can be provided without
Re: Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP
While I consider much of this document thoughtful and useful, there are a number of assertions in Section 1 which concern me. Section 1.2 of the document states that this document does not make a recommendation with respect to publication requirements: Any decision to make a Management Considerations section a mandatory publication requirement for IETF documents is the responsibility of the IESG, or specific area directors, or working groups, and this document avoids recommending any mandatory publication requirements. For a complex protocol, a completely separate draft on operations and management might be appropriate, or even a completely separate WG effort. However, at the same time Section 1 provides a potential justification for imposing such a requirement: Often when new protocols or protocol extensions are developed, not enough consideration is given to how the protocol will be deployed, operated and managed. Retrofitting operations and management mechanisms is often hard and architecturally unpleasant, and certain protocol design choices may make deployment, operations, and management particularly hard. Since the ease of operations and management may impact the success of IETF protocols, this document provides guidelines to help protocol designers and working groups consider the operations and management functionality needed by their new IETF protocol or protocol extension at an earlier phase. This paragraph caught my eye, since the case studies in RFC 5218 challenge some of our beliefs about what elements contribute to the success of a protocol. One of the takeaways from RFC 5218 is that the IETF may be setting the wrong bar for new protocol design efforts (too many requirements, but not necessarily the right ones), rather than focusing enough scrutiny on successful protocols undergoing revision. While we like to think that it is critical for new protocol designs to take issues such as security and OM into account from the start, a look back at the evolution of some of the Internet's most successful protocols teaches us that it is more important that a new protocol solve an important problem and that it get enough of the basic design right (e.g. extensibility) to be able to add those critical capabilities later. If that is true, then it is important that this document differentiate between those OM considerations that need to be thought through in an initial design, and those that need to be handled in a subsequent revision effort (where presumably the bar would be a lot higher). Given this, I would urge the authors to rethink much of Section 1, so as to carefully differentiate those issues that can cripple a new protocol versus those issues that are essential for global deployment of a successful protocol. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-opsawg-operations-and-management
Henning said: Before adding higher hurdles to the Proposed stage, maybe we can identify whether such a mechanism would have solved real issues in recent protocol design cases, or just delayed an already exceedingly long process even more. Maybe BCPs imposing new requirements on WGs need a Delay Impact Assessment section... There are not many cases that come to mind where the neglect of management concerns in a new protocol design turned out to be a show stopper (e.g. something that couldn't be fixed later). For example, I can't think of any cases where lack of a MIB or accounting support at the time of initial RFC publication was directly responsible for a failure to thrive. There may be some instances where a protocol was not optimized for certain scenarios (e.g. deployment on cellular networks) so that additional work was needed to develop OM extensions for those scenarios. But in those cases, maybe the most important deployment scenarios would not necessarily have been predictable in advance. And even if they were, would it have been better to have delayed the publication of the initial RFC for months or years until the issue was addressed? Maybe others can come up with examples where these concerns turned out to be critical, but at the moment, I'm mostly drawing a blank. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Beyond reproach, accountability and regulation
The problem here is that a consensus based approach is a lousy way to deal with large complicated problems where the number of stakeholders is very large and only a tiny minority of them are able to participate in the IETF process in an effective manner. This may well be true, but in many respects it reminds me of the Winston Churchill quotation: It has been said that democracy is the worst form of government except all the others that have been tried. ICANN might not be the right place to discuss issues such as I18N, but IETF is worse. ICANN is not by its nature a standards body so that it's not naturally well suited to discussion of standards issues, nor would it appear that it has any aspirations in that regard. Given that, I'm not sure what if any role ICANN could play in enhancing progress in DNS-related standards, other than perhaps providing some operational feedback. And worst of all would be to have a situation where IETF is defacto ratifying decisions that are actually being deliberated in ICANN process. So far, I haven't seen much evidence of that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Beyond reproach, accountability and regulation
Here is a dictionary definition of Beyond reproach: Beyond reproach: So good as to preclude any possibility of criticism. Last time I looked, RFC 3777 did not include this definition as a requirement for the nomcom in selection of I* candidates. Good thing, too. We seem to have gotten by with candidates with occasional imperfections over the years. Given the impossibility of populating all leadership positions with individuals beyond reproach, or even defining all potentially problematic behaviors, what is the way forward? How do we move beyond reproach? Years ago, the Direct Marketing Association Nonprofit Federation (of all people) published an article called 'Moving Beyond Reproach' that talks about moving beyond accountability initiatives: http://www.the-dma.org/nonprofitfederation/March2005final.pdf Some quotes: though nonprofits could seemingly drown in the flood of accountability initiatives, there is virtually no support for nonprofit leaders in dealing with actual ethical crises... it is clear that the nonprofit sector can do more good by focusing on ways to provide real support for dealing with actual crises than by trying to abolish them by decree. Some food for thought. == On Wednesday, April 22, 2009 Clint Chaplin said: ...Popper said that it is reasonable to assume that sooner or later some rotten scoundrels will gain power. It's not important who they will be precisely, but whatever your political views might be you must agree that a likelihood of such an event is rather high. So whatever law you want to have in your country, don't ask yourself the question how this law can be used in good hands. Ask the question how this law can be used when the filthiest, dirtiest, stupidest bastards will rule my country (and sooner or later they probably will). Only the law that cannot be used to do anything wrong EVEN by the most vicious ruler is truly good On 4/22/09, Phillip Hallam-baker also wrote: One of the commentators in a recent thread suggested that another person was beyond reproach. That has been worrying me as a security person for a number of reasons. Not least the fact that in my business nobody is ever beyond reproach. For the past eight years the establishment press in this country told us daily that suggesting that the 'president' was not beyond reproach was tantamount to committing treason, It seems to me that many of the social infrastructures that have developed over the years by IETF members suffer from being dependent on being run by individuals who are and must be beyond reproach. That is a very fragile model. If someone is beyond reproach they are beyond accountability. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-behave-nat-behavior-discovery (NATBehavior Discovery Using STUN) to Experimental RFC
Bruce -- Thanks for the reply. Your explanation provides some helpful background. Would you consider adding some of this material to the document? Date: Sun, 5 Apr 2009 22:57:22 -0400 Subject: Re: Last Call: draft-ietf-behave-nat-behavior-discovery (NATBehavior Discovery Using STUN) to Experimental RFC From: b...@lowekamp.net To: bernard_ab...@hotmail.com CC: ietf@ietf.org; beh...@ietf.org Bernard, Thanks for the comments. Let me see if I can describe a scenario in which behavior-discovery is useful. First, we don't want to go back to 3489. There were two problems (well, there were a lot more problems, but I just want to talk about two right now) in particular that we don't ever want to go back to: - 3489 specified that an application would start up, characterize its NAT, and work in that mode forever after - 3489 specified that if you had a friendly NAT, you could query the STUN server for your transport address and use that one address At the same time, behavior-discovery is targeting applications for which ICE doesn't necessarily make sense. For example, applications that don't want to fall back to TURN, but have other options for how to establish a connection. (whether this means indirect routing or not needing the connection, or other reasons) So let me try to go into more details on a potential P2P application. When P2P node A starts up, it evaluates its NAT(s) relative to other nodes already in the overlay. Let's say that its testing indicates it's behind a good NAT, with endpoint-independent mapping and filtering. In this case, the peer will join the overlay and establish connections with appropriate peers in the overlay, but it will advertise to any node in the overlay that wants to reach it that they don't need to route through the overlay network formed by the P2P nodes to reach it (which is the normal routing mode in a P2P overlay), they can just send directly to its IP address. So when node B wants to send a message to A, it sends the message directly to A's IP address and starts a timer. If it doesn't receive a response within a certain amount of time, then it routes the message to A across the overlay instead. (Alternatively, B could simultaneously send the message to A's IP address and across the overlay, which guarantees minimum response latency, but can waste bandwidth.) A over time observes what percentage of the time it receives direct messages compared to overlay messages. If the percentage of direct connections is below some threshold (say 66%, picking a random number) then may stop advertising for direct connections. But if the percentage is high enough, it continues to advertise because it may be helping performance. If at some point, the NAT changes its behavior, A will notice a change in its direct connection percentage and may re-evaluate its decision to advertise a public address. (There are a lot of other details how this might work, how it would deal with multiple levels of NATs, and what the actual cost benefits are. I don't want to get into all of the details of how it would work here.) This is a good example because behavior-discovery is used for initial operating mode selection, but the actual decision for whether to continue advertising that public IP/port pair is made based on actual operating data. It's also using the result of the behavior-discovery work as an optimization, not in a manner where the application will fail if a percentage of the nodes in the overlay are unable to make a connection. Bruce On Sat, Apr 4, 2009 at 2:39 AM, Bernard Aboba bernard_ab...@hotmail.com wrote: Bruce Lowekamp said: Many of the questions you raise point to the same question of whether tests or techniques that are known to fail on a certain percentage of NATs under a certain percentage of operating conditions are nevertheless valuable. behavior-discovery has an applicability statement http://tools.ietf.org/html/draft-ietf-behave-nat-behavior-discovery-06#section-1 that discusses those issues in some detail. I spent enough time wording that statement and discussing it with various people that I think it is best to refer to that statement. You also repeatedly uses phrases such as basically won't work and it might work. The comes down to the value of certain percentage as used above. My experience with these techniques, and the experience of those who have used such techniques recently, is that they are far more reliable than that, into the 90% range, particularly when used correctly. That is not high enough that we could go back to 3489---all techniques require fallbacks because they fail, and 90% is far, far too low of a success rate---but it is high enough that applications can make useful decisions based on that information, provided they have a fallback in cases where the information is wrong. And those
Re: Last Call: draft-ietf-behave-nat-behavior-discovery (NATBehavior Discovery Using STUN) to Experimental RFC
Bruce Lowekamp said: Many of the questions you raise point to the same question of whether tests or techniques that are known to fail on a certain percentage of NATs under a certain percentage of operating conditions are nevertheless valuable. behavior-discovery has an applicability statement http://tools.ietf.org/html/draft-ietf-behave-nat-behavior-discovery-06#section-1 that discusses those issues in some detail. I spent enough time wording that statement and discussing it with various people that I think it is best to refer to that statement. You also repeatedly uses phrases such as basically won't work and it might work. The comes down to the value of certain percentage as used above. My experience with these techniques, and the experience of those who have used such techniques recently, is that they are far more reliable than that, into the 90% range, particularly when used correctly. That is not high enough that we could go back to 3489---all techniques require fallbacks because they fail, and 90% is far, far too low of a success rate---but it is high enough that applications can make useful decisions based on that information, provided they have a fallback in cases where the information is wrong. And those are the conditions of the experiment. What I am failing to understand is the distinction between those situations in which we cannot go back to RFC 3489 and the scenarios envisaged for the experiment. Presumably, situations in which we cannot go back to RFC 3489 include Internet telephony, which may be used for life-critical situations such as E911. For those kind of scenarios, we need traversal technologies that are as reliable as possible, and are willing to live with the complexity of ICE to achieve this. The draft mentions P2P applications as one potential situation in which usage of imperfect techniques is acceptable, and yet the IETF currently has the P2PSIP WG, which is involved in the development of technology for usage of SIP over P2P networks. In that kind of application, wouldn't the reliability requirements be similar to those in which we cannot go back to RFC 3489? This lead me to think about the requirements for the diagnostic scenarios that are also discussed in the document. In existing deployments it is often challenging to figure out the reasons why traversal is unsuccessful, and what can be done to improve the overall success rate. Data suggests that there are even common situations in which ICE will fail. But in thinking through how to approach diagnosis under those conditions, I'd currently be more inclined to start from the addition of diagnostics to an ICE implementation than to focus on the use of the diagnostic mechanisms described in the draft. So while I'm generally sympathetic to the idea that there are situations in which less than perfect techniques can be useful, in practice a number of common situations where NAT traversal is used today (such as life-critical Internet telephony) do not seem to fit into that bucket. It could be that I didn't quite understand the examples given in the applicability statement, or that I'm putting too much emphasis on corner conditions, because that is what customers tend to complain about. However, overall the document left me unclear about the rationale by which the material deprecated in RFC 3489 was being re-introduced. While it does seem possible to construct a rationale for this, the document doesn't provide enough background to get me over that hump. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Last Call: draft-ietf-behave-nat-behavior-discovery (NAT Behavior Discovery Using STUN) to Experimental RFC
Cullen Jennings said: I was somewhat shocked to see the draft in IETF Last Call. The last time this draft was discussed at the microphone in Behave, many people were very concerned that it id not possible to correctly characterize a NAT without using more than one address behind the NAT. The tests done on on NATs by the researches at MIT did that, so did the the stuff from Cornell, as did draft-jennings-behave-test-results. The reason why this was needed is largely the reason why the IETF invented ICE. Initially folks thought that STUN alone would be enough to do NAT traversal. This turned out not to be true, STUN deprecated those parts and ICE was started. This draft fails to describe the types of test that have actually been found to work and just reinstates the stuff that was deployed and failed and then deprecated out of STUN. Now this draft pays some lip service to the fact that it basically won't work. You can read section 1 and get the full idea. The first and 2'nd par basically say this won't work. Then para 3 proposes this is experiment to find out something we already know the answer to. When this work was chartered, it was about making a way to characterize NATs and describe them in a controlled lab like environment. It was not about resurrecting exactly the part of STUN that had been tried, failed , and deprecated. There are several distinct issues here: a. Whether the draft faithfully represents the reliability of the mechanism described and the state of IETF standardization efforts in this area. b. Whether the draft prescribes use of the mechanism in ways that are appropriate (and different from RFC 3489). c. Whether the document is appropriate for publication as an Experimental RFC. d. Whether the draft fulfills the work item specified in the BEHAVE WG charter. With respect to a, here is what Section 1 says: This experimental STUN usage does not allow an application behind a NAT to make an absolute determination of the NAT's characteristics. NAT devices do not behave consistently enough to predict future behaviour with any guarantee. This STUN usage provides information about observable transient behavior; it only truly determines a NAT's behavior with regard to the STUN server used and the particular ports used at the instant the test is run. Applications requiring reliable reach between two particular endpoints must establish a communication channel through a NAT using another technique. IETF has proposed standards including ICE [I-D.ietf-mmusic-ice] and OUTBOUND [I-D.ietf-sip-outbound] for establishing communication channels when a publicly accessible rendezvous service is available. This usage provides techniques which are powerful diagnostic tools in the hands of a network administrator or system programmer trying to determine the causes of network failure; particularly when behavior varies by load, destination, or other factors that may be related to NAT behavior. Given this statement, it seems to me that the document isn't claiming that the usage enables the reliable determination of NAT characteristics, and that it recommends ICE for that purpose. So I'd say that the document is accurate in this respect. With respect to b, the document does describe experimental use in P2P applications: This draft also proposes experimental applications of NAT Behavior Discovery STUN for real-time selection of parameters for protocols in situations where a publicly accessible rendezvous service is not available. One such application is role selection in P2P networks based on statistical experience with establishing connections and diagnosing NAT behavior with a variety of peers. The experimental question is whether such a test is useful. If a node trying to join an overlay as a full peer when its NAT prevents sufficient connectivity and then withdrawing is expensive or leads to unreliable or poorly performing operation, then even if the behavior discovery check is only correct 75% of the time, its relative cheapness may make it very useful for optimizing the behavior of the overlay network. Section 2.2 describes this experimental application in more detail and discusses how to evaluate its success or failure. This particular usage seems to overlap with the ones envisaged in RFC 3489, and so it seems to me that Cullen does have a point about whether such an experiment would really yield new knowledge, or whether the outcome is already well understood (e.g. lots of situations in which it is already known that the experiment will fail). Another described use is diagnosis. However, in this use the diagnoser would presumably want as much information as possible about the behavior of the NAT in question in order to figure out why their application or service isn't working with it. Given that, do we believe that the diagnostic
Re: Please Review Draft IESG Statement on Activities that are OBE
Thomas Narten said: At the 20k level, I pretty much agree with everything John has said. This smells to me mostly of a way for the IESG to have an friendlier way of shutting down a WG without huring people's feelings. Sorry, but I think this missed the point. (I would be fine with individual cases being closed due to OBE, but even then the reasons will be nuanced and not covered by a broad statement.) OBE is not well defined, and folk will just start arguing about whether something really is OBE or not. I.e, we're just moving the problem elsewhere. In some cases, the problem may be easier to solve this way, but in others I doubt it. I agree with this. The IESG should have the right to close a WG for a wide variety of reasons, including lack of progress. Whatever those reasons might be, they should be subject to a approval by the IESG as a whole, as well as confirmation by IETF consensus. Given this, I don't believe that this draft IESG statement really helps much. If the IESG feels unable to close WGs that need to be closed, then they should write a document addressing this issue and bring it to IETF last call. This doesn't necessarily require RFC 2026bis (though getting that done is also necessary, but a subject for another discussion). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Welcome to the IETF Honest list (now go home!)
To paraphrase Hamlet: Hamlet: What's the news? Rosencrantz: None, my lord, but that the IETF list's grown honest. Hamlet: Then 'tis doomsday come. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Fourth Last Call: draft-housley-tls-authz-extns
I do not support publication of this document as a Proposed Standard via the AD-sponsored route, for several reasons: a. I believe that this document should have been handled as a WG work item. It should not be commonplace for standards track security documents to be handled outside of a WG. This issue has been addressed in IPsec (via IPSECME), and TLS needs to follow suit. If the TLS WG does not wish to deal with this and other documents, then the IETF should considered formation of a new WG. b. This document has become a lightening rod for attacks on the integrity of the IETF and IESG. While many of these attacks are groundless, proceeding with the approval of this document without addressing the underlying problems would send the wrong message about the IETF's commitment to ethics. -Original Message- From: ietf-announce-bounces at ietf.org [mailto:ietf-announce-bounces at ietf.org] On Behalf Of The IESG Sent: 14 January 2009 16:18 To: IETF-Announce Subject: Fourth Last Call: draft-housley-tls-authz-extns On June 27, 2006, the IESG approved Transport Layer Security (TLS) Authorization Extensions, (draft-housley-tls-authz-extns) as a proposed standard. On November 29, 2006, Redphone Security (with whom Mark Brown, a co-author of the draft is affiliated) filed IETF IPR disclosure 767. Because of the timing of the IPR Disclosure, the IESG withdrew its approval of draft-housley-tls-authz-extns. A second IETF Last Call was initiated to determine whether the IETF community still had consensus to publish draft-housley-tls-authz-extns as a proposed standard given the IPR claimed. Consensus to publish as a standards track document was not demonstrated, and the document was withdrawn from IESG consideration. A third IETF Last Call was initiated to determine whether the IETF community had consensus to publish draft-housley-tls-authz-extns as an experimental track RFC with knowledge of the IPR disclosure from Redphone Security. Consensus to publish as experimental was not demonstrated; a substantial segment of the community objected to publication on any track in light of the IPR terms. Since the third Last Call, RedPhone Security filed IETF IPR disclosure 1026. This disclosure statement asserts in part that the techniques for sending and receiving authorizations defined in TLS Authorizations Extensions (version draft-housley-tls-authz-extns-07.txt) do not infringe upon RedPhone Security's intellectual property rights. The full text of IPR disclosure 1026 is available at: https://datatracker.ietf.org/ipr/1026/ This Last Call is intended to determine whether the IETF community had consensus to publish draft-housley-tls-authz-extns as a proposed standard given IPR Disclosure 1026. The IESG is considering approving this draft as a standards track RFC. The IESG solicits final comments on whether the IETF community has consensus to publish draft-housley-tls-authz-extns as a proposed standard. Comments can be sent to ietf at ietf.org or exceptionally to iesg at ietf.org. Comments should be sent by 2009-02-11. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-housley-tls-authz-extns-07.txt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The IESG that can so no!
Thomas Narten said: At the 20k level, I pretty much agree with everything John has said. This smells to me mostly of a way for the IESG to have an friendlier way of shutting down a WG without huring people's feelings. Sorry, but I think this missed the point. (I would be fine with individual cases being closed due to OBE, but even then the reasons will be nuanced and not covered by a broad statement.) OBE is not well defined, and folk will just start arguing about whether something really is OBE or not. I.e, we're just moving the problem elsewhere. In some cases, the problem may be easier to solve this way, but in others I doubt it. I agree with this. The IESG should have the right to close a WG for a wide variety of reasons, including lack of progress. Whatever those reasons might be, they should be subject to a approval by the IESG as a whole, as well as confirmation by IETF consensus. Given this, I don't believe that this draft IESG statement really helps much. If the IESG feels unable to close WGs that need to be closed, then they should write a document addressing this issue and bring it to IETF last call. This doesn't necessarily require RFC 2026bis (though getting that done is also necessary, but a subject for another discussion). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
I do not support publication of this document as a Proposed Standard, for several reasons: a. I believe that the subject of this document (TLS authorization) is of fundamental importance to a number of IETF WGs, and therefore it should not be handled via AD-sponsorship, but rather within a WG. If the TLS WG does not wish to deal with the document, then the IETF should consider formation of a new WG to deal with this and other TLS extensions. b. This document has become a lightening rod for attacks on the integrity of the IETF and IESG. Rather than ignoring the concerns that have been raised, I believe that the IETF needs to tackle them head on, by initiating reforms in the areas of affiliation disclosure and conflict of interest within the IESG. Given the current controversy, approving this document could be interpretted as a lack of concern about those issues. c. I'm not convinced that the latest Redphone IPR disclosure represents a substantive rather than a cosmetic change from previous disclosures. -Original Message- From: ietf-announce-bounces at ietf.org [mailto:ietf-announce-bounces at ietf.org] On Behalf Of The IESG Sent: 14 January 2009 16:18 To: IETF-Announce Subject: Fourth Last Call: draft-housley-tls-authz-extns On June 27, 2006, the IESG approved Transport Layer Security (TLS) Authorization Extensions, (draft-housley-tls-authz-extns) as a proposed standard. On November 29, 2006, Redphone Security (with whom Mark Brown, a co-author of the draft is affiliated) filed IETF IPR disclosure 767. Because of the timing of the IPR Disclosure, the IESG withdrew its approval of draft-housley-tls-authz-extns. A second IETF Last Call was initiated to determine whether the IETF community still had consensus to publish draft-housley-tls-authz-extns as a proposed standard given the IPR claimed. Consensus to publish as a standards track document was not demonstrated, and the document was withdrawn from IESG consideration. A third IETF Last Call was initiated to determine whether the IETF community had consensus to publish draft-housley-tls-authz-extns as an experimental track RFC with knowledge of the IPR disclosure from Redphone Security. Consensus to publish as experimental was not demonstrated; a substantial segment of the community objected to publication on any track in light of the IPR terms. Since the third Last Call, RedPhone Security filed IETF IPR disclosure 1026. This disclosure statement asserts in part that the techniques for sending and receiving authorizations defined in TLS Authorizations Extensions (version draft-housley-tls-authz-extns-07.txt) do not infringe upon RedPhone Security's intellectual property rights. The full text of IPR disclosure 1026 is available at: https://datatracker.ietf.org/ipr/1026/ This Last Call is intended to determine whether the IETF community had consensus to publish draft-housley-tls-authz-extns as a proposed standard given IPR Disclosure 1026. The IESG is considering approving this draft as a standards track RFC. The IESG solicits final comments on whether the IETF community has consensus to publish draft-housley-tls-authz-extns as a proposed standard. Comments can be sent to ietf at ietf.org or exceptionally to iesg at ietf.org. Comments should be sent by 2009-02-11. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-housley-tls-authz-extns-07.txt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
From my perspective, the best approach involves keeping the general case simple. The documents that have been transferred outside the IETF in the past five years is a single digit number, a tenth of a percent of all RFCs if not a smaller fraction. From my perspective, the simplest solution to the transfer issue is to ask the people relevant to a document for which transfer has been suggested whether they have an issue with transferring it, rather than asking every document author his or her opinion on the vast majority of documents, which will never be transferred. Certainly in the IETF as we have known it, situations such as those described in RFC 4663 have been rare. If handling those scenarios is the major focus, then I'd agree with your argument for optimizing for the common case. In particular, corner conditions have a way of being somewhat unique (that's why they are corner conditions) so that trying to handle all of them in a unified way can prove elusive. So overall, the question seems to come down to whether transfers are likely to become much more commonplace in the future than they have in the past. It strikes me that the situations in which this would occur would tend to be rather dark -- and indeed the discussion on this topic has wandered into some of those less rosy scenarios. While an organization (or person) is healthy, it is often difficult to muster much enthusiasm for estate planning discussions. However, even if one considers those situations, it still is not entirely clear to me that these provisions are required. For example, over the last few years we seem to have made it through a number of wrenching transitions without requiring this. For example, do we believe that the situation described in RFC 4663 is likely to become increasingly common in the years ahead? To be blunt, the only scenarios in which that would seem possible would be worst case Remember that this boilerplate affects internet drafts, but most internet drafts are discussion documents - a fraction of internet drafts even become RFCs, and a small fraction of RFCs are transferred elsewhere. As to the other issues that 5378 addresses, I suspect that a better approach will be to fall back to 3978/4748/2026 temporarily and move to 5378-bis when it comes rather than to use this very general workaround to 5378's issues until 5378-bis is resolved. 3978 etc worked just fine for most purposes... On Jan 8, 2009, at 1:43 PM, Ed Juskevicius wrote: The purpose of this message is twofold: 1) To summarize the issues that some members of our community have experienced since the publication of RFC 5378 in November 2008, and 2) To invite community review and discussion on a potential work- around being considered by the IETF Trustees. Some I-D authors are having difficulty implementing RFC 5378. An example of the difficulty is as follows: - an author wants to include pre-5378 content in a new submission or contribution to the IETF, but - s/he is not certain that all of the author(s) of the earlier material have agreed to license it to the IETF Trust according to RFC 5378. If an I-D author includes pre-5378 material in a new document, then s/he must represent or warrant that all of the authors who created the pre-5378 material have granted rights for that material to the IETF Trust. If s/he cannot make this assertion, then s/he has a problem. This situation has halted the progression of some Internet-Drafts and interrupted the publication of some RFCs. The Trustees of the IETF Trust are investigating ways to implement a temporary work-around so that IETF work can continue to progress. A permanent solution to this pre-5378 problem may require an update to RFC 5378, for example new work by the community to create a 5378-bis document. The remainder of this message provides an outline of the temporary work- around being considered by the Trustees. RFC 5378 sections 1.j and 5.3.c provide the IETF Trust with the authority to develop legend text for authors to use in situations where they wish to limit the granting of rights to modify and prepare derivatives of the documents they submit. The Trustees used this authority in 2008 to develop and adopt the current Legal Provisions Relating to IETF Documents which are posted at: http://trustee.ietf.org/license-info/. The Trustees are now considering the creation of optional new legend text which could be used by authors experiencing the pre-5378 problem. The new legend text, if implemented, would do the following: a. Provide Authors and Contributors with a way to identify (to the IETF Trust) that their contributions contain material from pre-5378 documents for which RFC 5378 rights to modify the material outside the IETF standards process
Review of draft-ietf-trill-prob-05
Review of draft-ietf-trill-prob-05.txt I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC [EMAIL PROTECTED] if you reply to or forward this review. In general, I did not find any major transport issues that need to be addressed within this document. The document does a good job of summarizing the motivations for TRILL, such as the desire to improve path efficiency (Section 2.1), provide multipath support (Section 2.2), improve convergence (Section 2.3), and improve stability of multicast operation (Section 2.4). Since the end result of addressing these issues should be improvement in aggregate bandwidth as well as lower frame loss, the net result should be quite positive for transport layer performance. At various points, the document pays appropriate attention to transport implications such as reordering. For example, within Section 3.1, the document states: Current Ethernet ensures in-order delivery for frames of the same priority and no duplicated frames, under normal operation (excepting transients during reconfiguration). These criteria apply in varying degrees to the different variants of Ethernet, e.g., basic Ethernet up through basic VLAN (802.1Q) ensures that all frames between two link addresses have both properties, but protocol/port VLAN (802.1v) ensures this only for packets with the same protocol and port. There are subtle implications to such a requirement. Bridge autolearning already is susceptible to moving nodes between ports, because previously learned associations between port and link address change. A TRILL solution could be similarly susceptible to such changes. One question that did arise in my reading of the document was the degree to which TRILL would affect IEEE 802 mobility. Section 2.6 states: Similarly, solutions to TRILL need not address link layer node migration, which can complicate the caches in learning bridges. Similar challenges exist in the ARP protocol, where link layer forwarding is not updated appropriately when nodes move to ports on other bridges. Again, the compartmentalization available in network routing, like that of network layer Autonomous Systems (ASes), can help hide the effect of migration. That is a side effect, however, and not a primary focus of this work. However, in Section 3.5, the document also notes that multiple points of attachment are likely to be better supported in TRILL: In STP, a single node with multiple attachments to a single spanning tree segment will always only get and send traffic over one of the those attachment points. TRILL must manage all traffic, including multicast and broadcast traffic, so as not to create feedback loops on Ethernet segments with multiple TRILL attachment points. This includes multiple attachments to a single TRILL node and attachments to multiple TRILL nodes. I think what the Section 2.6 paragraph is trying to say is that TRILL will encounter some of the same issues as IEEE 802.1D with respect to changes in point of attachment. One such issue is how to rapidly seed the learning tables and ARP caches on movement between attachment points. For example, within IEEE 802.11F, the AP spoofs a multicast frame on behalf of the Station (IEEE 802.11F) on receipt of an Association-Request, so as to seed the learning tables in advance of station attachment. In DNAv4 (RFC 4436), unicast ARP-Requests are sent in order to seed the router ARP cache, providing for return reachability within a single exchange. The motivation behind both of these devices is to minimize handoff latency and frame loss. However, one of the reasons why these work-arounds were necessary is that IEEE 802.1D only allows a node to have a single attachment point. This in turn has lead to prohibitions against the maintaince of multiple 802.11 associations within a single ESS, impeding make before break support. Given this, my overall take is that Section 2.6 may be selling TRILL somewhat short. While it's probably fair to say that improved mobility support is not one of the major goals of TRILL, my assumption is that TRILL will function at least as well as a mechanism for connecting IEEE 802.11 access points (particularly if they support 11n), and possibly considerably better. My suggestion is that the paragraphs in Section 2.6 and 3.5 could be better harmonized, perhaps by mentioning TRILL support for current mobility work-arounds, or noting the positive mobility implications of support for multiple simultaneous attachments.
Review of draft-ietf-monami6-multiplecoa-10.txt
Review of draft-ietf-monami6-multiplecoa-10.txt I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC [EMAIL PROTECTED] if you reply to or forward this review. In general, I did not find any transport issues that need to be addressedwithin this document. As noted in the abstract, this document enables the use of multiplecare of addresses within MIPv6. MIPv6 (and mobility in general)can have considerable impact on transport layer performance in thathandovers frequently result in substantial changes in transportparameters. However, these issues are typically handled in otherdocuments, not within the MIPv6 documents themselves. While theuse of multiple CoAs may make the problem more serious, it doesnot appear to change the problem fundamentally in a way thatwould require that the issue be addressed in this document. From a point of view of congestion control, there are situationsin which faulty lower layer indications (e.g. jittery NICs) couldresult in a large amount of mobility-related traffic. However,these situations are not unique to multiple CoA configurations,and so addressing this potential issue is also probably not theresponsibility of this document. I did not notice any potential problems with ECN functionality. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IETF.org does its part on internationalization
.Due to the ASCII character encoding being the core/monopoly This is a bad start: non-ASCII characters are used on the Internet for many years. There is certainly an ASCII *bias* in many Internet protocols, applications or deployments but if there was an ASCII *monopoly*, it ended a long time ago. From draft-ietf-idnabis-protocol-03.txt Section 6.1: The current update to the definition of the DNS protocol [RFC2181] explicitly allows domain labels to contain octets beyond the ASCII range (..007F), and this document does not change that. Note, however, that there is no defined interpretation of octets 0080..00FF as characters. If labels containing these octets are returned to applications, unpredictable behavior could result. The A-label form, which cannot contain those characters, is the only standard representation for internationalized labels in the current DNS protocol. As noted above, the DNS protocol does not prohibit the carrying of non-ASCII characters; the issue is the response of applications to receipt of such characters in responses. Presumably applications written to UNICODE APIs such as GetAddrInfoW are capable of handling UTF-8 in responses, and indeed there are many such applications (e.g. applications depending on .NET/mono DNS classes). presently you cannot have domain names that are multilingual, for example: japanese and english language mixed character domain names, hindi and english language mixed character domain names etc. Since it is an IETF mailing list, I will focus on what depends on IETF, technical standards. There is *nothing* in the current IDN standard (machine names in Unicode) that forbids such mixes. You may refer to bad policies like ICANN IDN Guidelines, which apparently forbid mixing scripts, but this had nothing to do with the IETF, nothing to do with the protocols. From draft-ietf-idnabis-rationale-01.txt Section 14: To help prevent confusion between characters that are visually similar, it is suggested that implementations provide visual indications where a domain name contains multiple scripts. Such mechanisms can also be used to show when a name contains a mixture of simplified and traditional Chinese characters, or to distinguish zero and one from O and l. DNS zone administrators may impose restrictions (subject to the limitations identified elsewhere in this document) that try to minimize characters that have similar appearance or similar interpretations. It is worth noting that there are no comprehensive technical solutions to the problems of confusable characters. One can reduce the extent of the problems in various ways, but probably never eliminate it. Some specific suggestions about identification and handling of confusable characters appear in a Unicode Consortium publication [Unicode-UTR36]. This is *not* a prohibition, but rather a suggestion; Section 4 of the document contains no restriction on the registration of labels with mixed scripts. Similar advice can be found in RFC 3490 Section 10. Another example, there is not much browser / URL bar integration and usability innovation that allow for a non-ASCII language domain name to stay non-ASCII script on the browser / URL bar without it changing to Punycode. From draft-ietf-idnabis-rationale-01.txt Section 7.2: Applications MAY allow the display and user input of A-labels, but are encouraged to not do so except as an interface for special purposes, possibly for debugging, or to cope with display limitations. A-labels are opaque and ugly, and, where possible, should thus only be exposed to users and in contexts in which they are absolutely needed. Because IDN labels can be rendered either as the A-labels or U-labels, the application may reasonably have an option for the user to select the preferred method of display; if it does, rendering the U-label should normally be the default. Indeed, there are browsers (e.g. Safari) that actually follow this advice (and provide a more pleasant user experience as a result). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
Single label names are local in scope. Attempting to use them in a global context does not work. As the names in . get more interesting the probability of collisions with existing names goes up. Not many people choose two letter labels for the least significant parts of their host names unless they are choosing their initials. Single label hostnames are not globally unique. They SHOULD NOT be used in a context where globally unique names are required. Mark, With the understanding that I agree with everything you say above, there are some interesting problems Referring to the point Mark is making as a problem is a bit like saying that someone attempting to sell the Brooklyn Bridge has a problem. While the potential bridge purchaser may in fact very much desire to own the bridge, the problem is that the seller may not in fact have the right to sell it. That's really at the core of what Mark is arguing -- that various RFCs allocate single-label names for local use, and therefore that ICANN may not possess the right to sell that property to another party. (1) ICANN is well aware of the problem you mention As I understand it, they have explicitly decided to ignore that problem... Someone attempting to sell the Brooklyn Bridge can also explicitly decide to ignore the problem of whether they in fact own it. That won't make the problem go away. In this particular case, we are talking about RFCs that are included as requirements for purchase worth billions of dollars annually, as well as local names currently in local use by hundreds of millions of people. So we're not talking about selling a single Brooklyn Bridge here, but many. (2) Regardless of what some of us may think about the desirability (or not) of associating services with TLD names The issue is not desirability. Someone might very much desire to purchase the Brooklyn Bridge. It has many excellent qualities -- it is used by many people over the course of a day, it is a registered historical site making it of great interest to tourists, etc. The problem is whether the seller can establish title. So, much as I'd like it if we could say Single label names are local in scope...does not work Mark's point is that several RFCs already say this. So what we have here isn't really an technical argument or one about desirability -- it's a property rights argument. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
Not really. ICANN isn't selling single-label domains. They are selling (and I believe selling is probably now the correct term) plain, ordinary, TLD delegations. If I get one of those and populate the TLD zone only with delegation records, there are no problems with what ICANN has done at all, whether you describe it as a property right or in some other way. Agreed. On the other hand, if they delegate one and the enterprise that buys it chooses to populate the zone with service records, then ICANN's position will certainly be that any inability to use those service records isn't ICANN's problem -- any more than difficulties using .museum or .aero were ICANN's problem when those to whom those domains were delegated discovered that a lot of applications software thought that the one TLD label of more than three characters was ARPA. Is generic buyer beware disclaimer really sufficient here? The problem isn't just inability to use -- it's that other parties exist who may claim the usage right, and provide citations to RFCs to back up their claim. For example, typing http://brooklynbridgepark/ into a browser utilizing a resolver compliant with RFC 1536 will bring you to the web site of Brooklyn Bridge Park Conservancy, assuming that .org is in your searchlist. If ICANN sells the brooklynbridgepark TLD delegation to another party who populates the zone with service records, should that party expect that http://brooklynbridgepark/ will now resolve to their site? RFC 1536 says no. Similar problems will occur when the party purchasing the brooklynbridgepark TLD attempts to use the single-label name brooklynbridgepark for other uses, such as network access. And _that_ situation has a lot more to do about buyer beware and understanding of conflicting expectations about use than it does about ownership. Today there is a distinction between types of property rights - surface, subsurface, or rights to the air above a property. As noted at http://geology.com/articles/mineral-rights.shtml this was not always the case: If we go back in time to the days before drilling and mining, real estate transactions were fee simple transfers. However, once subsurface mineral production became possible, the ways in which people own property became much more complex. If the analogy holds (and I'm not a lawyer, so I have no idea if it does), then we could be talking about a fee simple transfer in a situation where sub-rights may be claimed to belong to someone else. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Update of RFC 2606 based on the recent ICANN changes ?
Lyman said: I'm familiar with draft-klensin-rfc2821bis-10.txt and understand the importance of using only FQDNs in SMTP exchanges given that [i]n the case of a top-level domain used by itself in an email address, a single string is used without any dots. What I'm interested in is any reason to proscribe the use of a TLD as a single label hostname (particularly for email addresses) other than the fact that there is software out there that will interpret it incorrectly - Potential problems with global use of single-label names go beyond SMTP. For example, RFC 4282, which defines the Network Access Identifier (NAI), does not permit the use of single-label names. From Section 2.1: realm = 1*( label . ) label As a result, someone purchasing the example TLD and using the NAI [EMAIL PROTECTED] in order to obtain access to the network, might well discover that this would not work. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Update of RFC 2606 based on the recent ICANN changes ?
Mark Andrews said: The Internet went to multi-label hostnames ~20 years ago.We added .ARPA to all the single label hostnames as partof that process. The only hold over is localhost andthat is implemeted locally, not in the global DNS. No sane TLD operator can expect http://tld; or [EMAIL PROTECTED]to work reliably. I suspect there are still mail configuationsaround that will re-write [EMAIL PROTECTED] to [EMAIL PROTECTED] we be writting a RFC which states that MX and addressrecords SHOULD NOT be added to the apex of a TLD zone? Should we be writting a RFC which states that single labelhostnames/mail domains SHOULD NOT be looked up as is inthe DNS? Both sound like good ideas to me. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
We have a way to count DISCUSS positions, but we do not have a way to figure out what percentage of them are perceived as late surprises by the community. So, while we are taking action in an attempt to make things better, we do not have a way to measure our success or failure beyond community perception. Suggestions on making this more objective and less subjective are greatly appreciated. Russ I agree that it might be hard to measure the effect of particular actions (e.g. changes in procedures). However, it is *not* hard to measure overall trends in performance, and to break these trends down between areas and types of documents. My understanding is that the Simcoe dataset continues beyond 2001, and that with some relatively modest effort, a detailed analysis could be produced quantifying how the IETF has performed. This would give us a window into what the actual results have been. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
Russ Housley said: I agree with this principle. In fact, I think that the IESG has taken many steps over the last four or more years to reduce the nearly-end-of-process surprises. Obviously, you do not think these measures have been sufficient. One lesson from the many attempts to make updates to RFC 2026 is that such policy documents needs to set expectations without taking away flexibility and judgement. Can you elaborate on what steps the IESG has taken to reduce the nearly-end-of-process surprises and why effect this has had, if any? For example, have the delays resulting from IESG reviews actually *decreased* as a result? The research by Prof. Simcoe of the Rotman School is not encouraging: http://www.rotman.utoronto.ca/strategy/research/working%20papers/Simcoe%20-%20Delays.pdf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG rejecting purple documents on Wednesdays
You may think I'm making light of this - and I am, because I think it's a remarkably silly stance from the IESG - but if you can explain the difference between rejecting all purple documents on Wednesdays and rejecting documents that do not use RFC 2606, I'll be most grateful. The difference is important. Rejecting all purple documents on Wednesday is a well defined (albeit silly) policy. Since such a policy can be articulated, it can be discussed and rejected by the IETF community. Rejecting *some* documents that do not use RFC 2606 while approving others is more dangerous, since it is not a policy at all, but rather, a whim that seemed like the right thing to do at the moment. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diame
Glen Zorn said: This all a matter of implementation stuff is just a cop-out: thisdocument needs to clearly specify all the entities involved, howeverskeletal that specification may be: if the RADIUS server gets thelocation information from another server which subsequently validatesthe response, that's fine. If the RADIUS server does it, that's fine; Idon't really care but 'fuzziness' has no place in standards, IMHO. [BA] I would agree. My assumption had been that theRADIUS server was merely looking for the presence/absence ofattributes and writing location data to a backend store,so that it was not required to be location aware. However, you have pointed out statements in the document whichappear to imply something more than this - such as the abilityof a RADIUS server to parse and understand location data. Given that two readers have come to such widely differing interpretations of the same text, I'd suggest that these ambiguities need to be cleared up. Glen Zorn also said this: As I understand the development cycle of an Internet-Draft, there's nosuch thing as 'too late to make a change'. The following text appearsin every single I-D published: Internet-Drafts are draft documentsvalid for a maximum of six months and may be updated, replaced, orobsoleted by other documents at any time. Seems pretty clear to me.I'm sure that someone will mention at this point that 3GPP87 or somesuch has already implemented this draft; fortunately, this is prettymuch taken care of by the next sentence (that also appears in everysingle I-D): It is inappropriate to use Internet-Drafts as referencematerial or to cite them other than as work in progress. [BA] In this particular case there is ambiguity, so that it is notclear what the current document is actually requiring. Assumingthat is cleared up, we can then address the issue of what changesare needed. I don't believe there is any statute of limitationson addressing ambiguities. Furthermore, Glen Zorn said this: So are you saying that good design practices aren't good designpractices until they have an RFC number? [BA] Since this document was developed alongside the Design Guidelinesdocument, and the Guidelines were developed in part in response toissues raised by this document, it is hard to argue that it shouldbe exempt, regardless of the state of the Design Guidelines document.___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
