On Mon, 16 Dec 2013, Smith, Donald wrote: > [ ... ] > From: C. M. Heard [[email protected]] > Sent: Sunday, December 15, 2013 8:57 AM > To: Smith, Donald > Cc: [email protected]; [email protected] > Subject: Re: [OPSEC] post iesg final version of > draft-ietf-opsec-ip-options-filtering (07) > > On Sun, 15 Dec 2013, Smith, Donald wrote: [ ... ] > > > Consider a LSRR A-B-C-D > > > > In this case, when the packet is originated the destination address > > in the IP header is A and the LSRR route contains BCD with the > > pointer pointing to B. > > Yea I could be confused as most of us don't support any type of SRR so I > haven't had much experience in it. > I am always willing to learn so thanks for any education you can provide me! > > It states what to do if you receive a SRR and the pointer is still > valid. But I don't see where it defines the creation of the > original SRR packet with A in the destination field? > From rfc791. > If the address in destination address field has been reached and > the pointer is not greater than the length, the next address in > the source route replaces the address in the destination address > field, and the recorded route address replaces the source > address just used, and pointer is increased by four. > > Does that mean when created the host must copy the first octet from the > option ssr field into the destination address field? > Or is that defined somewhere else?
The explanation in RFC 791 is, shall we say, just a bit terse. Excellent supplemental explanation may be found in RFC 1122 and RFC 1812. For this particular question see the DISCUSSION at the top of Page 37 in RFC 1122 for a picture of the correct way to format a source route option at the originating host. > I assumed a host with a default router would, in at least LSRR, send the > packet to it's default gateway (as the destination > addr) is that incorrect? The originating host would typically send te packet to its default gateway, though it could in principle choose another gateway if it knew about one. For LSRR the destination address in the IP header would not necessarily be the address of that gateway. For SSRR the destination is required to be the addess of the first-hop gateway. > > > > In this case, when the packet is originated the destination address > > in the IP header is A and the LSRR route contains BCD with the > > pointer pointing to B. > > > > > If A received it and ignores it (including the record route part) > > > and hands it off to something next to A (1 hop away) that device > > > could hand it back to A (since it should be in the RR path but > > > isn't) causing a loop that bounces between A and it neighbor until > > > the ttl expires right? So not only did it not arrive at the > > > destination it also could be used to ddos A. > > > > No. If A receives the packet and ignores LSRR it won't forward the > > packet at all; rather, it will assume that the packet is destined > > for itself because the destination address in the IP header is A. > > In other words, the packet will be delivered to A and not to D. > > In which case we can and should expect a response if you sent a packet to > most routers on a closed port it would send back a tcp > reset or a icmp error saying the port was closed (or maybe silently drop as > that is an option too). Yes, those are possible outcomes. Even if the port is not closed and the router accepts the packet for processing, it would probably fail the checksum test if the payload was TCP or UDP because the IP address in the pseudo-header is the final destination address. This would cause a silent drop too. It's possible to concoct examples where the packet would not be rejected in this way but all the ones I've come up with are rather far-fetched. The effect on end-to-end communication is of course the same as dropping the packet, but just ignoring the option can put an extra processing load on an intermediate router, and that is not an especially desirable outcome. The purpose of the note in draft-ietf-opsec-ip-options-filtering-07 is to alert operators to this possibility. > But I don't see where the initial packet assembly is defined only what to do > when a system receives a SSR with options and valid > pointer (not complete yet). Hopefully the reference to RFC 1122 that I provided above answers the question of initial packet assembly. A good explanation of what to do when the source route option is complete can be found in Section 5.2.4.1 of RFC 1812, which is at the top of page 72. If these references don't answer your questions please feel free to contact me on or off list and I'll see if I can dig up some better ones. Mike Heard _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
