On 12/21/11 15:02 , Naiming Shen wrote: > > Hi Jared, > > I completely agree. That is one of the reasons this draft has the > authentication object also defined. > The source of the query has to be a trusted host in order to reveal > network/enterprise private > information from the responder.
So, something targeted through the forwarding plane that filters up to the control plane will be filtered first either by source address or passed through a rate limiter or both because those are the protections we have that actually scale. Authentication increases the vulnerability to some kinds of abuse rather that decreasing it. > thanks. > - Naiming > > On Dec 21, 2011, at 2:57 PM, Jared Mauch wrote: > >> The idea that network operators will allow someone outside their >> administrative control have this level of visibility is interesting but >> unworkable. >> >> Those who wish to reveal this data can do so via other means such as public >> looking glasses and graphs. The major networks will not reveal this. >> >> Jared Mauch >> >> On Dec 20, 2011, at 5:41 PM, Naiming Shen <naim...@cisco.com> wrote: >> >>> >>> Hi Wes, >>> >>> Sure you can certainly use tools such as SNMP to query on those info, >>> the same thing can be said using SNMP to query on MPLS and interface >>> related information also. Although this is not only for one host, this is >>> generally >>> used by Traceroute application when traverse a list of hosts/routers. >>> >>> thanks. >>> - Naiming >>> >>> On Dec 20, 2011, at 1:52 PM, George, Wes wrote: >>> >>>>> From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On >>>>> Behalf Of Naiming Shen >>>>> Sent: Tuesday, December 20, 2011 3:23 PM >>>>> >>>>> I would >>>>> think it's useful to return the icmp response like: "i'm the VM for >>>>> location >>>>> tracking service with SQL database, CPU 80% busy" >>>>> >>>> >>>> [WEG] No, absolutely not. We have multiple protocols to handle this >>>> information already, with significantly better granularity of information >>>> as well as access control permissions (who is allowed to query/receive >>>> this information), most notably SNMP. There is *zero* reason to try to >>>> bolt this sort of information into an ICMP datagram. >>>> Please stick to information that is not available via alternate means if >>>> you are trying to justify its existence. >>>> >>>> Thanks >>>> Wes George >>>> >>>> This E-mail and any of its attachments may contain Time Warner Cable >>>> proprietary information, which is privileged, confidential, or subject to >>>> copyright belonging to Time Warner Cable. This E-mail is intended solely >>>> for the use of the individual or entity to which it is addressed. If you >>>> are not the intended recipient of this E-mail, you are hereby notified >>>> that any dissemination, distribution, copying, or action taken in relation >>>> to the contents of and attachments to this E-mail is strictly prohibited >>>> and may be unlawful. If you have received this E-mail in error, please >>>> notify the sender immediately and permanently delete the original and any >>>> copy of this E-mail and any printout. >>> >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
