(coffee != sleep) & (!coffee == sleep) [email protected]
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: > > This: > > Please note that treating packets with LSRR as if they did not > > contain this option can result in such packets being sent to a > > different device that the initially intended destination. > With > > appropriate ingress filtering this should not open an attack > vector > > into the infrastructure. Nonetheless, it could result in > traffic > > that would never reach the initially intended destination. > Dropping > > these packets prevents unnecessary network traffic, and does > not make > > end-to-end communication any worse. > > > > > > Should be this: > > Please note that treating packets with LSRR as if they did not > > contain this option can result in such packets being sent to a > > different device THAN the initially intended destination. > With > > appropriate ingress filtering this should not open an attack > vector > > into the infrastructure. Nonetheless, it could result in > traffic > > that would never reach the initially intended destination. > Dropping > > these packets prevents unnecessary network traffic, and does > not make > > end-to-end communication any worse. > > > > It also isn't true:( > > Actually, it IS true. > > > 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? 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? > > 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). 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). > > //xmh > > _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
