- NANOG - lists.nanog.org

Re: Global BGP - 2001-06-23 - Vendor X's statement...
by rs＠seastrom.com 26 Jun '01

26 Jun '01

Sean Donelan <sean(a)donelan.com> writes: > Sigh, the motto "be liberal in what you accept and conservative in what > you send" applies to BOTH parties. Making guesses as to what is meant when one gets malformed routing updates is well beyond the scope of being "liberal in what you accept". It is only noteworthy that the bad update didn't crash the Brand "C" router because it used to be notoriously easy to kick one over by that method. > The failure of one party not to > liberally accept what is received does not excuse the sending party from > being conservative in what they send. And vice-versa. Being "conservative in what you send" refers to interpretations of the specification, backwards compatability with older specifications, requiring weird extensions to the protocol, etc. These all fall along the axis of "what might be expected in a properly functioning implementation". Output that is clearly wrong, as is the case here, is not just breaking conservatism in what one sends, it's a sign that Something is Screwed Up (tm). A convincing argument can be made for a "max-malformed-update-resets" knob such that if the peer sends bogons and gets reset more than N times in T minutes, the session is admin-downed the same way it is when it exceeds max-prefixes. Of course, if more router manufacturers were to enable clairvoyant route update divination (CRUD), Sean would get more interesting outages to write about, so at least _someone_ is ahead. :) ---Rob

1 0

Re: Cable Modem [really responsible engineering]
by Fletcher E Kittredge 26 Jun '01

26 Jun '01

On Mon, 25 Jun 2001 18:27:50 -0700 Ted Lemon wrote: > > I think we are in violent agreement. I don't like the > > IP->MAC->Customer mapping, it is forgeable, but it is the only one I > > know we have available. I agree with you that it is not the only > > possible mapping. If you can point me to a better existing mechanism, > > I would be greatful. > > If you are a cable modem or DSL provider, you may be able to use the > relay agent information option to get a unique ID from the cable > modem. This should uniquely identify the customer, and has the > virtue that you may have sold the customer the box, and thus may > already know its ID. Cable modem and DSL systems that support this > functionality can apparently be set up so that it's quite difficult to > spoof the modem identification. Ted; That works for the cable/dsl/wireless modem. As always, there are some unstated assumptions that come with the particular engineering sub-niche. The unstated assumption here is that the problem is not the modems, but the devices beyond the modem, the devices that the customer actually uses: PCs, routers, ip-aware toasters, web cams, etc. These are the devices that tend to cause the most problems. They have an enormous range of different manufacturers. Customers, those pesky folk, tend to add/modify/delete them constantly. Also, if the cable/dsl/wireless modem is a router, life becomes much simpler as one can just gather the necessary information via tracing. However, I am not sure requiring modems to be routers is a good thing... Let me stress in passing, it is very important that public (non-RFC 1918) IPv4 addresses not be wasted on cable/wireless/dsl modems. There is no reason for these modems to be reachable from the outside world (in an IPoE environment) and reachability is actually dangerous. If you waste public IP addresses on these devices, eventually ARIN will step on your head. > Now, in this case and also in the case of tracking the customer's MAC > address, you are still really tracking access at a customer premise > level, not at a user level, and so this couldn't be used as a reliable > way of identifying an individual user, but it *could* be used as a way > of figuring out who to contact to get more information. Exactly. It isn't an optimal solution. However, Caller-Id and username/password have the same drawbacks. In fact, I once was an expert witness on the question of whether username/password was sufficient proof beyond a reasonable doubt. regards, fletcher

2 1

RE: Global BGP - 2001-06-23 - Vendor X's statement...
by Sean Donelan 26 Jun '01

26 Jun '01

On Tue, 26 June 2001, "Chance Whaley" wrote: > Vendor X released a limited statement to their customers describing the > issue - and their view on it. The large incumbent vendor that we all > know and love has confirmed the issue, and released a "patch" to some of > their customers. Vendor X also went on to state that at no time did > their boxes crash, mis-forward, reset, or have any issue resulting from > the events of the past weekend. Sigh, the motto "be liberal in what you accept and conservative in what you send" applies to BOTH parties. The failure of one party not to liberally accept what is received does not excuse the sending party from being conservative in what they send. And vice-versa. Just because one vendor has issued a patch does not excuse the other vendor.

3 2

RE: Global BGP - 2001-06-23 - Vendor X's statement...
by Richard A. Steenbergen 26 Jun '01

26 Jun '01

On Tue, Jun 26, 2001 at 11:01:58AM -0700, Sean Donelan wrote: > > On Tue, 26 June 2001, "Chance Whaley" wrote: > > Vendor X released a limited statement to their customers describing the > > issue - and their view on it. The large incumbent vendor that we all > > know and love has confirmed the issue, and released a "patch" to some of > > their customers. Vendor X also went on to state that at no time did > > their boxes crash, mis-forward, reset, or have any issue resulting from > > the events of the past weekend. > > Sigh, the motto "be liberal in what you accept and conservative in what > you send" applies to BOTH parties. The failure of one party not to > liberally accept what is received does not excuse the sending party from > being conservative in what they send. And vice-versa. > > Just because one vendor has issued a patch does not excuse the other > vendor. But in situations where there cannot be a mismatch between two parties' definition of "liberal", that is why we have standards. I'd say it is entirely the fault of the vendor who was TOO liberal in what they accepted, because they continued to propogate the bad information over the entire internet instead of stopping it where it began as the protocol intended. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: peering requirements (Re: DDOS anecdotes)
by Paul Vixie 26 Jun '01

26 Jun '01

Following up on my own post: vixie(a)mfnx.net (Paul Vixie) writes: > Recommendation: upgrade your peering requirements to include language like: > ... Several folks here talked about technical implementation aspects (RPF, etc) and a few told me privately that peering was a sales/marketing activity at this stage of the game. This either means that upgrading the general level of peering agreement is not possible, or that the people I should be discussing it with don't read NANOG. This echos what I learnt at Stephen's BOF in Phoenix.

3 2

Re: Cable Modem [really more about PPPoE]
by Daniel Senie 26 Jun '01

26 Jun '01

At 12:21 PM 6/26/01, Steve Schaefer wrote: >On Tue, 26 Jun 2001, Fletcher E Kittredge wrote: > > > > > On Tue, 26 Jun 2001 10:28:16 -0400 (EDT) Chris White wrote: > > > DHCP alone is not a viable option in this model. How do you get the end > > > user traffic to the ISP and back in a pure IP environment? Policy > routing, > > > GRE, MPLS, force your ISP customer to interconnect at every location, > > > etc.? > > > > Hello Chris; > > > > You provide frustrating few details and a statement "DHCP alone is not > > a viable option in this model." Could you restate more concretely > > what is your design problem which can only be solved by > > ATM/MPLS/PPPoE? I hesitate to answer for fear that there is some > > constraint I don't know about. > >The constraint is that outbound packets need to go to the right ISP. That >is, the packets need to go through the carrier network according to the >business relationship, not according to the destination IP address. This isn't necessarily the case. Take a look at rent-a-POP dialups. UUNet sells services to LOTS of ISPs from all of its POPs. The RADIUS authentication has to get to the proper ISP, but the traffic certainly does NOT travel to the ISP's network before going out into the world. Traceroutes from your dialup account will show that the traffic goes directly. UUNet charges the ISP a fee for the use of the dialup, and UUNet provides a relaying of the RADIUS traffic to the right ISP, and provides transport for the end user's packets. The same scenario COULD be used in DSL or cable setups. That's not to say that it will be. >Some method of identifying the ISP associated with each outbound packet is >necessary. Policy routing, tunnels and PVC's are a few methods. VLAN >tagging works, too. Right. Assuming the business model where the ISP actually handles the traffic. ----------------------------------------------------------------- Daniel Senie dts(a)senie.com Amaranth Networks Inc. http://www.amaranth.com

3 2

Re: SBC Contract Post (fwd)
by owen＠dixon.delong.sj.ca.us 26 Jun '01

26 Jun '01

And, of course, we all know how well BOCs (Bell Operating Companies) and other incumbent LECs (Local Exchange Carriers) follow such rules. The problem is that most of these safeguards are not really enforceable, and the telecom providers violate them at will. Heck, look at how easily Pac Bell was able to drive MCI out of the local telco business in California by dragging their feet on service/install requests, making repeated mistakes in the process, etc. (Yes, Pac Bell makes mistakes with their own customers as well, but these were mistakes that looked suspicious, even compared to Pac Bell's usual level of incompetence). SBC is one of the scariest, slimiest, sleaziest organiziations I've ever run up against. They truly fit the definition of Telco someone posted a while back (A law firm with a side business in telecommunications). They have certainly violated most, if not all, of the safeguards mentioned below, and their new contract certainly violates the spirit, if not the letter, of said same safeguards. Owen > Robert Cannon of cybertelecom.org asked I submit > this re: the SBC Contract thread.... > > ---------------- > > In proceedings going back to 1966 known as the Computer Inquiries, > the FCC established a series of safeguard rules that create ISP > rights to telecommunications. The Computer Inquiries first divided > the world into Enhanced Service Providers (aka computer networks, > ISPs, information service providers) and basic telecom. Enhanced > service providers are unregulated by the FCC. But acknowledging > the dependency of ESPs on the underlying telecom monopoly (remember > this is 1970s and 1980s), the FCC created a series of safeguards. > > The safeguards require all facilities based telecom carriers who > offer ISPs services to unbundle the services and offer them to > independent ISPs on the same terms and conditions. BOCs have added > requirements; they can elect to have an ISP through a separate > subsidiary (Computer II) or they can have an integrated ISP if they > file a comparably efficient interconnection plan (Computer III). > BOCs, regardless of whether they have an ISP, were also required > to create Open Network Architecture plans, breaking their networks > down to basic building blocks for the benefit of ISPs. > > Additional safeguards that generally fall on all carriers include > prohibitions against discrimination, requirements that line > provisioning be completed in the same time frame, cost accounting > rules, prohibitions against cross subsidization, requirements > for network information disclosure, and restrictions on the use > of customer information. > > I have created a white paper entitled "Where ISPs and Telephone > Companies Compete: A Guide to the Computer Inquiries, Enhanced > Service Providers and Information Service Providers." It is > available at http://www.cybertelecom.org/ci/ciii.htm#guide It > explains these rules as they exist today. > > -B > __________________________________________________ > > > -- > A host is a host from coast to coast.................wb8foz(a)nrk.com > & no one will talk to a host that's close........[v].(301) 56-LINUX > Unless the host (that isn't close).........................pob 1433 > is busy, hung or dead....................................20915-1433 >

2 1

SBC Contract Post (fwd)
by David Lesher 26 Jun '01

26 Jun '01

Robert Cannon of cybertelecom.org asked I submit this re: the SBC Contract thread.... ---------------- In proceedings going back to 1966 known as the Computer Inquiries, the FCC established a series of safeguard rules that create ISP rights to telecommunications. The Computer Inquiries first divided the world into Enhanced Service Providers (aka computer networks, ISPs, information service providers) and basic telecom. Enhanced service providers are unregulated by the FCC. But acknowledging the dependency of ESPs on the underlying telecom monopoly (remember this is 1970s and 1980s), the FCC created a series of safeguards. The safeguards require all facilities based telecom carriers who offer ISPs services to unbundle the services and offer them to independent ISPs on the same terms and conditions. BOCs have added requirements; they can elect to have an ISP through a separate subsidiary (Computer II) or they can have an integrated ISP if they file a comparably efficient interconnection plan (Computer III). BOCs, regardless of whether they have an ISP, were also required to create Open Network Architecture plans, breaking their networks down to basic building blocks for the benefit of ISPs. Additional safeguards that generally fall on all carriers include prohibitions against discrimination, requirements that line provisioning be completed in the same time frame, cost accounting rules, prohibitions against cross subsidization, requirements for network information disclosure, and restrictions on the use of customer information. I have created a white paper entitled "Where ISPs and Telephone Companies Compete: A Guide to the Computer Inquiries, Enhanced Service Providers and Information Service Providers." It is available at http://www.cybertelecom.org/ci/ciii.htm#guide It explains these rules as they exist today. -B __________________________________________________ -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

straw poll for multi-homed operators
by Joe Abley 26 Jun '01

26 Jun '01

[number 5 in a series of unscientific surveys] If you currently multi-home between two or more providers using IPv4: + why do you do it? What are the high-level goals you are hoping to achieve? Are you finding that you are achieving them? + how often does your traffic shift between transit providers due to a failure of some kind triggering a re-homing? + how often do you manually shift traffic, and why? Just inbound traffic? Or outbound too? + what impact does a manual or automatic shift in traffic between providers have to your users? Do their TCP sessions break? Or do you think they normally stay alive, maybe after a delay? What makes you think this? + what is *bad* about the way that multi-homing works in IPv4? + what is good about it? Context is an attempt to nail down some requirements for a multi-homing architecture in IPv6 (one that doesn't incorporate exciting up-and-to-the- right state explosion in the DFZ). I can summarise private replies if there is interest. http://www.ietf.org/html.charters/multi6-charter.html http://www.automagic.org/~jabley/draft-ietf-multi6-multihoming-requirements… http://www.automagic.org/~jabley/draft-ietf-multi6-v4-multihoming-00.txt Joe

1 0

History of 24/8 (was RE: for folks tracking DDOS sources or reading the GRC attack log)
by David R. Conrad 26 Jun '01

26 Jun '01

[Long, boring, and not much operational content. You are warned] A bit of biased history: Long ago, in an Internet very different than today's, Jon Postel was convinced by people with more than a little knowledge about such things that this "IP over Cable TV infrastructure" idea might actually take off. In fact, he was convinced that it was going to work so well that all the Cable TV providers all over the world were going to besiege the IANA like a biblical swarm of locusts and Jon would spend all his time fending off requests for huge blocks of addresses. My understanding of why things went to the IANA was that @Home was rejected for a large block of address space and they appealed to the IANA (as was the policy in those days). After much discussion, multiple requests for more information, proof, first-borns, etc., Jon agreed that the IP over CATV infrastructure model of operation was sufficiently different that it justified special treatment (the argument being, to my understanding, that IP over CATV provided something new at the time: always on end user service). The convincer (I'm told) suggested that the Cable TV industry was going to form a trade association that would handle industry coordination requirements like, oh say, allocation of IP addresses. Jon decided to allocate 24/8 to this (at that time not-yet-existant organization) with the understanding that all IP over CATV infrastructure address requirements were to be managed by this new trade association once it was formed. Until it was formed, the IANA would authorize ARIN (InterNIC at the time, I believe) to allocate address space out of the 24/8 block. Of course, history has shown that no such organization was formed (if you assume AT&T is not that organization). Anyhow, when APNIC, InterNIC, and RIPE-NCC found out about all this, we all expressed significant unhappiness as we didn't think there was any significant difference between a IP over CATV provider and any other ISP. However, what was done was done and it would've been a bit difficult to get @Home to return the block since they'd already allocated a bunch of customers to it. APNIC gave IP over CATV ISPs the option of allocating out of normal APNIC space or forwarding their request to the IANA. I think one request was forwarded to the IANA for an IP over CATV provider (but my memory is hazy). Not sure if RIPE-NCC forwarded any requests. After a while, I saw 24/8 as just another InterNIC/ARIN block, albeit one with a weird genealogy. At the time, 24/8 was pretty controversial. Many of the loons whinged and moaned about the unfairness of it all, making all sorts of bogus claims like @Home got the entirety of 24/8, that Jon was biased about the allocation since he worked with many of the @Home principals, etc. But then again, the loons whinge and moan about pretty much anything. Controversy flared up over this more recently when ICANN used 24/8 as an example of RIR-independent address space that would justify ICANN doing allocations of address space themselves. Suffice it to say that this was a poor example. Now, isn't that more than you ever wanted to know? Rgds, -drc (who played a small role at APNIC in a previous life) At 02:24 PM 6/26/2001 +1000, Bruce Campbell wrote: >On Mon, 25 Jun 2001, Richard A. Steenbergen wrote: > > > On Mon, Jun 25, 2001 at 04:54:12PM -0700, Mike Batchelor wrote: > > > > > > > 24.0/8 is the "cable block". > > > > > > No it's not. Check out 24.132/14 for instance. > >and 24.192/14 > > > IANA and ARIN seem to think it is... Check out: > > http://www.iana.org/assignments/network-24 > >24/8 has been used by all 3 RIRs to make assignments to cable modems in >times past. > >Recent events have lead to the non-ARIN parts of 24/8 being taken up by >ARIN, in addition to the non-allocated-to-a-RIR parts of 24/8. Updates to >various databases will simply take a bit of time, thats all. > >--==-- >Bruce.

1 0