At 15:06 05/03/01 +0000, Daniel Crichton wrote:
>Should have copied this to the list as well.
I did send my msg to the ML:)
>------- Forwarded message follows -------
>
>On 5 Mar 2001, at 15:56, mouss wrote:
>
> > [Problem 1]
> > assume my host is 10.1.2.3. Now assume that your router has the same
> address.
> > Can you explain to me how I can traceroute through your router. More
> > precisely, tell me what happens in your router stack when it is sending
> me an
> > ICMP ttl exceeded.
>
>AFAIK Traceroute works by sending ICMP packets to the destination
>address (the public IP at your are trying to trace to) with each packet
>having a
>TTL of 1 higher than the 1 before. This TTL value determines where the packet
>will be returned from, so the first one is returned by your upstream
>router, the
>next by the 1 up from that, and so on until you get to the end. When the
>router
>with the private IP address gets a packet it has to return instead of passing
>on
>it simply returns it to your machine with the source address set to the
>private
>address,
It's here that I come!
If I understand you: the router with 10.1.2.3 as one of its addresses sends
an IP
packet to 10.1.2.3 over the wire? That would be a revolutionary stack.
> but as it's not a TCP connection, just an ICMP packet being sent
>back,
>only the destination (your address) is important. When your machine
>receives it
>the source address is shown in the trace, which is the private address, but
>you
>can't actually connect to that address using TCP or send it UDP/ICMP
>packets.
Come on. I'm not talking about sessions, TCP or anything else. I'm fully in
plain IP.
just routing, nothing more. when a host with an IP address 1.2.3.4 needs to
send
an IP packet to 1.2.3.4, then it realizes that this is one of its addresses
and hand
it to the local handler.
> > [Problem 2]
> > Assume your router has a private address, say 10.1.2.3. Tell me why can't I
> > telnet to? The purpose of this question is that you come up with the
> > conditions that make it impossible to connect to your router, and then
> compare
> > these conditions with just blocking access to your router if it had a
> public
> > address.
>
>You can't connect to 10.1.2.3 from your end as there is no route defined on
>the
>internet, ie. once your packet hits a router outside your LAN (or even
>inside if
>you don't use the 10.x.x.x addresses on your own network) the packet is
>returned/dropped as there is nowhere to send it, as the next router upstream
>doesn't have a route to send the packet do (well, if I've read the RFC right
>there is a route, but it's a "blackhole" where all packets that reach the
>appropriate router are just dropped never to be seen again).
uhummmm....
- IP options allow source routing. so if the router doesn't disallow these,
you're
gonna get'em
- If I manage to router poisoning, then I can come to your door.
These are not easy, but IP still allows'em.
That's what I meant by not relying on other routers. If you wanna feel secure,
lock your door, yourself. don't count on "them".
> > [Problem 3]
> > Now, why not use ypur router in bridge mode, in which case it is simply
> > invisible?
>
>AFAIK only any good if you are bridging 2 physical networks that are part of
>the
>same subnet, but I'm no router expert (as you can already see from my
>starting
>this whole thread!). Routers can be hidden (I have a couple of routers
>here set
>for bridging to connect 2 offices as a single subnet) or visible (like my
>router
>connecting me to my ISP), and you can filter packets to prevent routers from
>being "seen", and now I'm going to revise my network layout to do just this
>as I
>can see that having private addresses "visible" to the internet can result in
>additional packets being generated that just end up wasting (albeit a tiny
>percentage) of bandwidth as they are routed to be discarded somewhere in
>IANA.
If your router allows you to use bridge mode on a rule basis, then you can
configure it visible from your hosts and invisble for the rest of us. This is
better than giving it a private addr.
cheers,
mouss
>Dan
>
>
>
>---
>D.C. Crichton email: [EMAIL PROTECTED]
>Senior Systems Analyst tel: +44 (0)121 706 6000
>Computer Manuals Ltd. fax: +44 (0)121 606 0477
>
>Computer book info on the web:
> http://computer-manuals.co.uk/
>Want to earn money? Join our affiliate network!
> http://computer-manuals.co.uk/affiliate/
>
>
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
