Where is the edge of the Internet?

address (as per your scenario). You look up the destination in the routing
table, and don't find it. So we look in RFC792 on page 5:

      If, according to the information in the gateway's routing tables,
      the network specified in the internet destination field of a
      datagram is unreachable, e.g., the distance to the network is
      infinity, the gateway may send a destination unreachable message
      to the internet source host of the datagram. In addition, in some
      networks, the gateway may be able to determine if the internet
      destination host is unreachable. Gateways in these networks may
      send destination unreachable messages to the source host when the
      destination host is unreachable.

-------------> who does? the source is reachable.......via BGP.....its a
valid internet address...

And you send that to the bogus source address *HOW*?

------> how what??...it still isnt a problem for the actual traffic, the
"source" network may exist on a BGP router as being advertised from another
AS ......but not on the edge router from where it uplinks ......as was
being discussed here

Also, note the following:

      Another case is when a datagram must be fragmented to be forwarded
      by a gateway yet the Don't Fragment flag is on. In this case the
      gateway must discard the datagram and may return a destination
      unreachable message.

Getting Path MTU Discovery to work is tough enough without some bozo network
engineer assuming that assymetric paths with unroutable endpoint addresses
will actually work. Yeah, sure - the destination *MIGHT* have a route back,
but if *you* don't have a route back, things will break in subtle ways.

---------------> suggest u read the thread... we were :
1. discussing a ip spoofed attacks
2. the network/ip may exist on a BGP running router as being advertised from
antoher AS/ differnet ISP.. its still present on the internet, .... but its
a BGP route, not an IGP route...although that network uplinks from ur
network...whats the problem? where does all this cause a problem? all ur
edges will 0.0.0.0/0 to some bgp running router and the packet will get
there..
......there are enuf asymmetric networks, i can assure of of that... for
one, you could simply try running a traceroute to some tracert sites from ur
PC and a reverse trace from those servers to you.... ull find lots...

-------------> who does? the source is reachable.......via BGP.....its a
valid internet address...

Hold that thought for a bit, and remember that at least *some* of us were
discussing whether to drop packets if we *DONT* have a route to the source.

......there are enuf asymmetric networks, i can assure of of that... for
one, you could simply try running a traceroute to some tracert sites from ur
PC and a reverse trace from those servers to you.... ull find lots...

And the point is, that even *WITH* an assymetric route, that if I *DONT*
have a route back to you *somehow*, it's probably time for me to toss the
packet out the window. There's a distinction between "the route to the
source goes out an interface other than the one the packet arrived on"
and "there is no route to the source at all, via any interface".

Where is the edge of the Internet?

here's what i came up with while trying to explain "the edge" elsewhere.

   1 - Connection Taxonomy

   1.1. The Internet is a "network of networks", where the component
   networks are called Autonomous Systems (AS), each having a unique AS
   Number (ASN).

   1.2. Connections inside an AS are called "Interior" (or sometimes
   "backbone"), and their security policies are set according to local
   needs, usually based on business or technical requirements.

   1.3. Connections between ASs are called "Border" (or sometimes
   "peering"), and their security policies are set bilaterally according to
   the joint needs of the interconnecting parties.

   1.4. Connections between an AS and its traffic sources (generators) and
   traffic sinks (consumers) are called "Edge" (or sometimes "customer"),
   and their security policies are generally, by long standing tradition,
   nonexistent.

-------------> who does? the source is reachable.......via BGP.....its a
valid internet address...

Hold that thought for a bit, and remember that at least *some* of us were
discussing whether to drop packets if we *DONT* have a route to the source.

=========> you cant if its a valid internet address...can you?

......there are enuf asymmetric networks, i can assure of of that... for
one, you could simply try running a traceroute to some tracert sites from

ur

PC and a reverse trace from those servers to you.... ull find lots...

And the point is, that even *WITH* an assymetric route, that if I *DONT*
have a route back to you *somehow*, it's probably time for me to toss the
packet out the window. There's a distinction between "the route to the
source goes out an interface other than the one the packet arrived on"
and "there is no route to the source at all, via any interface".

========> but that isnt the case here is it...some of ur internal core
routers may not have every router running bgp, so what do u do for such
scenarios..u default route it to a bgp router....im missing your point.....

$author = "alok" ;

you can't if its a valid internet address...can you?

depends on what you mean by "valid".

- does "valid" = any 32 bit dotted quad?
- does "valid" = any IP not in 1918 space?
- does "valid" = any IP that the routing table has an entry for?
- does "valid" = packets from this IP came in the interface i would send
  packets out of to reach that IP?

but that isnt the case here is it...some of ur internal core
routers may not have every router running bgp, so what do u do for such
scenarios..u default route it to a bgp router....im missing your point.....

"loose" RPF on routers without full tables makes little sense. you choose
where to filter carefully and avoid the pitfalls you keep raising...

marty

here is the scenario

u have a bgp A ---ospf-B - bgpC router setup

what will u do on ospf -B ?

coz transit traffic can flow thru it...

"careful selection"... :o) well that way u can fill every hole .. no end to
it... and it generates good jobs :o)

but what i was trying to say to Valdis....was that u cant just "blindly"
drop packets in the core whose source doesnt have a route...for eg ospfB is
a problem in the above

heard of default routes..?.... u dont always need an iBGP full mesh u cud
redistribute a bit and "default route" a bit.... okie i know now...u give me
a practice doc and say "bad boy" :o)...

u can redistribute im sure there is nothing bad with that.......and also u
will tend to summarize a lot with default routes too....

that was my point.....

the other angle being "DDoS with spoofed ips".. right? those IPs care
intertnet registerd ips?

now no reason that if the router B runs OSPF that u may not have an entry
for the source IP... it will be there either via redistribution or via iBGP
if thats the way u want it.....or covered under default.... :o)

what i mean by valid is this: "registered internet IP address"

in this case you may have routes to the source network anyways iva iBGP or
redistribution... inspite of a "DDoS" or "assymetric cases" ....or it may be
a part of the "default route".....

also agreed this default route is more on the access end most guys tend to
have links between BGP routers or run iBGP etc......then the same logic
applies there too....

-rgds
Alok

Paul Vixie wrote:

here's what i came up with while trying to explain "the edge" elsewhere.
   1 - Connection Taxonomy
   1.1. The Internet is a "network of networks", where the component
   networks are called Autonomous Systems (AS), each having a unique AS
   Number (ASN).

Even if this reflects the original intent of ASNs, it certainly does not fit
current reality. Let's call any set of networks under a unified administrative control
an Autonomous Routing Domain (ARD). ARDs should not be confused with ASes (an
implementation detail). They are distinct for these reasons:

1) Most ARDs do not have an ASN -- they are statically routed "at the edge".
2) Many networks "at the edge" use private ASNs.
3) Many ARDs share a provider provided ASN -- RFC 2270.
4) Many ARDs are implemented with multiple ASNs. Internap is probably an extreme
example. But even UUNet's global ARD (AS701, 702, 705 ...) reflects an implementation
choice (one that Sprint does not seem to follow with 1239, for example).

---tim