Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Andy Bierman wrote: I don't agree that this is low-hanging fruit. The server component of this system seems like a wonderful new target for DDoS and masquerade attacks. Well, first of all I don't see why this is any different than a radius server. In fact it could be that the access box forwards information in a very similar way. But let's say that it doesn't work that way just for yucks. Another approach is that the clients themselves must have a server on them and the queries go the other way. In this case the server need only check either a source address or a transaction ID. Furthermore, there is no reason for clients outside of that AS to have access to that server, so it's a good candidate for an ACL. Of course this creates a risk of attack on the clients themselves, which brings me to one of my greater concerns: In many of the mechanisms that communicate between client and network we are not finding good ways to prove the legitimacy of the service to the client. This is an area that perhaps it would be good to get the IRTF to work on. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Lakshminath Dondeti wrote: At 01:42 AM 10/7/2006, Harald Alvestrand wrote: snip Many universities require their students to buy their own laptops, but prohibit certain types of activity from those laptops (like spamming, DDOS-attacks and the like). They would love to have the ability to run some kind of NEA procedure to ensure that laptops are reasonably virus-free and free from known vulnerabilities, and are important enough in their students' lives that they can probably enforce it without a complaint about violation of privacy. Just pointing out that there's one use case with user-managed endpoints where NEA is not obviously a bad idea. My email ventures into a bit of non-IETF territory, but we are discussing use cases, and so I guess it's on topic. Universities should be the last places to try antics like NEA. Whereas an operational network would be a priority to them, it is also important that they allow students to experiment with new applications. If we are believing that general purpose computing will be taken away from college students, we are indeed talking about a different world. In any event, the bottomline is NEA as a solution to network protection is a leaky bucket at best. NEA at best *may* raise the bar in attacking a closed network where endpoints are owned and tightly controlled by the organization that owns the network. Lets not forget that when (not if) NEA/NAP/NAC is deployed the IDSen people have deployed today to solve the lying-client-problem by scanning for common/current vulnerabilities as part of the network admission process will have to interface with PDPs part of a NEA intfrastructure. Cheers Leif ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Extreme clipping below: v) IDS/IPS to detect and prevent intrusions NEA might help here by providing a common semantics for communicating the result of IDS scans of hosts to policy decision points. Cheers Leif ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
At 01:46 AM 10/16/2006, Leif Johansson wrote: Lakshminath Dondeti wrote: At 01:42 AM 10/7/2006, Harald Alvestrand wrote: snip Many universities require their students to buy their own laptops, but prohibit certain types of activity from those laptops (like spamming, DDOS-attacks and the like). They would love to have the ability to run some kind of NEA procedure to ensure that laptops are reasonably virus-free and free from known vulnerabilities, and are important enough in their students' lives that they can probably enforce it without a complaint about violation of privacy. Just pointing out that there's one use case with user-managed endpoints where NEA is not obviously a bad idea. My email ventures into a bit of non-IETF territory, but we are discussing use cases, and so I guess it's on topic. Universities should be the last places to try antics like NEA. Whereas an operational network would be a priority to them, it is also important that they allow students to experiment with new applications. If we are believing that general purpose computing will be taken away from college students, we are indeed talking about a different world. In any event, the bottomline is NEA as a solution to network protection is a leaky bucket at best. NEA at best *may* raise the bar in attacking a closed network where endpoints are owned and tightly controlled by the organization that owns the network. Lets not forget that when (not if) NEA/NAP/NAC is deployed the IDSen people have deployed today to solve the lying-client-problem by scanning for common/current vulnerabilities as part of the network admission process will have to interface with PDPs part of a NEA intfrastructure. Could you rephrase please? I am afraid I don't understand what you are saying. Oh, and lying endpoint problem cannot be solved by scanning for common vulnerabilities! In fact, the two have no relation whatsoever. Lakshminath Cheers Leif ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Please stop the country-specific references (Was: I understand that there is an ISO MOU with the IETF - I want to see it...
On Fri, Oct 13, 2006 at 01:08:42PM -0700, Dave Crocker [EMAIL PROTECTED] wrote a message of 34 lines which said: Further most people who participate in non-profits do not fit the legal definition of member. In the world of non-profits, that term has very specific meaning and carries very specific obligations. Hence most non-profits avoid it by having subscribers or the like who are not actually members. [And, in another message, a reference to what appears to be USA tax law and which probably puzzled many IETFers:] That puts things into the 501(c)(3, 6, whatever) category. And my comments meant in that context. I have no doubt that your analysis is correct, as long as you limit yourself to one country. Giving the vast variety of countries in which IETF members-who-are-not-members work, and the variety of legal systems, I urge everyone to avoid basing any reasoning on a specific legal system. Unlike ICANN, which is incorporated in the USA for a purpose, IETF has no nationality. My knowledge of the US legal system is mostly limited to what you can learn by watching TV series so, please, do not use it as a reference that anyone should share. Or I will talk about the IETF by using examples from the french 1901 law about non-profit organisations :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Please stop the country-specific references (Was: I understand that there is an ISO MOU with the IETF - I want to see it...
I'd like to observe that the IASA was created so that the IETF as a whole wouldn't need to bother about these administrative matters. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-kolkman-appeal-support
John C Klensin wrote: ... Eliot, It seems to me that, if there is a right track here --and that is not obvious to me-- that you are on it or at least on a parallel one. I suggest that implies several changes to the draft, YMMD: (1) The supporter procedure/requirement should be triggered only is someone shows symptoms of being a vexatious appellant. People who are entering their first appeals don't trigger it. People whose last appeal was successful, even in part (that would need to be defined, of course, and that might not be easy) don't trigger it. The only folks who need to look for supporters are those who have appealed before and whose appeals have been rejected as without merit. That's roughly why I put a section in draft-carpenter-ietf-disputes called Single Dispute per Topic. We certainly need to create a disincentive to repetitious appeals IMHO. Requiring supporters may be a way to do that. John raises good points in his message. Michael Thomas wrote: ... Can an appeal be rejected with merit? Sandy gave you the caricature response, but the short answer is yes, if the IESG (or IAB) feels that the technical point in the appeal is valid, but not serious enough to invalidate the document. That's really what technical appeals are all about: someone who believes that a valid technical issue has been set aside when it shouldn't have been, and wants the IESG (or IAB) to take another look. Ditto, if a process violation is not felt serious enough to overturn a decision. As in: yes, we made a mistake, but the end result is the same anyway. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Please stop the country-specific references (Was: I understand that there is an ISO MOU with the IETF - I want to see it...
On Mon, Oct 16, 2006 at 02:00:17PM +0200, Brian E Carpenter [EMAIL PROTECTED] wrote a message of 9 lines which said: I'd like to observe that the IASA was created so that the IETF as a whole wouldn't need to bother about these administrative matters. I am not sure I understand. If you mean that the IASA's aim is to deliver engineers from day-to-day administrative stuff such as printing badges for the meetings, OK. But if you mean that IETF non-members should stay away from important policy-related things like the dispute resolution process or the very nature of the IETF (incorporated or not, in a country or another, etc), then, I would certainly disagree. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Please stop the country-specific references
But if you mean that IETF non-members should stay away from important policy-related things like the dispute resolution process or Certainly not; that's part of the standards process, which is explicitly excluded from IASA scope. the very nature of the IETF (incorporated or not, in a country or another, etc), then, I would certainly disagree. Well, hold on: the community took a clear decision about that, which is recorded in RFC 4071. My point is only that IASA is charged to implement that decision, which surely includes making sure that we remain tax-exempt, appropriately insured, etc. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
event calendar
When clicking on http://www.ietf.org/meetings/events.cal.html one gets the event calendar that was posted a while ago. But within a few seconds the page refreshes and one is sent to http://geneva.isoc.org/events/, which is a quite different, and much more limited list. I understand that the listmaintenanceis best-effort and that itt is available in text format, but is there some reason for the html format to be hidden ? Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Eliot Lear wrote: Andy Bierman wrote: I don't agree that this is low-hanging fruit. The server component of this system seems like a wonderful new target for DDoS and masquerade attacks. Well, first of all I don't see why this is any different than a radius server. In fact it could be that the access box forwards information in a very similar way. But let's say that it doesn't work that way just for yucks. Another approach is that the clients themselves must have a server on them and the queries go the other way. In this case the server need only check either a source address or a transaction ID. Furthermore, there is no reason for clients outside of that AS to have access to that server, so it's a good candidate for an ACL. Of course this creates a risk of attack on the clients themselves, which brings me to one of my greater concerns: In many of the mechanisms that communicate between client and network we are not finding good ways to prove the legitimacy of the service to the client. This is an area that perhaps it would be good to get the IRTF to work on. My comment was on Harald's characterization of this work effort as 'low hanging fruit'. IMO, that term is reserved for huge gains for very little effort. I don't think that is the case here. Eliot Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
call for documentation of legacy EAP methods
This is a call for vendors and authors of existing, deployed EAP methods to document their protocols. The IESG, the RFC Editor, and a number of volunteer reviewers want to help this process and make it as smooth as possible. Extensible Authentication Protocol (EAP -- RFC 3748) is used for network access control in various link layers and protocols, including 802.11, 802.16, IKEv2, etc. Being extensible, EAP allows different authentication methods. Unfortunately, many of the real-world EAP methods are either undocumented or poorly documented, particularly those methods that were developed prior to RFC 3748 and its IANA considerations being approved. The IETF is and has been addressing methods in the EMU WG, as well as in some individual submissions. For instance, there are currently four methods in the RFC Editor's queue. However, these activities are mostly about creating new methods that can be used in future networks. In addition, the IESG would like to see some commonly used current EAP methods to be published as RFCs. The intention would be to document current practice and focus on accurate descriptions (as opposed to improving the protocols or attempting to fix bugs in them). We believe this improves overall interoperability and makes it easier for anyone to implement equipment that employs EAP. More information available from an e-mail sent to the EMU and EAP WG lists, archives at: http://www1.ietf.org/mail-archive/web/emu/current/index.html Please contact me if you are interested in this. Jari Arkko ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I understand that there is an ISO MOU with the IETF - I want to see it...
Title: Re: I understand that there is an ISO MOU with the IETF - I want to see it... Todd Those are not exactly the facts. The two notes I wrote and posted on the ABA InfoSec list yesterday (10/12-- a.m pdt) were both replies to jeff williams who was inquiring about the property status of domain names. Unless jeff williams is a pseudonym you use, my replies were not to you individually and I am unaware of any ABAISC list inqury from you yesterday. I was brought in to the IETF list thread 5 pm PDT when a VRSN colleague forwarded several notes of YOURS saying if there is an MoU I want to see it. I then responded on the IETF list with the cite and text from the 1995 IETF/ISO (N.B.-ISO, as I originally wrote, NOT IEEE as you have opined). Admittedly also, again, NOT an MoU but rather, a more significant CoOp agreement with a Mutual Recgnition provision. BUT I have to ask, why are we still doing this? By the way, I am an attorney. My title at VeriSign is Corporate Director of Government Relations. I am not in the VRSN law department, (we are corp. staff) though I have in the past been Government Relations counsel at Digital Equipment from 1981-1997 and Legis. Counsel at the FCC 1976-81, am a member of the DC Bar and a member of the Legal/Regulatory Task Force of the President's NSTAC. But why do you ask ? Regards, Michael -Original Message- From: todd glassey [mailto:[EMAIL PROTECTED]] Sent: Friday, October 13, 2006 08:51 AM Eastern Standard Time To: Harald Alvestrand; ietf@ietf.org; Aisenberg, Michael Cc: John C Klensin; Contreras,Jorge Subject: Re: I understand that there is an ISO MOU with the IETF - I want to see it... Harald - you are right - the commentary came off the ABA Information Security Committee based on a question I had asked on IP issues for a matter not concerning the IETF per se, but when Michael popped up with the commentary that there was a formal MOU, I was intrigued and I wanted to see the document. And yes its Michael Aisenberg who made the statement who you will note is cc:d on this mailing (Morning Michael :-) For those of you who are unaware, Michael is Verisign's Sr. Attorney in its Federal Operations group as I recall - Michael - please correct me if I am wrong on the title! Todd - Original Message - From: Harald Alvestrand [EMAIL PROTECTED] To: ietf@ietf.org Cc: John C Klensin [EMAIL PROTECTED]; Contreras,Jorge [EMAIL PROTECTED] Sent: Friday, October 13, 2006 1:50 AM Subject: Re: I understand that there is an ISO MOU with the IETF - I want to see it... todd glassey wrote: Thats what I thought John but when Verisign's Corporate-Government Liaison, who is a very reputable attorney, pops up and says there is one I have to ask. Google searching seems to indicate that this role belongs to Michael Aisenberg. I suggest that anyone who cares to pursue this rumour go verify with him what he tried to say. There are Verisign people on this list who can ask him for clarification. (Note - there is an ITU-T Recommendation that talks about almost exactly what is being described. It is documented in RFC 3356, which is shared text with ITU-T A-Series Supplement 3. This is, however, not an MOU; it's an ITU description of its internal procedures. It's possible that ISO and ITU got mixed up somewhere along the line.) - Original Message - From: John C Klensin [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED]; ietf@ietf.org Cc: Contreras, Jorge [EMAIL PROTECTED] Sent: Thursday, October 12, 2006 1:09 PM Subject: Re: I understand that there is an ISO MOU with the IETF - I want to see it... --On Thursday, 12 October, 2006 12:27 -0700 todd glassey [EMAIL PROTECTED] wrote: I understand that there is a formal MOU between the ISO and the IETF that talks about ISO's actions with regard to the reliance on IETF Standards and RFC's. I want to physically see a copy of the document - in its entirety. To the best of my knowledge from either an IETF perspective or as a member of one or two of the mailing lists on which ISO would have needed to see comment, there is no such document or agreement. For such a thing to exist, there would almost certainly have to be a formal liaison agreement between IETF and either ISO or ISO/IEC JTC1 and that agreement doesn't exist either (although several of us have, over the years, attempted to make it happen). Where do you get these ideas? And please see my earlier comments about your rights in these issues generally and to make this type of demand, even if the agreement and documents did exist. It wasnt a demand John. Just a statement. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Greetings, todd glassey [EMAIL PROTECTED] wrote on 10/13/2006 05:56:42 AM: So then this is an attempt by Cisco and IBM and several others to qualify a SOX reporting and compliance tool - get real. Todd Glassey I'm not sure I follow how you can infer that post-admission status checks are Cisco and IBM's attempt to qualify a SOX reporting and compliance tool. That's one of the wildest leaps of (il)logic I have seen. While my comments here do not represent IBM in any official capacity I can say that IMHO, a Sox compliance and reporting tool based solely on NEA (or Cisco NAC or TNC) would be woefully inadequate. Could the data collected for an NEA posture check be stored as part of an audit trail and would this data be useful? Absolutely! Does that make this a Sox compliance and reporting tool? No way! It would just become another trail of interesting information that would be aggregated in a REAL compliance and reporting tool. One might also consider that the original post concerned post-admission integrity checking as opposed to checking at admission only. The data collected during the admission process would be just as suitable for compliance and reporting as post-admission data. So why does the addition of post-admission checking suddenly make this a compliance and reporting tool? While logic can sometimes be dangerous (my logic is undeniable), I tend to rely on it in the absence of anything better. I don't understand the logic behind your statement. Regards, Frank Yeh - Original Message - From: Frank Yeh Jr To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] ; ietf@ietf.org Sent: Thursday, October 12, 2006 3:32 PM Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Greetings, Both of the existing flavors of NEA-type protocols (Cisco NAC and TNC) provide some mechanisms for integrity checking after the admission process has completed and removing an endpoint's privileged access if it falls out of compliance. So IMHO, support for post-admission integrity checking willbe expected in NEA. Collector/Verifier pairs can use NEA for pre-admission integrity checking and some other protocol for post-admission checking but if a post-admission violation is found, there should be a mechanism to terminate the user's current admission session and restart the admission process. Regards, Frank Yeh Corporate Security Strategy Team IBM Tivoli Software [image removed] Darryl \(Dassa\) Lynch [EMAIL PROTECTED] Darryl \(Dassa\) Lynch [EMAIL PROTECTED] 10/12/2006 02:27 PM Please respond to [EMAIL PROTECTED] [image removed] To [image removed] [EMAIL PROTECTED] [image removed] cc [image removed] ietf@ietf.org [image removed] Subject [image removed] RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) [image removed] [image removed] Douglas Otis wrote: If an application happens to be malware, it seems it would be unlikely stop these applications. How about: vi) Provide application level advisory information pertaining to available services. Points that seem to be missing are: vii) Notification of non-compliance. (Perhaps this could become a restatement of i.) viii) Time or sequence sensitive compliance certificates provided following a remediation process or service. Often bad behavior is detected, such as scanning or sending spam which may violate AUPs. These violations may trigger a requirement for the endpoint to use a service that offers remedies the endpoint might use. There could then be a time-sensitive certificate of compliance offered following completion of a check-list and an agreement to comply with the recommendations. Those that remain infected after remediation, or that ignore the AUPs and are again detected, may find this process a reason to correct the situation or their behavior, or the provider may wish to permanently disable the account. Am I mistaken or is NEA intended to be a compliance check before a node is allowed onto the network? As such, observed behaviour and application abuse would seem to be issues that would be dealt with by other tools. NEA may be used to ensure certain applications are installed and some other characteristics of the node but actual behaviour may not be evident until such time as the node has joined the network and would be beyond the scope of detection by NEA IMHO. NEA may be used to assist in limiting the risk of such behaviour but that is about the extent of it that I see. My reading of the charter gives me the impression NEA is only intended for a specific task and some of what we have been discussing seems to extend well beyond the limited scope proposed. Darryl (Dassa) Lynch ___ Nea mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/nea
Re: draft-kolkman-appeal-support
--On Monday, 16 October, 2006 14:35 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: (1) The supporter procedure/requirement should be triggered only is someone shows symptoms of being a vexatious appellant. People who are entering their first appeals don't trigger it. People whose last appeal was successful, even in part (that would need to be defined, of course, and that might not be easy) don't trigger it. The only folks who need to look for supporters are those who have appealed before and whose appeals have been rejected as without merit. That's roughly why I put a section in draft-carpenter-ietf-disputes called Single Dispute per Topic. We certainly need to create a disincentive to repetitious appeals IMHO. Requiring supporters may be a way to do that. John raises good points in his message. Hmm. Brief reflecting on this comment suggests something else in line with my comment above. I would see it as much more reasonable to require supporters, endorsement, or even requiring that a second party generate the formal appeal if an appeal is lodged with the IESG, the IESG says no, and without merit, and the person involved wants to appeal to the IAB. The trick here, I think, is to try to keep the number of appeals that are either designed to create disruption or that have that effect to a minimum while recognizing that it is very much in the interest of the IETF to have an easily-exercised appeal process for those who are acting in good faith to try to reverse a misunderstanding, oversight, or process abuse that could not be handled at an earlier stage. One might even want to separate the rules for technical appeals from those applicable to appeals about process or abusive behavior, especially abusive behavior at the WG level (i.e., without IESG members being directly involved) and create a slightly higher bar for the latter after ADs and the IETF Chair conclude there is no problem... or maybe not. Again, I think there are tradeoffs here but that we need to try to understand the kinds of appeals we really want to have, and have quickly and efficiently. And then, whatever else we do, we should be sure we don't create unintentional obstructions to those types of appeals as side effects of making repeated and disruptive abuses more difficult. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-kolkman-appeal-support
Thanks to all that replied (and thanks to David for spawning a new subject header). Below are a few thoughts and replies to things people brought up. --- In a private communication somebody suggested that this draft is targeted to one or two specific individuals. That is not the case. --- Frank wrote: And please withdraw... If this turns out a extremely bad idea then I'll leave the draft be and we have the archive to proof that this idea has been raised and shot. You just shot the first bullet :-) . --- Ned wrote: In any case, I think there is far more danger associated with excluding the wanted than there is to including the unwanted. As for my motivation to choose NOMCOM eligibility for supporters. My underlying requirement is that supporters should understand the IETF culture and its structures. Besides, IETF participants should know the supporters. The idea behind that is that it creates a certain level of accountability between peers. All in all, supporters should individuals that can be clearly identified as stakeholder in the IETF (John used materially concerned party). I hope that we agree on that requirement; now we only have to define what makes a stakeholder (the devil in the detail)... It is clear that anybody in a 'leadership' role can be clearly and unambiguously identified as stakeholder that understand IETF culture and structure. (All present and past WG-Chairs, IESG and IAB members, the draft should be clarified on this). For non-leadership roles identifying stake-holders is more difficult. As far as I know there is only one _existing_ somewhat formal method to establish that; nomcom eligibility. I too, am hesitant with respect to using the nomcom criterion is the only mechanism for which there is running code. The immediate and obvious problem with the Nomcom criterion is that it excludes people that everybody knows are stake-holders but never go to meetings, or go to them on less regular basis. If there is an easy and unambiguous way to identify those IETF stakeholders I would want to include them. I've seen a few suggestions: - I have a feeling that writing an I-D puts the bar to low. - Having written an IETF-track document is a clear and unambiguous criterion. (Note that I used IETF-track here) - I do not think that membership of USENIX, IEEE, or other organizations helps to identify IETF stakeholders. Have I missed suggestions? In private communication it was also suggested that the supporters may should also take a role as mediator. I think that is not a requirement but I suppose that having the appellant talk to supporters may cause beneficial side effects. John argued: (1) The supporter procedure/requirement should be triggered (...) The problem I have with it is that it is a patch upon the patch. Besides, having an appeal denied is not always a _bad_ thing. I could imagine cases where one appeals because having the appeal denied actually clarifies how our procedures work. (2) The definition of someone permitted to be a supporter must, as several people have pointed out (Ned, IMO, most eloquently), be broad enough to include active IETF contributors who don't attend meetings. I agree; see above. One class of action that might need appealing would be a procedural decision that would [further] impede the ability of those people to effectively get work done in the IETF and they _must_ have standing to appeal such measures by themselves or in conjunction with others who are similarly impacted. I understand your concern, but I think/hope it is academic. I hope that it is clear from the I-D that _anybody_ can appeal as long as there are two people willing to say the appeal body should put time into looking at this. And I actually trust there will be sufficient people in the pool that understand that their default response should be support of the appeal. That trust, I realize, is not hardcoded in the process. (...) (3) The idea that, if someone successfully appeals, or supports an appeal, on one action, they should be permanently barred from supporting similar appeals in the future is seriously broken. That is not what I intended, I mend to say: If a supporter has supported an appellant, that same supporter cannot support that particular appellant again. The supporter can support other appellants. It could only have a chilling effect on the generation of appeals, legitimate ones as well as bogus ones, because one would want to save endorsements for important-enough occasions. As long as the pool of supporters is sufficiently large compared to the number of appeals from one appellant I do not think that will happen. We could set a time-out on the supporter not being
RE: draft-kolkman-appeal-support
This reply was inadvertently blind copied to the ietf mailing list. I meant to have it plain copied, but dropped it a line to low... -- Eric -- -Original Message- -- From: Gray, Eric -- Sent: Monday, October 16, 2006 2:04 PM -- To: 'Olaf M. Kolkman' -- Subject: RE: draft-kolkman-appeal-support -- -- I think, to address the comment, you would have to change the phrase to -- end with there are not sufficient qualified supporters. -- -- David wrote: -- Perhaps Olafur might even be convinced to produce text in his draft -- that encourages individuals to provide their support in proxy, or to -- allow IAB/IESG members to waive. -- -- _Olaf_ :-) wrote in the I-D: --Note that the appeal body may choose to consider an appeal even when -- there are not sufficient supporters. -- -- -- -- -Original Message- -- -- From: Olaf M. Kolkman [mailto:[EMAIL PROTECTED] -- -- Sent: Monday, October 16, 2006 1:20 PM -- -- To: ietf@ietf.org -- -- Subject: Re: draft-kolkman-appeal-support -- -- -- -- ___ -- -- Ietf mailing list -- -- Ietf@ietf.org -- -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to appeal by Robert Sayre dated 2006-08-29
Robert, thanks for following up even though the outcome was as expected. Robert Sayre schrieb: Atompub, Sorry, I guess you're stuck with the complete nonsense in your current draft. Even though RFC2617 is already a draft standard. Well, maybe the members of the working group want to consider to have the protocol published somewhere else (remember there was a big discussion about W3C vs IETF before this working group was formed?). HTTP-WG, Which mechanism will become required to implement for all HTTP/1.1 implementations? You can't cycle at DS without picking one. One potential outcome may be that there'll be no revision of the spec. IESG, It means what we want it to mean. Below, there are some brief responses to the irrelevant citations that were included. I guess I'll head over to Apache and write some client support for their new HTTP security standards. Sounds good. Any pointers to what's going on there? A good security mechanism implemented both in Apache httpd and Mozilla clearly would be A Good Thing. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Sam, -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 12:43 PM To: Frank Yeh Jr Cc: Hardie, Ted; [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Frank == Frank Yeh [EMAIL PROTECTED] writes: Frank Standardized VS vendor-specific attributes is not something that needs to be Frank solved today. Solutions can start with vendor-specific and migrate toward a Frank standard, if one develops, without changing the protocol. The specification Frank should not preclude the addition of standardized attributes. IE the Frank specification is like an alphabet, attributes are like vocabulary. You can add Frank new words without changing the letters. One of the things coming out of the most recent BOF was a strong desire for PA-level interoperability. That can be accomplished through standardized attributes or vendor-specific attributes that are sufficiently well documented (and not subject to patents) that third parties can implement collectors or analysis tools that interoperate with the vendor tools for the vendor attributes. Will we be able to meet these interoperability goals? Why or why not? I am very apprehensive of achieving any meaningful PA-level interoperability. I am not sure what minimum set of PA attributes will be standardized, but, whatever that set is, I doubt will be sufficient to provide any acceptable level of security, even for the endpoints. Even assuming ongoing standardization of vendor specific attributes, it is not totally realistic to assume that all applications will support the appropriate attributes. The rate of standardization is also very likely to be much slower than the rate of the growth in the number of attributes needed for any continued meaningful protection. Regards, Vidya ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Harald, This seems to be missing the point. I think there is a general sense that NEA could be helpful for some level of protection to complying endpoints in an enterprise scenario, which is exactly what you have described below. The disagreement seems to be on the topics of what NEA does for the network and whether it makes any sense in the provider model where the network and end device owners are different. On the network protection issue, I still have not seen anything that NEA provides that is not provided (in a better manner) by protection mechanisms that the network must use to protect itself against any unknown vulnerabilities and compromised endpoints. Everything that has been said still seems to be a subset of that larger threat which must be protected against anyway. Having said that, the use of NEA for the provider model doesn't make sense, since providers are interested in protecting their networks more than protecting the devices they don't own. Not to mention that they cannot really hope to get compliance from devices they don't own. Vidya -Original Message- From: Harald Alvestrand [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 6:24 AM To: Alan DeKok Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) A typical NEA case (taken out of what Cisco's NAC is supposed to be good for): - Worker goes on holiday, takes laptop - New attack is discovered that exploits a newly discovered Windows vulnerability - Patch is created, distributed and installed - NEA posture requirement is increased to must have patch - Worker comes back, plugs in laptop Without NEA-like functionality: - Worker is admitted - Worker gets attacked compromised - IDS other alarms go off - Remediation efforts do what they usually do With NEA: - Worker gets sandboxed - Worker gets upgraded - Worker gets admitted - No compromise, so no remediation No ill intent on the part of any participant (except the attacker). Just a TCO issue. The fact that some fruit is low-hanging doesn't mean it's not worth picking. Harald Alan DeKok wrote: Brian E Carpenter [EMAIL PROTECTED] wrote: What if your contractor has carefully configured the laptop to give all the right answers? What if it has already been infected with a virus that causes it to give all the right answers? Yes, that's a problem with NEA. No, it's not a problem for many (if not most) people using NEA. The people I talk with plan on using NEA to catch the 99% case of a misconfigured/unknown system that is used by a well-meaning but perhaps less clueful employee or contractor. The purpose of NEA is to enhance network security by allowing fewer insecure end hosts in the network. No one can prevent a determined attacker from getting in. But by providing fewer hosts for him to attack, the attacks become less feasibly, and more visible. Alan DeKok. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
On Oct 12, 2006, at 2:27 PM, Darryl ((Dassa)) Lynch wrote: Am I mistaken or is NEA intended to be a compliance check before a node is allowed onto the network? It seems impractical to specify system requirements or expect a suitable examination be done realtime prior to obtaining access. NEA should be seen more as a notification process with the goal of avoiding self inflicted trouble tickets. Bad actors will always be able to falsify this information, so the NEA does not offer protection. As such, observed behaviour and application abuse would seem to be issues that would be dealt with by other tools. Agreed. When these other tools withdraw services after bad behavior is detected, NEA can notify the endpoint nothing is malfunctioning, but rather these services have been withheld. A selection of certificates may then be required before additional (or any) services are subsequently granted. The NEA should be viewed as a process that eliminates many of the security related support calls. NEA may be used to ensure certain applications are installed and some other characteristics of the node but actual behaviour may not be evident until such time as the node has joined the network and would be beyond the scope of detection by NEA IMHO. NEA may be used to assist in limiting the risk of such behaviour but that is about the extent of it that I see. It seems impractical to expect NEA will prevent bad actors from producing the expected results. There is little that prevents the NEA from providing falsified information. There are anti-virus and OS updating services that could produce a certificate that includes: 1) certificate creator for validation 2) a time-stamp 3) class 4) the user/host identifier 5) resources required for updating the certificate It seems unwise to expect an endpoint to open their robes to the access point. However, the access point could offer certification services they require prior to granting access. This service may be something as simple as agreeing to the AUP presented on a web-form, or agreeing to remedy the cause of abusive behavior. The NEA should also be helpful in deciding whether a range of services are acceptable, and how this can be changed. Perhaps different certificates are required before specific services are granted. Rather than talking about the posture of the endpoint, consider the NEA to be little more than a repository for time- sensitive compliance certificates offering just the five points listed. My reading of the charter gives me the impression NEA is only intended for a specific task and some of what we have been discussing seems to extend well beyond the limited scope proposed. It seems that the NEA charter delves into too many details. The NEA can act as a bidirectional notification of services. From the access standpoint, these are services granted and compliance services required to upgrade what is being granted. From the endpoint standpoint, their certificates indicate which compliance services have been previously obtained, and the resources needed to renew these certificates when they are considered out-of-date by the access point. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Response to appeal by Robert Sayre dated 2006-08-29
This is the IESG response to the appeal by Robert Sayre posted at http://www.ietf.org/IESG/APPEALS/appeal-from-robert-sayre-08-29-2006.txt. The IESG has considered Mr. Sayre's concerns and believes that by requiring mandatory to implement security mechanisms the IESG is continuing a long established practice with strong IETF-wide community support. Acting counter to that support would require evidence of a new community consensus. Some sparse recent discussion on the IETF-wide list has not yet shown a change in this support. Therefore, we reject the appeal and hold with our original advice given to the atompub working group. - Appendix: Summary of relevant IETF documents RFC 3935 (BCP 95) states The benefit of a standard to the Internet is in interoperability - that multiple products implementing a standard are able to work together in order to deliver valuable functions to the Internet's users. RFC 2026 (BCP9) requires demonstrated interoperability of all features (mandatory or optional) prior to advancement to DS. Although demonstrated interoperability is not required for PS, it is clearly illogical to admit a spec to the standards track that is by construction ineligible for DS. Therefore, interoperability is the overall goal and all features (mandatory or optional) must be designed to be interoperable. RFC 2360 (BCP 22) points out the dangers of optional features: 2.10 Handling of Protocol Options Specifications with many optional features increase the complexity of the implementation and the chance of non-interoperable implementations. The danger is that different implementations may specify some combination of options that are unable to interoperate with each other. RFC 3365 (BCP 61) requires strong security to be available for all protocols. The solution is that we MUST implement strong security in all protocols to provide for the all too frequent day when the protocol comes into widespread use in the global Internet. ... However security must be a MUST IMPLEMENT so that end users will have the option of enabling it when the situation calls for it. RFC 3631 (IAB document), section 2.2, discusses Mandatory to implement security in more detail. The key sentence is To solve this problem, the IETF requires that *ALL* protocols provide appropriate security mechanisms, even when their domain of application is at first believed to be very limited. This is an IAB document, not a BCP, but it is a document that was discussed widely prior to publication. It describes the policy followed by the IESG for many years and endorsed by the IAB, in tandem with BCP 61. --- ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
2006/07 NomCom Members
The following are confirmed as members of NomCom 2006/07. Voting Members: Cengiz Alaettinoglu Dan Li Brian Haberman John Drake Stephen Kent Vidya Narayanan Hao Zhou Kurt Zeilenga Martin Stiemerling Juergen Quittek The non-voting members are: Andrew Lange (Chair) Olaf Kolkman (IAB Liaison) Cullen Jennings (IESG Liaison) Fred Baker (ISOC Liaison) Ralph Droms (Previous Chair/Advisor) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Call for Nominations - NomCom06
NomCom06 is now accepting nominations for open IAB, IESG and IAOC positions. To nominate a candidate visit: http://www1.tools.ietf.org/group/nomcom/06/nominate and fill the form in with the requested information. Please also include information on why this person would be good for the nominated position in the comments field. The nomination form requires a login. If you do not already have one, you can visit this page: http://www1.tools.ietf.org/newlogin to create a login for yourself. IESG positions that will be reviewed by this NomCom are: Brian Carpenter -- General Area (IETF Chair) Ted Hardie -- Applications Area Mark Townsley -- Internet Area David Kessens -- Operations and Management Area Jon Peterson -- RT Apps Infrastructure Area (currently on one year term) Bill Fenner -- Routing Area Russ Housley -- Security Area Lars Eggert -- Security Area (currently on one year term) IAB members whose positions will be reviewed by this NomCom are: Bernard Aboba Loa Andersson Kurtis Lindqvist Dave Meyer Dave Thaler (currently on one year term) Lixia Zhang The IAOC member whose term will expire is: Jonne Soininen The nomination period will at end noon Pacific Time November 16, 2006. Any member of the IETF community my nominate any member of the IETF community for any position. Self-nominations are permitted and encouraged. Likewise, if you have any feedback regarding current incumbents, you can submit it via the online tool as comments to a nomination or send it to [EMAIL PROTECTED] Thanks! Andrew ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4688 on A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D
A new Request for Comments is now available in online RFC libraries. RFC 4688 Title: A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D Author: S. Rushing Status: Informational Date: October 2006 Mailbox:[EMAIL PROTECTED] Pages: 8 Characters: 13255 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-rushing-s1000d-urn-00.txt URL:http://www.rfc-editor.org/rfc/rfc4688.txt This document describes a Uniform Resource Name (URN) namespace for naming persistent resources defined by Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Security Implications of Using the Data Encryption Standard (DES)' to Informational RFC
The IESG has approved the following document: - 'Security Implications of Using the Data Encryption Standard (DES) ' draft-kelly-saag-des-implications-06.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kelly-saag-des-implications-06.txt Technical Summary Despite the fact that DES is susceptible to brute force attacks and has been deprecated, implementers continue to support it, sometimes as the default algorithm. RFC 4450 concluded that the Internet community would benefit from a document which explicitly spells out the security implications of using this algorithm. This document does just that. Working Group Summary This document is not a product of a Working Group. This document was announced on the SAAG mailing list, but there was no public discussion on that list. However, the author received a number of private comments, updating the document to address them. The document was reviewed at various stages by Paul Hoffman, Doug Whiting, Matt Curtin, Eric Rescorla, Bob Baldwin, and Yoav Nir. Protocol Quality This document was reviewed by Russ Housley for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Direct Data Placement over Reliable Transports' to Proposed Standard
The IESG has approved the following documents: - 'Direct Data Placement over Reliable Transports ' draft-ietf-rddp-ddp-07.txt as a Proposed Standard - 'A Remote Direct Memory Access Protocol Specification ' draft-ietf-rddp-rdmap-07.txt as a Proposed Standard These documents are products of the Remote Direct Data Placement Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rddp-ddp-07.txt Technical Summary Direct Data Placement Protocol (DDP) enables an Upper Layer Protocol (ULP) to send data to a Data Sink without requiring the Data Sink to Place the data in an intermediate buffer - thus when the data arrives at the Data Sink, the network interface can Place the data directly into the ULP's buffer. This can enable the Data Sink to consume substantially less memory bandwidth than a buffered model. Additionally, this can also enable the network protocol to consume substantially fewer CPU cycles than if the CPU was used to move the data, and removes the bandwidth limitation of only being able to move data as fast as the CPU can copy the data. DDP preserves ULP record boundaries (messages) while providing a variety of data transfer mechanisms and completion mechanisms to be used to transfer ULP messages. The Remote Direct Memory Access Protocol (RDMAP) operates over the Direct Data Placement Protocol (DDP). RDMAP provides read and write services directly to applications and enables data to be transferred directly into ULP Buffers without intermediate data copies. It also enables a kernel bypass implementation. Working Group Summary DDP provides two mechanisms, a Tagged Buffer mechanism for Remote DMA transfers where the network communication contains a destination memory offset, and an Untagged Buffer mechanism that supports socket-like sends where the receiver chooses the buffer on its own. The WG has strong consensus that both mechanisms are required in order for an implementation to exercise control over all memory buffer resources used for network communication. RDMAP supports both DMA (direct read/write to identified buffer) style and message (send, receiver selects buffer) style transfers. The WG has strong consensus that both transfer styles are required in order for an implementation to exercise control over all memory buffer resources used for network communication, and to appropriately support usage where a DMA style transfer is followed by a message style transfer whose reception is used to infer completion of the preceding DMA style transfer. Protocol Quality These protocols have been reviewed for the RDDP WG by David Black, who also acted as PROTO Shepherd. Francis Dupont ([EMAIL PROTECTED]) was the GEN-ART Reviewer for these documents. These protocols have been reviewed for the IESG by Lars Eggert and Jon Peterson. Note to RFC Editor Section 1 of draft-ietf-rddp-rdmap, last paragraph: this document are to be interpreted as described in [RFC2119]. ^ Note: remove the double-quote after the period. Section 10.1 of draft-ietf-rddp-rdmap: Remove the unused [VERBS] reference. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Operation of Anycast Services' to BCP
The IESG has approved the following document: - 'Operation of Anycast Services ' draft-ietf-grow-anycast-04.txt as a BCP This document is the product of the Global Routing Operations Working Group. The IESG contact persons are David Kessens and Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-grow-anycast-04.txt Technical Summary This document describes the use of anycast for both local scope distribution of services using an Interior Gateway Protocol and global distribution using BGP. Many of the issues for monitoring and data synchronisation are common to both, but deployment issues differ substantially. The document considers the design of anycast services, including considerations of protocol suitability, routing considerations, addressing considerations and multi-service configurations, as well as service management issues. Working Group Summary The document was adopted as a GROW WG document in February 2005, and further revised in accordance with WG comments. The WG position was a general consensus, with some residual points of dissension within the working group from a single party. Protocol Quality David Kessens reviewed this document for the IESG. Note to RFC Editor Please insert at the beginning of Section 1: This document is addressed to network operators who are considering whether to deploy or operate a distributed service using anycast. It describes the best current practice for doing so, but does not recommend whether any particular service should or should not be deployed using anycast. Please insert at the end of Section 4.1: Operators should be aware that, especially for long running flows, there are potential failure modes using anycast that are more complex than a simple 'destination unreachable' failure using unicast. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Procedures for protocol extensions and variations' to BCP
The IESG has approved the following document: - 'Procedures for protocol extensions and variations ' draft-carpenter-protocol-extensions-04.txt as a BCP This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-protocol-extensions-04.txt Technical Summary This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the larger IETF community. Working Group Summary No dissent reported. Protocol Quality The author is of course chair of the IESG, and Ross Callon has also reviewed this for the IESG. However, due to the fact that this discusses procedural issues that could affect a wide variety of IETF documents, I think that the all IESG members should review this carefully and individually. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
