Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Original Message All, This charter is definitely clearer on some of the points that were discussed based on the last version, but a couple of things still remain to be clarified. Based on several discussions that we've had lately, I have two suggestions for further clarity: 1. Let's add the text suggested by Harald and Lakshminath (there seemed to be agreement on this text on the list). Quoting the change proposed: Replace: "NEA can be limited in its applicability when the endpoint and the organization providing network access are owned by different parties." with "NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. That seems overbroad, in particular because a laptop that connects to multiple networks cannot in general be expected to adhere to conflicting policies of the networks to which it connects. As far as I can tell, this is the crux of the problem with NEA - that in general it's simply unreasonable for a network to demand that every host that connect to it conform to arbitrary policies for configuration of those hosts. IETF should not be standardizing unreasonable expectations. And even if the behavior is in some limited set of circumstances reasonable (which is debatable), IMHO IETF should hesitate to define standards for corner cases. (I do sympathize with the notion that the biggest threats to an enterprise network are from the hosts that connect directly to it, and so it makes sense to concentrate efforts for protecting the network at the points where those hosts attach to the network) The other problem I have with this charter is one that I have with many charters these days - it presupposes a particular design or architecture before the working group has actually met, when this should be an engineering decision taken by the consensus of the working group AFTER analysis of the problem space. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
> From: Keith Moore [mailto:[EMAIL PROTECTED] > As far as I can tell, this is the crux of the problem with > NEA - that in general it's simply unreasonable for a network > to demand that every host that connect to it conform to > arbitrary policies for configuration of those hosts. IETF > should not be standardizing unreasonable expectations. And > even if the behavior is in some limited set of circumstances > reasonable (which is debatable), IMHO IETF should hesitate to > define standards for corner cases. That is not my understanding of the problem statement. My understanding is that the specification will provide a description of the host configuration policy to the network, thus allowing the network to better decide whether to let the host connect. It is a network protocol, not an inter-network protocol. That is not new, DHCP is a network protocol and has no relevance to the inter-network. NEA is a security gloss on DHCP. > (I do sympathize with the notion that the biggest threats to > an enterprise network are from the hosts that connect > directly to it, and so it makes sense to concentrate efforts > for protecting the network at the points where those hosts > attach to the network) > > The other problem I have with this charter is one that I have > with many charters these days - it presupposes a particular > design or architecture > before the working group has actually met, when this should > be an engineering decision taken by the consensus of the > working group AFTER analysis of the problem space. That is the approach that the IETF has been configured for for 15 years. If you believe that a different architecture is appropriate you would have to convince people that that is the case. Working Groups that do no begin with a tightly defined architecture usually fail. There could be a role for the IAB to consider what the best overall Internet architecture is, but the IAB does not operate at that level. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
My network, my rules. If you don't like them go to the nearest Panera and use their free WiFi. If you want to connect to my network, my rules apply. That's not arbitrary, that's my right and my choice. perhaps. but I don't see why the IETF should provide tools to help you impose those rules - especially if to do so harms the flexibility of the Internet. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
As far as I can tell, this is the crux of the problem with NEA - that in general it's simply unreasonable for a network to demand that every host that connect to it conform to arbitrary policies for configuration of those hosts. IETF should not be standardizing unreasonable expectations. And even if the behavior is in some limited set of circumstances reasonable (which is debatable), IMHO IETF should hesitate to define standards for corner cases. That is not my understanding of the problem statement. My understanding is that the specification will provide a description of the host configuration policy to the network, thus allowing the network to better decide whether to let the host connect. that's my understanding also. but nothing you said here contradicts my statement. if connection of the host to the network is predicated on having the host conform to whatever arbitrary policy the network wishes to impose on how the host is configured, then it's unreasonable. the most that the network should be able to do is impose limitations on the kinds of traffic that host sends to or receives from the network. more broadly, the likely effect of standardizing a protocol that lets the network insist on a particular configuration for a host is to make the network less flexible over time, by reducing the number of kinds of hosts that can connect to a network. the unintended consequence of this proposal would thus be to reduce the flexibility of the Internet. It is a network protocol, not an inter-network protocol. true, but not relevant to this argument. The other problem I have with this charter is one that I have with many charters these days - it presupposes a particular design or architecture before the working group has actually met, when this should be an engineering decision taken by the consensus of the working group AFTER analysis of the problem space. That is the approach that the IETF has been configured for for 15 years. yes, and IMHO it's been wrong for 15 years. Working Groups that do no begin with a tightly defined architecture usually fail. that might say more about how WGs operate than anything else. we claim to do engineering around here, but the discipline of engineering requires that we understand a problem before we attempt to solve it. as long as we're not bothering to do that, we shouldn't be surprised when working groups produce "solutions" that don't solve problems. and there are plenty of these to be found in rfc-index.txt. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
> From: Keith Moore [mailto:[EMAIL PROTECTED] > that's my understanding also. but nothing you said here > contradicts my statement. if connection of the host to the > network is predicated on having the host conform to whatever > arbitrary policy the network wishes to impose on how the host > is configured, then it's unreasonable. So what if it is unreasonable. My network, my rules. If you don't like them go to the nearest Panera and use their free WiFi. If you want to connect to my network, my rules apply. That's not arbitrary, that's my right and my choice. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
> From: Keith Moore [mailto:[EMAIL PROTECTED] > > My network, my rules. If you don't like them go to the > nearest Panera and use their free WiFi. > > > > If you want to connect to my network, my rules apply. > That's not arbitrary, that's my right and my choice. > > perhaps. but I don't see why the IETF should provide tools > to help you impose those rules - especially if to do so harms > the flexibility of the Internet. Because the architecture you propose is failed and unworkable. You are still stuck in the Internet of 1980, you are like the hippie who turns up at Aldermaston for the Ban the Bomb march with a sign saying 'ban the Gattlin Gun', possibly a relevant concern if the march was being held in 1910 but utterly irrelevant to the issue of the day. The Internet has a billion users and in the future it will be common for houses to have over a hundred network connected devices. Very few of those hundred network connected devices will or should be Internet connected. I do not care what you think I might need but I do not want to spend my time worrying whether Mr Coffee is hacking into the fridge or the microwave is hosting a kiddie porn site. The best way to stop such nonsense is to recognize what every mainstream security specialist working in the field recognized long ago - there is a difference between the network and the inter-network and connection to either is a privilege that should only be granted on the basis of need. Your political strategy is naïve and fragile. You mistake a tactic for a strategy. Insisting that every component that connects to any network be absolutely unrestricted in its capabilities is unworkable, unsustainable and violates the security principle of least privilege. It is a tactic that is doomed to failure. Your goal appears to be to ensure that individual Internet subscribers have unrestricted connectivity to the Internet. The appropriate strategy for that goal is a consumer reports type strategy, measure what is delivered, award seals of approval accordingly. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Hallam-Baker, Phillip wrote: The best way to stop such nonsense is to recognize what every mainstream security specialist working in the field recognized long ago - there is a difference between the network and the inter-network and connection to either is a privilege that should only be granted on the basis of need. Your political strategy is naïve and fragile. You mistake a tactic for a strategy. Insisting that every component that connects to any network be absolutely unrestricted in its capabilities is unworkable, unsustainable and violates the security principle of least privilege. It is a tactic that is doomed to failure. I think the problem that Keith is talking about is the problem of "unreasonable" policies, which will instantly create a "criminal" subculture in any networks that have such "unreasonable" policies. For example, if the only ISPs that are available to me insist that the machine I connect to their precious network run Windows XP SP > foo, but I'm actually a Linux user, then techniques will emerge that allow me to fool the ISP into thinking that I'm a Windows XP SP > foo machine. Trying to enforce that a Turing-complete machine have capabilities "no greater than X" might seem to an IT senior manager to be a really good idea, but in practical terms, it can't be done. And if you try to do this in any but the most tightly-purposed networks, rebellion will be the inevitable result. Some companies have an emerging draconian policy about users running only "authorized" software on their machines, with a cumbersome "approvals" process for any new software that someone might want to run on their machine. Which includes software written by the user themselves. That type of policy might be "reasonable" in a call-center, or some other tightly-purposed network, but it fails in the general case, and true enforcement is impossible. This emerging draconian policy is subtly re-defining that which constitutes "useful work" in many places such that the only authorized things you can do with your machine are to shuffle Word, PowerPoint, and Excel documents around, surf the Web, and e-mail your co-workers. If you want to do "real work", you necessarily have to violate policy, or do your "real work" on a machine not subject to the policy. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
> From: Marcus Leech [mailto:[EMAIL PROTECTED] > I think the problem that Keith is talking about is the > problem of "unreasonable" policies, which will instantly create > a "criminal" subculture in any networks that have such > "unreasonable" policies. The people talking about NEA are generally talking about securing corporate networks. > For example, if the only ISPs that > are available to me insist that the machine I connect to > their precious network run Windows XP SP > foo, but I'm actually > a Linux user, then techniques will emerge that allow me to > fool the ISP into thinking that I'm a Windows XP SP > foo > machine. And what if the cable company decides to only broadcast Fox News? This is a political issue and not a technical one. This is not the purpose for which the specification is being proposed. The fact that some people might use it for that purpose is irrelevant. > Trying to enforce that a Turing-complete machine have > capabilities "no greater than X" might seem to an IT senior manager > to be a really good idea, but in practical terms, it can't > be done. Of course it can. Simply put a trustworthy computing partition on the machine. Palladium is more than capable of providing a proof that would be prohibitively expensive to defeat. > And if you try to do this in any but the most tightly-purposed > networks, rebellion will be the inevitable result. So you accept that the abuse scenario is not credible. > Some companies have an emerging draconian policy about users > running only "authorized" software on their machines, with > a cumbersome "approvals" process for any new software that > someone might want to run on their machine. True, I expect this to become the default. > Which includes > software written by the user themselves. That type of > policy might be "reasonable" in a call-center, or some other > tightly-purposed network, but it fails in the general case, > and true enforcement is impossible. This emerging draconian > policy is subtly re-defining that which constitutes "useful > work" in many places such that the only authorized things > you can do with your machine are to shuffle Word, > PowerPoint, and Excel documents around, surf the Web, > and e-mail your co-workers. That is a matter for you to discuss with your employer. It is not something that a standards body should consider. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Hi Vidya Inline ... > -Original Message- > From: Narayanan, Vidya [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 24, 2006 2:15 AM > To: iesg@ietf.org; ietf@ietf.org > Cc: [EMAIL PROTECTED] > Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint > Assessment (nea) > > All, > > This charter is definitely clearer on some of the points that were > discussed based on the last version, but a couple of things > still remain > to be clarified. Based on several discussions that we've had lately, I > have two suggestions for further clarity: > > 1. Let's add the text suggested by Harald and Lakshminath > (there seemed > to be agreement on this text on the list). Quoting the change > proposed: > > Replace: > > "NEA can be limited in its applicability when the endpoint and the > organization providing network access are owned by different parties." > > with > > "NEA is applicable to computing environments of enterprises where > endpoints accessing the enterprise's network are owned and/or expected > to conform to the policies set forth by the organization that owns and > operates the network. All other cases are outside the scope > of the NEA > charter, since we do not know that NEA would be useful in > such cases." > I don't think there is consensus around this text, and I can think of existing deployment scenarios that might be ruled out by this text and also where it might be considered to be too broad. I would rather allow the WG the time to define terminology and discuss criteria that determine applicability, e.g. who owns the endpoint versus who manages the endpoint (these may be different), so that we can do a clearer job articulating this. I don't think we are going to complete this now, and given there is an explicit action in the charter to address applicability, I think this should be good enough. > 2. On the mandatory-to-implement PT protocol, I would like to see the > clarification that the protocol must allow the NEA process to > run either > at the time of network access or while connected. This clarification > seems mainly needed because there is text elsewhere in the > charter about > allowing NEA runs "at network access or while connected" - if > that text > is removed, this clarification won't be required. > I don't think this really matters, but in the interests of closing on this, will remove the text you refer to. Thanks Susan > Thanks, > Vidya > > > -Original Message- > > From: IESG Secretary [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, October 17, 2006 12:50 PM > > To: ietf-announce@ietf.org > > Cc: [EMAIL PROTECTED] > > Subject: [Nea] UPDATED: WG Review: Network Endpoint > Assessment (nea) > > > > A new IETF working group has been proposed in the Security Area. > > The IESG has not made any determination as yet. The following > > UPDATED draft charter was submitted, and is provided for > > informational purposes only. Please send your comments to the > > IESG mailing list (iesg@ietf.org) by October 23rd. > > > > +++ > > > > Network Endpoint Assessment (nea) > > === > > > > Current Status: Proposed Working Group > > > > Chair(s): > > TBD > > > > Security Area Director(s): > > Russ Housley <[EMAIL PROTECTED]> > > Sam Hartman <[EMAIL PROTECTED]> > > > > Security Area Advisor: > > Russ Housley <[EMAIL PROTECTED]> > > > > Mailing List: [EMAIL PROTECTED] > > > > Description of Working Group: > > > > Network Endpoint Assessment (NEA) architectures have been > > implemented in the industry to assess the "posture" of > > endpoint devices for the purposes of monitoring compliance to > > an organization's posture policy and optionally restricting > > access until the endpoint has been updated to satisfy the > > posture requirements. An endpoint that does not comply with > > posture policy may be vulnerable to a number of known threats > > that may exist on the network. The intent of NEA is to > > facilitate corrective actions to address these known > > vulnerabilities before a host is exposed to potential attack. > > Note that an endpoint that is deemed compliant may still be > > vulnerable to unknown threats that may exist on the network. > > The network may thus continue to be exposed to such threats > > as well as the range of other threats not addressed by > > maintaining endpoint compliance. > > > > Posture refers to the hardware or software configuration of > > an endpoint as it pertains to an organization's security > > policy. Posture may include knowledge that software installed > > to protect the machine (e.g. patch management software, > > anti-virus software, host firewall software, host intrusion > > protection software or any custom software) is enabled and > > up-to-date. On network access and while connected, an > > endpoint supporting NEA protocols can be queried for such > > posture information. > > > > An organization may make a range of policy decisions b
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
My network, my rules. If you don't like them go to the nearest Panera and use their free WiFi. If you want to connect to my network, my rules apply. That's not arbitrary, that's my right and my choice. perhaps. but I don't see why the IETF should provide tools to help you impose those rules - especially if to do so harms the flexibility of the Internet. Because the architecture you propose is failed and unworkable. I didn't propose anything resembling an architecture. and the proposal at hand is an anti-architecture - it's something that destroys the possibility of a unifying theme. You are still stuck in the Internet of 1980, you are like the hippie who turns up at Aldermaston for the Ban the Bomb march with a sign saying 'ban the Gattlin Gun', possibly a relevant concern if the march was being held in 1910 but utterly irrelevant to the issue of the day. Phill, you are not in a very good position to be judging my character or trying to extrapolate what I've said into a model of how my mind works. You are too stuck in your own little world to understand mine. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Hallam-Baker, Phillip wrote: Trying to enforce that a Turing-complete machine have capabilities "no greater than X" might seem to an IT senior manager to be a really good idea, but in practical terms, it can't be done. Of course it can. Simply put a trustworthy computing partition on the machine. Palladium is more than capable of providing a proof that would be prohibitively expensive to defeat. I, and others, dispute that such "proofs" are proof of anything really meaningful, and that defeating them would be "prohibitively expensive to defeat". But that is territory that is emphatically not part of the work of this group. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Whether a company manageing a network demands that all hosts meet a specific policy is a local policy issue and the charter specifically addresses this concern: "An organization may make a range of policy decisions based on the posture of an endpoint. NEA is not intended to be prescriptive in this regard. " what the WG charter says and how the WG output is used are different things. IMHO we need to consider the potential unintended consequences of our efforts in IETF, not just what we intend. network operators do not limit their use of technology to what we write in applicability statements. I think the intent of the working group is to standardize the data formats and protocols so that NEA components can talk together, not to say what to do with non-compliant hosts. That is a local policy decsion. But to get to that decision, the components first have to communicate. At a very high level, this isn't much different than RADIUS, which defines the data formats and protocols between a network access device such as modem pool and the RADIUS server. I don't think it's a good analogy because modem pools are very special-purpose devices, whereas a host can potentially do anything that needs to communicate with something else. For that matter, RADIUS doesn't have the intent of preventing some kinds of modem pools from connecting to the network. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
> From: Keith Moore [mailto:[EMAIL PROTECTED] > > Because the architecture you propose is failed and unworkable. > > I didn't propose anything resembling an architecture. and > the proposal at hand is an anti-architecture - it's something > that destroys the possibility of a unifying theme. So you see your role as wrecking proposals rather than making constructive proposals of your own? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Hi Susan,
Having the applicability text baselined in the charter is necessary
in my view. The current charter text is vague ("can be
limited"). If you want to propose a revision of the text that
Harald, Vidya and I are ok with, please do so. Given that this is up
for discussion and decision in 2 days, let's work quickly on it.
thanks,
Lakshminath
At 09:39 AM 10/24/2006, Susan Thomson \(sethomso\) wrote:
Hi Vidya
Inline ...
> -Original Message-
> From: Narayanan, Vidya [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 24, 2006 2:15 AM
> To: iesg@ietf.org; ietf@ietf.org
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint
> Assessment (nea)
>
> All,
>
> This charter is definitely clearer on some of the points that were
> discussed based on the last version, but a couple of things
> still remain
> to be clarified. Based on several discussions that we've had lately, I
> have two suggestions for further clarity:
>
> 1. Let's add the text suggested by Harald and Lakshminath
> (there seemed
> to be agreement on this text on the list). Quoting the change
> proposed:
>
> Replace:
>
> "NEA can be limited in its applicability when the endpoint and the
> organization providing network access are owned by different parties."
>
> with
>
> "NEA is applicable to computing environments of enterprises where
> endpoints accessing the enterprise's network are owned and/or expected
> to conform to the policies set forth by the organization that owns and
> operates the network. All other cases are outside the scope
> of the NEA
> charter, since we do not know that NEA would be useful in
> such cases."
>
I don't think there is consensus around this text, and I can think of
existing deployment scenarios that might be ruled out by this text and
also where it might be considered to be too broad. I would rather allow
the WG the time to define terminology and discuss criteria that
determine applicability, e.g. who owns the endpoint versus who manages
the endpoint (these may be different), so that we can do a clearer job
articulating this. I don't think we are going to complete this now, and
given there is an explicit action in the charter to address
applicability, I think this should be good enough.
> 2. On the mandatory-to-implement PT protocol, I would like to see the
> clarification that the protocol must allow the NEA process to
> run either
> at the time of network access or while connected. This clarification
> seems mainly needed because there is text elsewhere in the
> charter about
> allowing NEA runs "at network access or while connected" - if
> that text
> is removed, this clarification won't be required.
>
I don't think this really matters, but in the interests of closing on
this, will remove the text you refer to.
Thanks
Susan
> Thanks,
> Vidya
>
> > -Original Message-
> > From: IESG Secretary [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, October 17, 2006 12:50 PM
> > To: ietf-announce@ietf.org
> > Cc: [EMAIL PROTECTED]
> > Subject: [Nea] UPDATED: WG Review: Network Endpoint
> Assessment (nea)
> >
> > A new IETF working group has been proposed in the Security Area.
> > The IESG has not made any determination as yet. The following
> > UPDATED draft charter was submitted, and is provided for
> > informational purposes only. Please send your comments to the
> > IESG mailing list (iesg@ietf.org) by October 23rd.
> >
> > +++
> >
> > Network Endpoint Assessment (nea)
> > ===
> >
> > Current Status: Proposed Working Group
> >
> > Chair(s):
> > TBD
> >
> > Security Area Director(s):
> > Russ Housley <[EMAIL PROTECTED]>
> > Sam Hartman <[EMAIL PROTECTED]>
> >
> > Security Area Advisor:
> > Russ Housley <[EMAIL PROTECTED]>
> >
> > Mailing List: [EMAIL PROTECTED]
> >
> > Description of Working Group:
> >
> > Network Endpoint Assessment (NEA) architectures have been
> > implemented in the industry to assess the "posture" of
> > endpoint devices for the purposes of monitoring compliance to
> > an organization's posture policy and optionally restricting
> > access until the endpoint has been updated to satisfy the
> > posture requirements. An endpoint that does not comply with
> > posture policy may be vulnerable to a number of known threats
> > that may exist on the network. The intent of NEA is to
> > facilitate corrective actions to address these known
> > vulnerabilities before a host is exposed to potential attack.
> > Note that an endpoint that is deemed compliant may still be
> > vulnerable to unknown threats that may exist on the network.
> > The network may thus continue to be exposed to such threats
> > as well as the range of other threats not addressed by
> > maintaining endpoint compliance.
> >
> > Posture refers to the hardware or software configuration of
> > an endpoint as it pertains to an organization's security
> > policy. Posture may include knowledge that software installed
> > to protect the machine (e.g. patch man
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Keith Moore writes... > what the WG charter says and how the WG output is used are > different things. IMHO we need to consider the potential > unintended consequences of our efforts in IETF, not just what > we intend. network operators do not limit their use of > technology to what we write in applicability statements. Should I infer from this sentiment that you believe that the IETF ought to refrain from standardizing any technology that could be used by public or private network operators to discriminate against certain classes of clients, based on the "posture" of their hosts? I'll point out that only certain kinds of discrimination are undesirable, i.e. discrimination against protected classes. Other kinds of discrimination, e.g. helping to maintain a "safe computing" environment within a network, are highly desirable. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Keith Moore wrote: That seems overbroad, in particular because a laptop that connects to multiple networks cannot in general be expected to adhere to conflicting policies of the networks to which it connects. Exactly. That's why there are provisions for non-conforming systems. Network access can be denied entirely, or limited to the public (and unprotected) network. However, 99% of systems don't move networks, so those systems don't have a problem conforming to the local requirements. do you have actual statistics to back that up? are 99% of hosts produced servers or desktops rather than laptops? and how are you defining a host, anyway? sorry, it just looks like a number picked out of thin air. even if the 99% figure is true today, will it be true in general in the future? personally I think that desktops as we know them are dinosaurs. they are too much of a security threat, too expensive to maintain, offer more flexibility than is needed, and are becoming a vector by which extortionist licensing fees can be extracted from owners. and the trend seems to be toward more and more mobile devices and special purpose devices. standards take a long time to produce and need to last a long time, so it make sense to define them in such a way as to be likely to continue to be useful for the foreseeable future. As far as I can tell, this is the crux of the problem with NEA - that in general it's simply unreasonable for a network to demand that every host that connect to it conform to arbitrary policies for configuration of those hosts. I'm not sure how to take this. It's unreasonable... OK, why? because the very nature of a personal computer is one in which every machine is customizable to suit the needs of the individual user. if the network takes away that flexibility, it also obviates the need for a user-programmable personal computer. there are better (more reliable, more secure, more effective, cheaper) ways of providing a set of functions at a user terminal than to give everyone user-programmable machines and then have the network insist that they all have a rigidly controlled configuration...and the only way to really get security out of PCs is to rigidly control their configurations. and furthermore if PCs continue to be user-programmable then it becomes possible to make NEA meaningless. (though the protocol could make it difficult for a host to forge assertions about itself by having the host sign the assertions with a key signed by the NEA software vendor, it would take some significant cleverness to prevent that key from being exposed to an attacker on that host, particularly one with physical access to the host). NEA isn't about knowing "who" is on your network in the sense of determining identity, it's about being able to delve into arbitrary details of host configuration. The other problem I have with this charter is one that I have with many charters these days - it presupposes a particular design or architecture before the working group has actually met, when this should be an engineering decision taken by the consensus of the working group AFTER analysis of the problem space. I think it presupposes a particular problem, not an architecture. The problem is: a) knowing who is on my network b) controlling who is on my network c) controlling the behavior of the hosts on my network. If any of those problems are unreasonable to solve, then I would be *very* confused. The proposed NEA architecture derives directly from that problem statement. to me it seems to presuppose much more than that, by naming the kinds of actors and their roles. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Hallam-Baker, Phillip wrote: From: Keith Moore [mailto:[EMAIL PROTECTED] that's my understanding also. but nothing you said here contradicts my statement. if connection of the host to the network is predicated on having the host conform to whatever arbitrary policy the network wishes to impose on how the host is configured, then it's unreasonable. So what if it is unreasonable. My network, my rules. If you don't like them go to the nearest Panera and use their free WiFi. If you want to connect to my network, my rules apply. That's not arbitrary, that's my right and my choice. I'm unclear on what host requirements NEA is proposing to add. The reality is that I have about 2 giant corporations to choose from for Internet connectivity where I live. I don't want either one of them installing mandatory software on my computers that denies access to the Internet if any "unapproved" applications are found. I would rather decide which applications I get to run, and if the ISP chooses to firewall certain protocols, then fine. Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
So you see your role as wrecking proposals rather than making constructive proposals of your own? do you by any chance listen to Rush Limbaugh? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Progressive Posting Rights Supsensions' to ...
I agree with John K lets purge 2418, 3683 etc of any language that appears to limit enforcement options and work things out on a case by case basis Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
what the WG charter says and how the WG output is used are different things. IMHO we need to consider the potential unintended consequences of our efforts in IETF, not just what we intend. network operators do not limit their use of technology to what we write in applicability statements. Should I infer from this sentiment that you believe that the IETF ought to refrain from standardizing any technology that could be used by public or private network operators to discriminate against certain classes of clients, based on the "posture" of their hosts? I think it's dangerous territory, and IETF needs to be very careful about how the subject is approached. I don't think the current NEA charter reflects that kind of care, and I don't think that IETF processes for WG adoption really facilitate that kind of care. Within existing IETF structure defining the appropriate direction for a group like NEA probably calls for an IAB workshop - which unfortunately is a lot slower than you want if you're trying to ship product and have it blessed as a standard. Clearly there is some potential benefit at being able to identify hosts that present a risk to the network to which they are attached. But there's a very large and unpleasant camel attached to that nose. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
> "Susan" == Susan Thomson (sethomso) <[EMAIL PROTECTED]> writes: Susan> Hi Vidya Inline ... >> -Original Message- From: Narayanan, Vidya >> [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 >> 2:15 AM To: iesg@ietf.org; ietf@ietf.org Cc: [EMAIL PROTECTED] >> Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint >> Assessment (nea) >> >> All, >> >> This charter is definitely clearer on some of the points that >> were discussed based on the last version, but a couple of >> things still remain to be clarified. Based on several >> discussions that we've had lately, I have two suggestions for >> further clarity: >> >> 1. Let's add the text suggested by Harald and Lakshminath >> (there seemed to be agreement on this text on the >> list). Quoting the change proposed: >> >> Replace: >> >> "NEA can be limited in its applicability when the endpoint and >> the organization providing network access are owned by >> different parties." >> >> with >> >> "NEA is applicable to computing environments of enterprises >> where endpoints accessing the enterprise's network are owned >> and/or expected to conform to the policies set forth by the >> organization that owns and operates the network. All other >> cases are outside the scope of the NEA charter, since we do not >> know that NEA would be useful in such cases." >> Susan> I don't think there is consensus around this text, and I Susan> can think of existing deployment scenarios that might be Susan> ruled out by this text and also where it might be Susan> considered to be too broad. Ah. Count me as one in favor of the text (although I do not object to the old text). I didn't speak up because I thought there was consensus. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
> -Original Message- > From: Sam Hartman [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 24, 2006 10:28 AM > To: Susan Thomson (sethomso) > Cc: Narayanan, Vidya; [EMAIL PROTECTED]; iesg@ietf.org; ietf@ietf.org > Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint > Assessment (nea) > > > "Susan" == Susan Thomson (sethomso) <[EMAIL PROTECTED]> writes: > > Susan> Hi Vidya Inline ... > > >> -Original Message- From: Narayanan, Vidya > >> [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 > >> 2:15 AM To: iesg@ietf.org; ietf@ietf.org Cc: [EMAIL PROTECTED] > >> Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint > >> Assessment (nea) > >> > >> All, > >> > >> This charter is definitely clearer on some of the points that > >> were discussed based on the last version, but a couple of > >> things still remain to be clarified. Based on several > >> discussions that we've had lately, I have two suggestions for > >> further clarity: > >> > >> 1. Let's add the text suggested by Harald and Lakshminath > >> (there seemed to be agreement on this text on the > >> list). Quoting the change proposed: > >> > >> Replace: > >> > >> "NEA can be limited in its applicability when the endpoint and > >> the organization providing network access are owned by > >> different parties." > >> > >> with > >> > >> "NEA is applicable to computing environments of enterprises > >> where endpoints accessing the enterprise's network are owned > >> and/or expected to conform to the policies set forth by the > >> organization that owns and operates the network. All other > >> cases are outside the scope of the NEA charter, since we do not > >> know that NEA would be useful in such cases." > >> > > Susan> I don't think there is consensus around this text, and I > Susan> can think of existing deployment scenarios that might be > Susan> ruled out by this text and also where it might be > Susan> considered to be too broad. > > Ah. Count me as one in favor of the text (although I do not > object to the old text). I didn't speak up because I thought > there was consensus. > I thought so as well. There were a few who explicitly agreed and I saw no disagreements on the list. Vidya ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
I don't see how NEA is such a big philosophical change from existing RADIUS practices. perhaps not, but I don't see how past mistakes are a justification for future ones. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Progressive Posting Rights Supsensions' to ...
Scott Bradner wrote: I agree with John K lets purge 2418, 3683 etc of any language that appears to limit enforcement options and work things out on a case by case basis Just to be clear, the intention of sections 1 and 2 of draft-carpenter-rescind-3683-03 is to remove the limitations on 2418 inadvertently introduced by 3934. That is quite separable logically from rescinding 3683; hence the form of Sam's questions. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
do you have actual statistics to back that up? It's not meant to be an exact number, but it's pretty close to being correct, in my experience. one of my axioms for dealing with the Internet is that people's experiences (and assumptions) about what is typical vary widely - no single person's assumptions holds true in general. the consequence for protocol standards is that they need to work in the face of a variety of assumptions/scenarios. there are better (more reliable, more secure, more effective, cheaper) ways of providing a set of functions at a user terminal than to give everyone user-programmable machines and then have the network insist that they all have a rigidly controlled configuration... Yes. And there are mistakes in IETF protocols that have been deployed for decades, too. What are we supposed to tell the people who have billions of dollars invested in their current systems? "You got it wrong, we're not going to come up with a solution to your problems." ? no, we say "we're going to try to give you an evolution path that doesn't break compatibility with the investment you've made in our technology". however realize that the half-life of a computer system is pretty short compared to the lifetime of a successful protocol standard. there's more investment in the protocols than in the hardware, and the protocols don't generally assume user-programmable machines on everyone's desks. (a few of them predate those days) Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Progressive Posting Rights Supsensions' to BCP (draft-carpenter-rescind-3683)
John C Klensin wrote: --On Monday, 23 October, 2006 21:22 +0200 Brian E Carpenter <[EMAIL PROTECTED]> wrote: ... In general, at least as things are now, I would prefer that this current draft simply be dropped, and the current status be retained. The problem with the current status is that we have no tools intermediate between 30 days suspension by a WG Chair and indefinite suspension by PR-action. That gives us a small hammer and a very big hammer, and nothing for medium size nails. Brian, I've been trying to avoid this discussion, but it appears to me that, especially if the plan is to tune things further, there is a middle ground in the proposals and comments that have been made... and the subject draft isn't it. I think that middle ground has the following elements: (1) Any language in 3683 that appears to limit other actions with regard to mailing list abuse needs to be overridden. Ah, but the limiting language is in 3934. Hence the restructuring of the -03 version of the draft. In Montreal, I was convinced that the best way to do that, given levels of discussion that turned into what, IMO, were self-inflicted DoS attacks on getting any IETF list work done, was to get rid of 3683. I'm no longer convinced and think that, maybe, the right thing to do in the short term is a very short document (or piece of document), that simply overrides any provisions of 3683, 3934, 2418, and even 4633 that appear to constrain other options for dealing with a problem. If we can remember that we aren't a legislature trying to write laws that cannot be interpreted in unreasonable ways, I think that material should be moderately easy to write. Given my reading of the various documents, it's written: sections 1 and 2 of the -03 draft. (2) We should let the experiment of 4633 run its course before doing major retuning. It seems to me that the intent of that document is to provide ways to establish, and experiment with, exactly the type of "hammer for medium-sized nails" that you suggest is missing. Indeed, if I read 4633 correctly, we can do the overriding suggested above at our collective leisure, since it seems to permit any or all of the intermediate measures. I would completely agree with that. See http://www.ietf.org/IESG/content/experiments.html (3) 3683, at least for the present, should remain on the table. Efforts to initiate 3683 proceedings should consider not only the behavior of the claimed offender but also the amount of community energy a 3683 action takes up. If that deters some 3683-type PR actions as just not worth the energy, fine. If not, then perhaps the comments suggesting that an indefinite suspension that is expected to be more or less permanent should require community discussion are correct... (4) It seems to me that the arguments that we should not permit indefinite (or very long) suspensions without some more formal action and opportunity for community comment have merit. If so, I would hope that can be taken as guidance for those involved, especially when approving actions under 4633. If that guidance is not heeded, that would seem to be grounds for a "procedures aren't working adequately or as intended" appeal, which would force the then-required community discussion. Otherwise, we revisit that question at the end of the 4633 period, i.e., revisit that and other questions in 16 months, more or less. Given 4633 and the comments above, what do you think we need to do now... other than, possibly, un-doing the sections of the existing specs that appear to limit, rather than expand, options? Well, I'll wait until Sam summarizes this Last Call. My own personal feeling is that we *really* need to fix the problem caused by 3934, so that we can tune the hammers to the nails. As you say, applying 3683 is not compulsory, so the world will not come to an end if it lies on the books. Brian john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
> -Original Message- > From: Alan DeKok [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 24, 2006 11:29 AM > To: Keith Moore > Cc: [EMAIL PROTECTED]; iesg@ietf.org; ietf@ietf.org > Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint > Assessment (nea) > > Keith Moore wrote: > > I don't think it's a good analogy because modem pools are very > > special-purpose devices, whereas a host can potentially do anything > > that needs to communicate with something else. For that matter, > > RADIUS doesn't have the intent of preventing some kinds of > modem pools > > from connecting to the network. > > No, but it has the explicit intent of preventing some kinds > of hosts from connecting to the network. Current RADIUS > deployments implement almost anything you can imagine to > control network access for hosts and/or users, down to > filtering the users network traffic. Current RADIUS > deployments *already* do ad-hoc posture assessment, there are > a number of startups implementing this today. > > I don't see how NEA is such a big philosophical change from > existing RADIUS practices. > I can sort of buy the analogy to RADIUS, although the AAA protocols are intended to do a lot more (the third "A" for instance). However, RADIUS doesn't inherently claim any security properties, while NEA seems to. RADIUS (or Diameter, for that matter) cannot really guarantee any level of security for network access control - that is dependent on what is carried in RADIUS (sometimes, a couple of levels down - e.g., EAP Method over EAP over RADIUS, where the strength is really dependent on the EAP method). Also, the strength of the second "A" in AAA depends on the kind of authorization policies in place. AAA is just a framework facilitating these - not a protocol that has some security claims to it. Vidya ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Progressive Posting Rights Supsensions' to BCP (draft-carpenter-rescind-3683)
Date:Fri, 20 Oct 2006 18:29:37 -0400 From:The IESG <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> I guess I should reply to the questions... | 1) Do you support the proposal in section 2 of the draft to restore | the AD and IESG's ability to suspend posting rights for longer than | 30 days and to approve alternative methods of mailing list control | as originally documented in RFC 2418? The proposal, as a general thing, yes, the method it does it, no. | 2) Do you support the proposal in section 3 to rescind RFC 3683? Not at this time. | 3) Do you have any concerns about approving one part of the draft | without approving the other? Yes, of course - the IESG can't (or shouldn't) do things like that, the right way is to produce a new draft that contains the new proposal, and have that last called, so the community can see and comment on the new version. Too many more than editorial changes get made to docs as part of the approval process already, aside from trivia like spelling mistakes and out of date references (which should be the RFC editor's job to fix anyway) the draft approved (or not) should be exactly the draft last called, and not something different - if it has problems, have them corrected them and issue a new last call. | 4) Do you have any other comments on the document? Since a whole new draft needs to be written anyway, more comments on this one aren't worth anyone's time. Lastly, in response to my last message, Brian said ... | One bit of missing context is that in the General Area open meeting in | Montreal, we did discuss the general issue and Jim Galvin took the action to | follow up with a few interested parties. We don't have a draft yet, but the | idea of the present draft was to fix a couple of immediate issues, not to be | the end of the matter. That's interesting, but irrelevant. Either this draft stands alone, and should result in a workable situation, with only the changes in this draft, or it is to be part of a set of changes, in which case it needs to wait until the other changes are ready to proceed. Saying "we're going to do something else, but take this change as a short term fix, even though it isn't really adequate" simply isn't acceptable. kre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
> Whether a company manageing a network demands that all hosts meet a > specific policy is a local policy issue and the charter specifically > addresses this concern: > > "An organization may make a range of policy decisions based on the > posture of an endpoint. NEA is not intended to be prescriptive in > this regard. " what the WG charter says and how the WG output is used are different things. IMHO we need to consider the potential unintended consequences of our efforts in IETF, not just what we intend. Keith, I have two big problems with this position. First of all, I have grave doubts our crystal ball is up to the task of forseeing all unintended consequences of the protocol we develope. So while I think some consideration of consequences is OK, we also need to keep in mind that we collectively pretty much suck at predicting the future. Second, consequences don't just attach to the roads we take, they also attach to the roads not taken. When we say "no" to something it often ends up being done in an ad hoc way that can potentially be far more damaging to the network than had we created a standard with the proper security mechanisms, applicability statements, and so on. I also think NEA is a good example of something that will cause a lot less problems if we do it right than if it is done in a bad and proprietary way. I started hearing talk about implementating NEA-like mechanisms at several large sites long before I ever heard of NEA. I therefroe believe that mechanisms to do this are going to be developed and deployed no matter what the IETF does. The only question is whether or not we're going to have a say in what gets done. I really don't want to see a situation arise where I can't use, say, my Linux laptop somwhere because the necessary secret handshake is some proprietary glop that only Windoze boxes can do. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
what the WG charter says and how the WG output is used are different things. IMHO we need to consider the potential unintended consequences of our efforts in IETF, not just what we intend. Keith, I have two big problems with this position. First of all, I have grave doubts our crystal ball is up to the task of forseeing all unintended consequences of the protocol we develope. So while I think some consideration of consequences is OK, we also need to keep in mind that we collectively pretty much suck at predicting the future. I agree. But we don't usually have to actually predict the future in order to make ourselves aware of the potential pitfalls associated with something that we're thinking about doing, and to take those pitfalls into account in a design. In the case of NEA those pitfalls aren't too hard to figure out, but nothing has been proposed to address those pitfalls other than inconsequential wording suggestions about the scope of the WG. The WG scope isn't the problem so much as the protocol itself. Figure out a way to keep the protocol from doing harm, and I'll be much more interested. Second, consequences don't just attach to the roads we take, they also attach to the roads not taken. When we say "no" to something it often ends up being done in an ad hoc way that can potentially be far more damaging to the network than had we created a standard with the proper security mechanisms, applicability statements, and so on. I agree also that this potential exists. One of the things that really bothers me about our WG creation process is that a lot of fundamental decisions about direction of a particular effort tend to be made with zero investigation of alternatives and little or no community input. Whatever gets written into the charter is essentially carved in stone, and sometimes the WGs don't even pay attention to whatever limitations are included in their charter - they just continue with whatever they started doing before the charter was approved. In the case of NEA (as in so many other cases) we (the wider community) are being presented with this as a done deal - either take this charter (modulo minor wording changes) or leave it. I sincerely believe that IETF can do something useful in this general space, but I also sincerely doubt that NEA is the right direction. And yet, we're already asking a yes or no question when it really should be a "how can we address these problems?" question. Is the wrong direction better than no contribution from IETF in this case? It's not entirely clear, but I suspect that in this case the answer is no. And yes, I'm also aware that historically when we charter a WG to study a problem and draft "requirements", they tend to wallow around and not produce much of any use. I also think NEA is a good example of something that will cause a lot less problems if we do it right than if it is done in a bad and proprietary way. I started hearing talk about implementating NEA-like mechanisms at several large sites long before I ever heard of NEA. I therefroe believe that mechanisms to do this are going to be developed and deployed no matter what the IETF does. I agree. But is that really so bad? To me it isn't axiomatic that the Internet is better off if every application type that is widely deployed has a standard protocol. DRM is a good example - until DRM can, at a minimum, preserve a balance of interests between the public and rightsholders, the Internet is better off without standards for DRM. A similar argument can be made for NEA - there needs to be a way to preserve a balance between the rights of host owners and the rights of network owners. (one particularly chilling scenario is for a network to use NEA to force every host that connects to it to implement a form of DRM that compromises the interests of the public) The only question is whether or not we're going to have a say in what gets done. I really don't want to see a situation arise where I can't use, say, my Linux laptop somwhere because the necessary secret handshake is some proprietary glop that only Windoze boxes can do. IMHO, that is _more_ likely to happen if NEA is standardized than if there are some number of proprietary solutions. Ketih ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: NEA compelling problem (but no deployment)
>But I think that's beside the point - the use cases for which we know >that NEA may be useful are already compelling enough that we should stop >debating whether or not to charter the group and get on with the work. While I do agree that the *problem* being described is compelling, that does not imply that the architecture being described represents a workable solution to that problem. The solutions that customers are currently deploying tend to be considerably simpler and more general than the NEA architecture. For example, few of these solutions rely on EAP, or require forklift upgrades of routers or switches. Few involve elaborate "posture conversations" on each network access. Instead, the solutions that are being deloyed tend to be based on "appliances" that are compatible with any operating system or network infrastructure and have negligible impact on the performance of non-infected hosts. They are therefore easy to deploy and inexpensive to operate. With NEA as with any other Internet technology, performance and ease of deployment matter. Some food for thought: http://www.itbusinessedge.com/item/?ci=8349 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Inherent problems in the NEA architecture
> "NEA is applicable to computing environments of enterprises > where endpoints accessing the enterprise's network are owned > and/or expected to conform to the policies set forth by the > organization that owns and operates the network. All other > cases are outside the scope of the NEA charter, since we do > not know that NEA would be useful in such cases." I would like to point out that in a number of cases it is not possible for the host to determine what network it is connecting to. For example, IEEE 802.1X-2004 does not provide an equivalent to the Beacon offered by say, IEEE 802.11. As a result, the host may not necessarily be able to determine what credentials to use, what information it can or should disclose, or even whether it is appropriate for it to make use of the remediation capabilities offered by the network it is connecting to. It has already been pointed out that the architecture described does not support mobility very well. To provide some perspective on the impact of this, currently notebooks comprise more than 55% of all computers sold by revenue; by the time that the NEA standards are complete, this may be closer to 75 or even 80 percent. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
