Is a good knowledge of either origin-AS, or next-AS with respect to flows valuable in establishing, monitoring, or re-enforcing a security posture? In what ways? TIA, Joe
On Thu, 15 Dec 2011, Joe Loiacono wrote:
Is a good knowledge of either origin-AS, or next-AS with respect to flows valuable in establishing, monitoring, or re-enforcing a security posture? In what ways?
If I'm understanding your question correctly, I think it can be helpful, to a degree. It's always good to 'know your neighbors', but for the most part I don't think an organization's security posture would change very much, based strictly on next-AS. In the case of next-AS, you already know your neighbors somewhat, because you have some sort of a business relationship with them (your transit providers, peers, downstream BGP-speaking customers, etc). origin-AS could be another story. If you know of an AS that is being used by the bad guys for bad purposes, you can write a routing policy to dump all traffic to/from that AS into the bit bucket or take some other action that could be dictated by your security policy. In that case, a routing policy could be considered an extension of a security policy. jms
-----Original Message----- From: Justin M. Streiner [mailto:streiner@cluebyfour.org] Sent: Thursday, December 15, 2011 9:45 AM To: nanog@nanog.org Subject: Re: Is AS information useful for security?
origin-AS could be another story. If you know of an AS that is being used by the bad guys for bad purposes, you can write a routing policy to dump all traffic to/from that AS into the bit bucket or take some other action that could be dictated by your security policy. In that case, a routing policy could be >considered an extension of a security policy.
I could be wrong here but I believe origin-AS uses a lookup from the routing table to figure out what the originAS for the source IP should be (and not what it explicitly IS) which means the information is unreliable. For example if someone is sending spoofed packets towards you the origin AS will always show up as the originator of the real route instead of the origin AS of the actual traffic. This is why it would be useful to have the originAS (from the actual origin) in the packet header. Thanks, -Drew
On Thu, Dec 15, 2011 at 11:28:48AM -0500, Drew Weaver wrote:
I could be wrong here but I believe origin-AS uses a lookup from the routing table to figure out what the originAS for the source IP should be (and not what it explicitly IS) which means the information is unreliable.
Using a bit of Cisco jargon, i believe we speak of source peer-AS and asymmetric routing. True what you say but a more accurate information can be achieved by correlation, ie. against the input interface. This leaves open the case of input traffic from a shared medium ie. an IXP. If using sFlow, MAC layer information would be pretty much available for the job; if using NetFlow instead, NetFlow v9 (and IPFIX .. brrr) could come to the rescue .. if was not for lack of implementation of the MAC layer primitives for routed traffic (ie. not switched) by the vendors on the bigger pieces of iron (ie. no ASR1K, software routers, etc.). Cheers, Paolo
On 15/12/2011 16:28, Drew Weaver wrote:
-----Original Message----- From: Justin M. Streiner [mailto:streiner@cluebyfour.org] Sent: Thursday, December 15, 2011 9:45 AM To: nanog@nanog.org Subject: Re: Is AS information useful for security?
origin-AS could be another story. If you know of an AS that is being used by the bad guys for bad purposes, you can write a routing policy to dump all traffic to/from that AS into the bit bucket or take some other action that could be dictated by your security policy. In that case, a routing policy could be>considered an extension of a security policy.
I could be wrong here but I believe origin-AS uses a lookup from the routing table to figure out what the originAS for the source IP should be (and not what it explicitly IS) which means the information is unreliable.
For example if someone is sending spoofed packets towards you the origin AS will always show up as the originator of the real route instead of the origin AS of the actual traffic.
This is why it would be useful to have the originAS (from the actual origin) in the packet header.
How would you determine and enforce this? Ok so a packet leaves my network that I know originated from my network based on some factor (IGP route existing or matched prefix list) and the origin AS is put into a new field in the packet header... Whats to stop the spoofer putting that origin AS into their spoofed packet headers? This means that another level of checking then needs to be put into inter AS BGP sessions to make sure that all traffic passing across the link would need to be checked to make sure origin ASs are matched. Couldn't most of the same protection be solved by more people running BCP38 and RPKI?
Thanks, -Drew
It's useful in terms of remediation as it can help identify through which "door" packets entered your network. Though, as others will undoubtedly point out, it's trustworthiness will depend upon how you derive the AS mapping and upon other security features (e.g. uRPF) -- Eric :)
On Thu, 15 Dec 2011, Joe Loiacono wrote:
Is a good knowledge of either origin-AS, or next-AS with respect to flows valuable in establishing, monitoring, or re-enforcing a security posture? In what way?
participants (6)
-
Drew Weaver -
Eric -
Joe Loiacono -
Justin M. Streiner -
Paolo Lucente -
Patrick Sumby