dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
28
share rss forum feed

HELLFIRE
Premium
join:2009-11-25
kudos:17
reply to HELLFIRE

Re: Burned by IP INSPECT -- My Own Personal Journey

@nosx

said by nosx:

Its the networks job to deliver packets, not mangle them.

Agreed, which makes me question one unnamed vendor's comment once upon a time of the ASA TCP-MAP
as "mangling packets" even less... though I don't have any operational experience with TCP-MAPs.

said by nosx:

the Jdownloader may violate the protocol in some way, or Cisco may be interpreting too strictly.

The fact that JDownloader was the ONLY one that didn't play nicely, makes me suspect the former... but how do you
prove that to the developers? Perfect Catch-22 situation.

said by nosx:

Have you tried inspect on different & newer IOS? What did TAC say? etc.

Just to give some context, this was on the home 1811 on 12.4T code. AFAIK, Cisco said that CBAC wouldn't
have new features added to it after 12.4T, and I haven't found any indications this is necessarily a bug, per se.
I get some time, I'll review the 15.x release notes for anything related to CBAC / HTTP/S inspection if anything
pops out or not.

@aryoba
said by aryoba:

I have been testing reliability of HTTP/HTTPS IP Inspection features on IOS and the results are never good.

Do you mind sharing some specific examples (non-NDA protected ones, of course) of what you experienced?
Like I said, this was a home environment rather than prod (thanks be for THAT!), so I just wanted to hear about
other experiences from the field for personal reference and learning.

said by aryoba:

This reminds me of a story that a lot of government entities encrypt their data over point-to-point dedicated private links as a requirement in order to avoid the situation where the ISP or telco stealing their data.

Financial institutions are nuts about this... and the funny thing is, especially for the client I deal with most, it's
not that hard to leave the encryption up to the ENDPOINTS to do (AES isn't that computationally expensive
on modern server hardware), yet I keep coming across multiple MACD requests to the carriers to set up
a P2P encrypted VPN requests as if it were the "in" thing to do these days...

@cramer
said by cramer:

Cost and speed trump security.

You're preaching to the choir on that one, brother! Amen!

Again, if anyones got more stories or experiences about IP INSPECT, please share.

Regards

nosx

join:2004-12-27
00000
kudos:5

Set up a packet capture and produce a PCAP of the behavior between the router and host running jDownloader. If there is any funny business with HTTP, many tools can decode those sessions and something obvious might jump out. Watch for the exchange right before the inspect engine kills the traffic and injects spoofed reset packets in both directions.

Getting developers on-board is always tricky, depending on how interested they are in fixing whatever is going wrong. There is also the possibility that the developers and Cisco are BOTH innocent, and the underlying library that the developers used is at fault. Lets face it, not many people are gung ho to write their own underlying application dependancies, we all use existing librarys that get the job done to save time, cost, and sanity.


aryoba
Premium,MVM
join:2002-08-22
kudos:4
reply to HELLFIRE

said by HELLFIRE:

said by aryoba:

I have been testing reliability of HTTP/HTTPS IP Inspection features on IOS and the results are never good.

Do you mind sharing some specific examples (non-NDA protected ones, of course) of what you experienced?
Like I said, this was a home environment rather than prod (thanks be for THAT!), so I just wanted to hear about
other experiences from the field for personal reference and learning.

Basically you can test HTTP/HTTPS inspection against any application such as Youtube for video streaming or news feed. I find the best application to troubleshoot and/or test is live streaming or constant traffic flowing since you can actually monitor any slowness or problems in real time. Start from some configuration template and tune your way in during test to get the best result. Time outs or keepalives, buffer sizes, are some factors you can tune. If you are unsure which factors you can tune, reading Cisco online documentations on the IOS command you are testing while doing the test I always find helpful.

aryoba
Premium,MVM
join:2002-08-22
kudos:4
reply to nosx

said by nosx:

Getting developers on-board is always tricky, depending on how interested they are in fixing whatever is going wrong. There is also the possibility that the developers and Cisco are BOTH innocent, and the underlying library that the developers used is at fault. Lets face it, not many people are gung ho to write their own underlying application dependancies, we all use existing librarys that get the job done to save time, cost, and sanity.

This is one of the reason why I prefer to work for small companies with tight relationship across highly technical people who actually know what they are doing; networks, servers, developers. The goal is about get things done quickly and efficiently without politics and finger pointing