Re: Privacy, Integrity, Security mailing-list invitation
I suppose the inevitable question would be: Is this the appropriate venue for discussions surrounding the efforts to create a Do Not Track (mumble)? - ferg On Thu, Mar 17, 2011 at 1:06 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi Dean, since you asked: 1) What is different about this exercise from the ongoing privacy discussion on priv...@iab.org/ietf-priv...@ietf.org? A) priv...@iab.org The priv...@iab.org was a mailing list created for the IAB privacy workshop: http://www.iab.org/about/workshops/privacy/ It was used by the workshop organizers only. It will be deleted soon. B) ietf-priv...@ietf.org This mailing list has been set up to discuss issues related to privacy that cut across multiple groups and areas. The initial goal of this discussion is to investigate privacy and related identity management terminology. A secondary goal is to explore the opportunity to develop Privacy Consideration guidelines similar to the Guidelines for Writing RFC Text on Security Considerations [RFC3552] used in the security area. To subscribe go to: https://www.ietf.org/mailman/listinfo/ietf-privacy C) privacy...@ietf.org There is a privacy directorate created as a result of last year's privacy workshop. Membership (like the security area directorate): per-invitation only. Ciao Hannes PS: It would be nice to get review comments on the privacy terminology, the privacy considerations, and policy considerations document: http://tools.ietf.org/html/draft-hansen-privacy-terminology-02 http://tools.ietf.org/html/draft-morris-privacy-considerations-02 http://tools.ietf.org/html/draft-morris-policy-cons-00 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Is this true?
On Sun, Aug 29, 2010 at 12:22 AM, Fernando Gont ferna...@gont.com.ar wrote: Agreed. I just meant that even without v6 NATs, it shouldn't come as a surprise if end-to-end connectivity is *not* restored by IPv6. It is refreshing to hear someone actually say that out loud. Thank you. - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: T-shirts?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Mar 29, 2010 at 11:55 PM, Fred Baker f...@cisco.com wrote: personally, I think that should be in the weave, not the print... On Mar 27, 2010, at 8:21 AM, Christian Huitema wrote: Can we make sure that the shirts are ASCII only? http://www.ipinc.net/IPv4.GIF Hmmm... movie alert: http://www.imdb.com/title/tt0493464/ List of assassination targets coded in a weave.. from a mystical loom. Yes, I know... :-) - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLsaLTq1pz9mNUZTMRApJLAKCT71P8F9CdhTMUqO3P7C46rPa/DgCg/i5O fOveXtEs3+Lcffm9J9XPPAQ= =KqV+ -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NATs *ARE* evil!
I find it amazing (well, probably not so amazing) that we are re-hashing this every few years. It looks like NAT's are a fact of life, and we just need to figure out how to deal with them. - paul At 07:59 PM 12/15/2000 -0500, Scott Bradner wrote: I will admit to some level of confusion the subject line of this thread is "NATs *ARE* evil!" yet most of the discussion is about the use of private addresses - something that a whole lot of firewalls also do - howcum the subject line is not "NATs Firewalls are evil!" or "use of private addresses is evil!"? this focus on NATs seems to be an incomplete statement of the problem
Re: RFCs in print
At 06:29 PM 06/09/2000 -0700, Jeffrey Mogul wrote: Other people have raised the issue of equity. I've always believed that RFCs should be freely copyable, with no royalty or permission requirements, [...] Ditto. As an author, I agree. And as far as I'm concerned, RFC's are already "published". - paul
Re: draft-ietf-nat-protocol-complications-02.txt
At 08:27 PM 04/24/2000 -0400, Andrew Partan wrote: Or seperate the end system identifer from the routing goop. This solves lots of problems (while introducing others). Deja Vu. - paul
RE: Re[2]: Re: Critically compare the congestion control on TCP/
At 11:16 AM 03/09/2000 -0600, Schipper, Dell wrote: I recall that Larry Roberts a few years ago gave presentations (at NetWorld+InterOp ?) that compared the congestion avoidance algorithms of ATM-ABR service to TCP/IP. I know he has started a new company since then and I do not have any contact information. One of my favorites along those lines was: "End-to-End Traffic Management Issues in IP/ATM Internetworks," draft-jagan-e2e-traf-mgmt-00.txt, S. Jagannath and N. Yin, August 1997. - paul [snip] Abstract This document addresses the end-to-end traffic management issues in IP/ATM internetworks. In the internetwork environment, the ATM control mechanisms (e.g., Available Bit Rate (ABR) and UBR with Early Packet Discard (EPD)) are applicable to the ATM subnetwork, while the TCP flow control extends from end to end. We investigated the end to end performance in terms of TCP throughput and file transfer delay in cases using ABR and UBR in the ATM subnetwork. In this document, we also discuss the issue of trade-off between the buffer requirements at the ATM edge device (e.g., Ethernet-ATM switch, ATM router interface) versus ATM switches inside the ATM network. Our simulation results show that in certain scenarios (e.g., with limited edge device buffer memory) UBR with EPD may perform comparably to ABR or even outperform ABR. We show that it is not sufficient to have a lossless ATM subnetwork from the end-to-end performance point of view. The results illustrate the necessity for an edge device congestion handling mechanism that can couple the ABR and TCP feedback control loops. We present an algorithm that makes use of the ABR feedback information and edge device congestion state to make packet dropping decisions at the edge of the ATM network. Using the algorithm at the edge device, the end-to-end performance in throughput and delay are improved while using ABR as the ATM subnetwork technology and with small buffers in the edge device. [snip]
Re: Internet SYN Flooding, spoofing attacks
At 11:15 AM 02/15/2000 +, Lloyd Wood wrote: A lot of surveillance can be based on 'if A is talking to B, then A must be as guilty as B', and message content is irrelevant. This helps counters that. Well, get over it. ;-) (Smiley included for the humor impaired.) - paul
Re: Internet SYN Flooding, spoofing attacks
At 03:41 PM 02/14/2000 -0800, Charles E. Perkins wrote: Mobile IP would like to send out packets with the mobile node's home address, while it is attached to a network in a foreign domain. The home address is likely to look "incorrect" from the standpoint of such a filter. If I'm not mistaken (although my coauthor has tracked the mobile ip cruft more than have I), there is some notion of a tunneling mechanism from the first-hop mobile ip gateway, such that the bogon source is really never seen in that fashion (as a bogon). Again, I admit complete ignorance of mobile ip cruft. Plus I don't think the gain is worth the pain. I'd rather see a technology that actually solves the problem instead of swatting at gnats with a sledge hammer. Well, right now, you get swatted. Figure out a better way, and you'll stop getting swatted. - paul
Re: Internet SYN Flooding, spoofing attacks
At 02:40 PM 02/11/2000 -0500, Bernie Volz wrote: Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs required to put filtering on their networks that PREVENTS packets with invalid source addresses ever entering their infrastructure? Because there is no "Internet Police", that's why. If every site connected to the Internet did this, spoofing would be much more difficult because you couldn't do it. Sure, you could spoof an address from YOUR network, but that's all. And guess what, it would be much easier to track and thus to shut down the intrusions should they occur. Yes, this practice is documented in RFC2267. Thus ever edge router should have filter lists that prevent it forwarding traffic out to the Internet (ISPs network) any packet that does not have a source address that is valid from that site. I would hope that lots of ISPs already do this. But, perhaps not. I would hope so, too, but apparently many do not. Thus, the problem at hand. - paul - Bernie Volz Process Software
Re: Internet SYN Flooding, spoofing attacks
At 11:57 AM 02/11/2000 -0800, Randy Bush wrote: Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs required to put filtering on their networks that PREVENTS packets with invalid source addresses ever entering their infrastructure? maybe you want to be reading the nanog mailing list, [EMAIL PROTECTED], where the problems with and tactics for this and other approaches are discussed. Let's point folks to: http://www.nanog.org/mailinglist.html instead. The last thing I want to see on the NANOG list is a bunch of "subscribe me" messages. - paul
[fwd] Lawyers Forsee Denial Of Service Suits
It has begun. Sigh. FYI, - paul http://www.techweb.com/wire/story/TWB2211S0014
Re: Internet SYN Flooding, spoofing attacks
Vijay, We (at least cisco, anyways) already have a knob for this: [no] ip verify unicast reverse-path We call it Unicast RPF. See also: Craig Huegen's very useful web page on minimizing the effects of DoS attacks: http://users.quadrunner.com/chuegen/smurf.cgi Cisco: Distributed Denial of Service (DDoS) News Flash, February 9, 2000 http://www.cisco.com/warp/public/707/newsflash.html Dave Dittrich's (University of Washington) very good analysis of the recent DDoS attack tools. http://www.washington.edu/People/dad/ NIPC (National Infrstructure Protection Center), TRINOO/Tribal Flood Net/tfn2k stuff: http://www.fbi.gov/nipc/trinoo.htm "Handling A Distributed Denial of Service Trojan Infection: Step-by-Step." http://www.sans.org/y2k/DDoS.htm CERT (Computer Emergency Response Team at CMU) http://www.cert.org/ Cisco: Internet Security Advisories http://www.cisco.com/warp/public/707/advisory.html Characterizing and Tracing Packet Floods Using Cisco Routers http://www.cisco.com/warp/public/707/22.html Cisco Product Security Incident Response (PSIRT) http://www.cisco.com/warp/public/707/sec_incident_response.shtml "Essential IOS" - Features Every ISP Should Consider http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip Know your enemy: Script Kiddies http://www.enteract.com/~lspitz/enemy.html Cisco Flow Logs and Intrusion Detection at the Ohio State University http://www.usenix.org/publications/login/1999-9/osu.html If anyone else has useful links (it doesn't matter who is the vendor, whatever), please let me know. - paul At 09:01 PM 02/11/2000 -0500, Vijay Gill wrote: CC'd to NANOG, maybe we can move this there. On Fri, 11 Feb 2000, Paul Ferguson wrote: It would allow the attacks to be traced back to the zombies (in the case of these DDoS attacks), and the perpetrators to be traced back and identified. To make that easier, what is needed is something associated with a downstream interface that is a part of the configuration itself, not a separate access-list. This makes it much easier to track on a large box with many hundreds of customer links and so forth. Something like so: interface XXXm/n/p.q description whatever customer encaps ... ip address x y ip allow-source blocks-that-are-valid ip allow-source ...more-blocks- so on and so forth. /vijay
Re: Internet SYN Flooding, spoofing attacks
At 09:14 PM 02/11/2000 -0500, Vijay Gill wrote: This only works on single homed customers. Due to asymmetric routing, the customer can source _valid_ ip addresses from an ip source address that is not routed over that interface. I too would prefer some sort of magic unicast RPF, but the best compromise is the built-in access filter. The solution must be general enough to work for multihomed, defaulting out customers with blocks from n providers, No, that is a common misconception, or rather, an overstatement of a pretty easily described situation. It only breaks things in transit situations, and only in transit situations where you might not have the same forwarding path back to the source as you would via the same interface a packet came in on. This is a small percentage, I would thing, since the percentage of ISP's offering transit pales in comparison to all other "access" ISP's that do not. And in cases where ISP's _do_ offer transit, or have transit agreements, will they really do this on their transit interfaces? I think not. - paul
Re: Internet SYN Flooding, spoofing attacks
At 11:33 PM 02/11/2000 -0500, [EMAIL PROTECTED] wrote: What are the chances of setting up "The Next Release" of IOS so that for simple configs (for example, a customer backbone and one upstream link to a provider) the knob would automagically default to Doing The Right Thing? I of course am writing as a non-expert on the innnards of IOS, and I'm expecting flame-fests regarding "simple config" and "Right Thing". No, it's not a total fix. It won't fix everything. It may not even be possible. But it certainly would be nice. ;) Something like "ip default clueless"? Just kidding. ;-) Well, overwhelming support for any suggested default mod is always considered. Really. Overwhelming is the operative word here. We (as do many other vendors, I would suggest) operate under the "Principle of Least Astonishment": How many people would we screw if we changed the defaults of a particular command? If overwhelming community support were to set the tone for a default change, we would certainly not take it lightly. :-) - paul
RE: IP network address assignments/allocations information?
Hi Tony, Well, the statement below is not true -- I sit behind a NAT/PAT device and Real PLayer works just fine for me. I've only found a couple of applications that will not work for me (e.g. ICQ, NTP, SNMP), but then again, I'm not a gamer so I can't speak to the broader range of applications that it _does_ break. In any event, I've always personally been of the opinion that if applications don't work in the face of NAT, then the applications themselves are functionally deficient and should be fixed. :-) Cheers, - paul At 10:44 AM 11/29/1999 -0800, Tony Hain (Exchange) wrote: 1) Yes ... We have been forced into a world of NAT where simple applications such as Real Player won't work without real-time manual intervention at the NAT.
