Re: Path MTU (was: RE:)
--- Phil Dyer <phil.dyer@cox.net> wrote:
> Mike Mestnik wrote:
>
> >> mac address changes at every hop. The mac is *always* going to be
> your
>
> > Assuming you could, do the imposible and, find out what the original
> mac
> > was. (We seam to agree)You can't send a pkt to a mac address not on
> your
> > local network.
>
> I can only deal with the possible.
>
> >> next-hop router's address. No use sending it back to it, it doesn't
>
> > Not next-hop, where talking about source MAC, the last(previous)-hop.
>
> OK. Talking again about a stub net. The last router to touch the packet
> would be the router that all packets for your net come in on and go out
> on. It's the same router. outgoing Next hop and incoming prev hop are
> the same router. Semantics.
>
I was talking about changing/assigning Next-hop = Previous-hop. In this
case Next-hop would be on another interface, else we act normaly.
> >> care.
> >>
> > What do you mean by care? If I take you literaly, that router cared
> enuff
> > to send us the original pkt. The idea is the host(router) that gave
> us
> > the pkt had a reverse route for the IP. This MUST be true
> > since(other-wise) that router should/would have been the one to red
> flag
> > the pkt.
> >
> What information are you going to send that router? Are you going to
Not the router. See we can't send a pkt directly to the host that made
the original pkt. We can only try our best to convay that it must use a
diffrent route, I'm not sure a simple REJECT would do this.
> tell it that it sent you a packet it shouldn't have? What type of
> packet? Are you going to send an icmp dest unreachable? The router is
> forwarding packets. It's not the originator of the packet and if you
> send it a icmp dest unr. back to it, it's going to discard the packet.
> It simply won't know what you are talking about and drop the packet.
>
Your assuming the pkt is spoofed. There are perfectly legit reasons why a
pkt would not have the same reverse route.
> > In cases where that router made a mistake it would/might send the
> reject
> > pkt back to us. In these cases we can do one of two things, keep
> state
> > and see that we can just drop this pkt or subtract one from the
> > TTL(eventualy it will be out of time) and bounce it back.
>
> OK, here's my last on this. Let's have a scenario that is pretty common.
> udp packet with a spoofed source address. That's spoofed IP address. The
> packet is sent from the originating host and travels along the net thru
> routers that care about *1* thing - destination. They look at the
Your correct. This won't work if other routers don't do this. ISPs
should be preforming this step for it's customers. In that case a
REJECT(admin prohib) would be best.
> destination address and forward the packet out the right interface.
> Period. It moves along the net and finally gets to your network and hits
> your debian firewall, which is forwarding for an internal LAN. You are a
> firewall and you look at the source address and note that it says it's
> coming from your internal net, however it is coming in on the external
Hopefully your internal net uses public addresses that any one else could
be using.
> interface. Decision? Reject the packet? As I've said before, you don't
> know where to send it. Your stack is going to create a packet with a
> desstination address of a host on your *internal* net and then your
> routing table is going to make the decision to route that packet out
> your internal interface. It's that simple. There are no 'what if we
> could find the original mac address' or 'maybe the prev-hop router will
> do something if I send a packet'.
>
> At this point, we've gone miles past a response to path mtu discovery,
> and Steven's has a great book on TCP/IP.
>
>
> --
> To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
Reply to: