Re: Issue with 208.192.0.0/8 - 208.196.93.0/24?
On Tue, Mar 11, 2003 at 01:50:01PM +, [EMAIL PROTECTED] said: Remember: The majority of the posters here probably have roughly as much (but not as much) of an ego as you, yet a _lot_ more experience and skills to back it up. I think the results are Altho sometime I have to wonder especially with some of the recent posts. Perhaps clueful folk should sneak off and form nanog-clueful mailing list ;) Please don't; there are many of us lurking who are learning a great deal from listening in on the conversations of the clueful. -- Scott Francis || darkuncle (at) darkuncle (dot) net illum oportet crescere me autem minui pgp0.pgp Description: PGP signature
OpenSSL
More OpenSSL (and SSH) fun. http://lists.netsys.com/pipermail/full-disclosure/2003-March/004524.html AND http://lists.netsys.com/pipermail/full-disclosure/2003-March/004529.html
Re: APNIC returning 223/8 to IANA
In a message written on Mon, Mar 17, 2003 at 01:31:08AM -0500, Jared Mauch wrote: When you get a /8, you expect it to be fully usable. The APNIC posture here seems to make sense to me that its an issue that needs to be resolved. using one of the other currently reserved /8's while that issue plays out seems quite logical to me. Just like the people who get 69/8 blocks should expect them to be fully usable as well, right? Surely if one reserved /24 means you can return space and get new space assigned then the inability to reach some percentage of the internet is an even bigger, and more immediate concern that should warrant the same treatment. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: APNIC returning 223/8 to IANA
On Mon, 17 Mar 2003, Leo Bicknell wrote: Just like the people who get 69/8 blocks should expect them to be fully usable as well, right? Surely if one reserved /24 means you can return space and get new space assigned then the inability to reach some percentage of the internet is an even bigger, and more immediate concern that should warrant the same treatment. I think all that really needs to happen here is an RFC update that unreserves 223.255.255.0/24. RFC3330 already mentioned that the basis for this reservation was no longer applicable. Someone at IANA just screwed up the order of events, as the block should have been explicitly unreserved before it was assigned. On the same note, if you do a few google/groups.google.com searches, you'll find that LOTS of people treat the networks marked as IANA-Reserved in http://www.iana.org/assignments/ipv4-address-space in much the same way as RFC1918 space, some even call them quasi-RFC1918 space. A groups.google.com search for 69.0.0.0/8 will turn up 5 pages of hits, nearly all of which are firewall/ipf/ipchains/etc. config examples recommending and demonstrating how to block, among other reserved nets, 69.0.0.0/8. I'd like to strongly encourage IANA to reexamine all current IANA-Reserved blocks, decide which ones will remain Reserved for the forseeable future, and which are likely candidates for assignment to RIRs at any future date, and update these to a more suggestive status such as Future-RIR-Assignment. Otherwise, we're going to repeat the 69/8 exercise (signifigant parts of the net ignoring the space months after assignment...some parts ignoring it likely for years) every time a net goes from being IANA-Reserved to assigned to some RIR. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: APNIC returning 223/8 to IANA
On Mon, 17 Mar 2003, Leo Bicknell wrote: Just like the people who get 69/8 blocks should expect them to be fully usable as well, right? I think all that really needs to happen here is an RFC update that unreserves 223.255.255.0/24. RFC3330 already mentioned that the basis for this reservation was no longer applicable. Someone at IANA just screwed up the order of events, as the block should have been explicitly unreserved before it was assigned. ... Its not quite that simple folks. The reason this particular block is reserved has some real technical merit, while the 69/8 muddle is strictly due to ISP negligence. RFC 3330 got it wrong. Anyone remember the Martian List from the 1970-1990's? Trying to use the all-ones or all-zeros network for real traffic is not possible. Pre CIDR it was not possible to use 192.0.0.0/24 or 192.0.255.0/24. (the same was true on -every- network boundary) With CIDR, those boundaries moved to 1.0.0.0/24 and 223.255.255.0/24 e.g. only two reservered blocks instead of hundreds. Simply having someonechange a DB entry or create an RFC will not affect the installed silicon base. Won't work. APNIC is on the moral highground here. They received damaged goods without notification. IANA needs better technical clue. --bill
Re: APNIC returning 223/8 to IANA
In a message written on Mon, Mar 17, 2003 at 07:01:32AM -0800, [EMAIL PROTECTED] wrote: Simply having someonechange a DB entry or create an RFC will not affect the installed silicon base. Won't work. APNIC is on the moral highground here. They received damaged goods without notification. IANA needs better technical clue. s/silicon/filter/ s/APNIC/Joe ISP/ s/IANA/ARIN/ Note, I don't think either case represents damaged goods, so I'm not supportive of either effort. That said, look at the fixes: Case 1: IANA properly updates RFC's to indiate that 223.255.255.0/24 is not allocatable, and makes APNIC's allocation properly 223/8 minus 223.255.255.0/24. Case 2: ISP's all across the US must handle user complaints, probe, test and then e-mail, call, and plead with hundreds, or even thousands of people to fix their broken filters I don't see any case where an ISP was in danger of receiving IP's that didn't work from 223/8, unless of course APNIC was actually thinking about giving out 223.255.255.0/24. That said, it can be demonstrated that the IP's given out in in 69/8 don't work for a measurable percentage of the Internet. My only claim is that if one questionable /24 our of a /8 means the entire /8 can be returned then clearly someone who receives a block out of 69/8 should be able to return their space as well because their entire block is impared. APNIC has a legitimate complaint, and it needs to be solved. That said it's a very minor complaint, and returning the allocation is simply grandstanding on their part, and is going to give fuel to all the people in other blocks who have what are generally much more serious operational problems. Maybe it would be better for APNIC to give up 223/8 for 70/8, since I suspect 70/8 will have the same filtering problems as 69/8. If they want to make life worse for their users, more power to them. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: OpenSSL
On Mon, Mar 17, 2003 at 04:39:31AM -0500, [EMAIL PROTECTED] said: More OpenSSL (and SSH) fun. http://lists.netsys.com/pipermail/full-disclosure/2003-March/004524.html AND http://lists.netsys.com/pipermail/full-disclosure/2003-March/004529.html Fun is about all it comes to. See what Schneier had to say in the most recent crypto-gram regarding this hole. http://www.counterpane.com/crypto-gram-0303.html -- Scott Francis || darkuncle (at) darkuncle (dot) net illum oportet crescere me autem minui pgp0.pgp Description: PGP signature
Re: OpenSSL
In message [EMAIL PROTECTED], Scott Francis writes: Fun is about all it comes to. See what Schneier had to say in the most recent crypto-gram regarding this hole. http://www.counterpane.com/crypto-gram-0303.html This is a new attack, not the one Schneier was talking about. It's very elegant work -- they actually implemented an attack that can recover the long-term private key. The only caveat is that their attack currently works on LANs, not WANs, because they need more precise timing than is generally feasible over the Internet. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book)
RE: APNIC returning 223/8 to IANA
-Original Message- On Mon, 17 Mar 2003, [EMAIL PROTECTED] wrote: I'd like to strongly encourage IANA to reexamine all current IANA-Reserved blocks, decide which ones will remain Reserved for the forseeable future, and which are likely candidates for assignment to RIRs at any future date, and update these to a more suggestive status such as Future-RIR-Assignment. Otherwise, we're going to repeat the 69/8 exercise (signifigant parts of the net ignoring the space months after assignment...some parts ignoring it likely for years) every time a net goes from being IANA-Reserved to assigned to some RIR. That's probably a good idea from a practical standpoint. It's just hard to swallow the idea of IANA having to make policy a certain way just to accomodate the operators who aren't paying attention. Sorry for prolonging an endless debate.
Nortel SHASTA
Greetings. Is there anyone out there in the NANOG community who uses the Nortel SHASTA box for aggregation that would like to technically chat offline? Regards, Gerard White Aliant
Re: Nortel SHASTA
Is there anyone out there in the NANOG community who uses the Nortel SHASTA box for aggregation that would like to technically chat offline? Didn´t nortel more or less kill or suffocate the product quite quickly after the aquiring the company? (as they did Promatory) Pete
Re: OpenSSL
Steve Bellovin wrote: The only caveat is that their attack currently works on LANs, not WANs, because they need more precise timing than is generally feasible over the Internet. On the other hand, many of the SSL servers on the web are located in hosting centers, which are LAN-connected to potential attackers who can get accounts on machines in the same hosting centers. The attackers' and targets' servers tend to have routers in front of them, as well as the switches provided by the hosting center, but it's still much more precise than the open net.
RE: Nortel SHASTA
I use this product. I think they still sell this product especially in dsl enviroments. Good for the pptp and ppoe stuff. Alan You can contact me directly at [EMAIL PROTECTED] -Original Message- From: Petri Helenius [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 11:01 AM To: [EMAIL PROTECTED]; Gerard White Subject: Re: Nortel SHASTA Is there anyone out there in the NANOG community who uses the Nortel SHASTA box for aggregation that would like to technically chat offline? Didn´t nortel more or less kill or suffocate the product quite quickly after the aquiring the company? (as they did Promatory) Pete
FW: Controlling outbound traffic in a multihomed BGP environment
How can you control outbound traffic from a single subnet - meaning forcing all its outbound traffic out a single bgp edge router in a multihomed environment. Here is the scenario: 1. Inbound traffic is engineered using prepends - meaning to force inbound traffic through a particular router, we are using prepends to make one path seem better than the other on the outside. 2. Local preferences are set to control general outbound traffic to specific ISPs - those that are one or two hops away. 3. Now, I have a customer whose traffic I'll prefer to force out a single bgp edge router - all his traffic, no specific ones. The IGP is OSPF, and there are several different distribution routers between the access IGP router and the core/edge bgp routers.
RE: Controlling outbound traffic in a multihomed BGP environment
Routing based on source address is called Policy Routing. IF you are on a cisco box, create an extended access-list specifying the source Ip's, and then match that access list in a route map to set the next hop. Apply the route map on ports facing that customer, building a chain from edge (facing the customer) to border (facing the internet. Good Luck, Ejay -Original Message- From: Daniel Abbey [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 10:20 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: FW: Controlling outbound traffic in a multihomed BGP environment How can you control outbound traffic from a single subnet - meaning forcing all its outbound traffic out a single bgp edge router in a multihomed environment. Here is the scenario: 1. Inbound traffic is engineered using prepends - meaning to force inbound traffic through a particular router, we are using prepends to make one path seem better than the other on the outside. 2. Local preferences are set to control general outbound traffic to specific ISPs - those that are one or two hops away. 3. Now, I have a customer whose traffic I'll prefer to force out a single bgp edge router - all his traffic, no specific ones. The IGP is OSPF, and there are several different distribution routers between the access IGP router and the core/edge bgp routers.
Re: OpenSSL
On Mon, Mar 17, 2003 at 12:55:24PM -0500, [EMAIL PROTECTED] said: In message [EMAIL PROTECTED], Scott Francis writes: Fun is about all it comes to. See what Schneier had to say in the most recent crypto-gram regarding this hole. http://www.counterpane.com/crypto-gram-0303.html This is a new attack, not the one Schneier was talking about. It's very elegant work -- they actually implemented an attack that can recover the long-term private key. The only caveat is that their attack currently works on LANs, not WANs, because they need more precise timing than is generally feasible over the Internet. Hm, mea culpa. I read the title without digging very far into the actual announcements and thought it a rehash of the earlier holes. Thanks for clearing it up for me. -- Scott Francis || darkuncle (at) darkuncle (dot) net illum oportet crescere me autem minui pgp0.pgp Description: PGP signature
of marginal oper. interest [bgp reflecting actual traffic flow (or not)]
sent to e2e hoping thread pursued on only one mailing list but wasn't sure which one would hate it more. fwiw. critical feedback/corrections/thoughts welcome k - Forwarded message from k claffy [EMAIL PROTECTED] - Date: Mon, 17 Mar 2003 21:26:30 -0800 From: k claffy [EMAIL PROTECTED] Subject: bgp reflecting actual traffic flow (or not) To: [EMAIL PROTECTED] Cc: Rajesh Talpade [EMAIL PROTECTED] 8 months may be my record for email latency impressive huh On Tue, Jul 02, 2002 at 09:27:50PM -0400, Rajesh Talpade wrote: kc wrote: would recommend against assumptions of either symmetric paths or bgp reflecting actual traffic flow unless you're writing science fiction always wondered about what new career i could launch into! :-) seriously, what's a good reference for your second point about bgp not reflecting actual traffic flow? preliminary tech report finally up, have not wanted to publish till we had more complete results but that might not be in community's best interest so here: http://www.caida.org/outreach/papers/2003/ASP/ (also linked from 'what's new' on caida.org) remark reckon it's not going to surprise any operators, and it's still only a piece of the interdomain alchemistry, but there we bgp k - End forwarded message -
