[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC and Network Analysis
> The industry continues to distribute more and more layers of protocols,
> APIs, middleware, etc. Even with all the logging and trace files available,
> I still locate the source of a lot of problems by capturing and analyzing
> packets.
Lots of us are in this boat, Gary. My advisor once said, "There's no such
thing as too many traces."
> How easy will it be to turn the encryption off when necessary for
> troubleshooting? Will IPSEC render all the management and monitoring tools
> like RMON probes useless?
The idea behind IPsec is to make monitoring hard. In our minds, people who
monitor are adversaries of some kind. In your mind, monitoring is for
troubleshooting. Both mindsets are legitimate.
> I'd guess that this is highly implementation specific but was curious if
> anyone has thought about this.
I suspect we all have to some small degree. An implementation {SHOULD,MUST}
be able to turn off IPsec. If your network problem is local, then unplugging
your router and turning off IPsec would probably work and allow you to
troubleshoot without the kiddies coming in to bug you.
Another possibility is to be able to feed real IP security associations into
a monitoring tool, so that monitoring tool can decrypt/authenticate packets
that it reads as easily as the destination would. The flip side to this coin
is that an adversary (if he/she has access to the security associations) can
use such a tool to his/her benefit.
BTW, the only time you have to worry about this is with ESP. AH is just
another header, and can _easily_ be parsed around. I can't remember if the
NRL IPv6/IPsec distribution ships with its modified tcpdump, but when I was
at NRL we'd modified tcpdump to parse around AH and still see all of the
relevant TCP/UDP/etc. headers. It was nice to have.
Hope this helps,
Dan
References: