Thanks for the clarification Watson. I am always looking to learn new tricks and was hoping you might had one for distributed, large scale, remote packet captures. This is one area we have yet to fully conquer.
What you describe is something different, but also valuable and useful. But the best thing you illustrate, IMHO, is that none of these techniques or tools is a panacea. We need many arrows in our quivers to do an effective job of managing todays networks. Thanks again Mike From: Watson Ladd [mailto:watsonbl...@gmail.com] Sent: Saturday, July 15, 2017 7:08 PM To: Ackermann, Michael <mackerm...@bcbsm.com> Cc: Matthew Green <matthewdgr...@gmail.com>; Dobbins, Roland <rdobb...@arbor.net>; IETF TLS <tls@ietf.org> Subject: RE: [TLS] draft-green-tls-static-dh-in-tls13-01 On Jul 15, 2017 12:39 PM, "Ackermann, Michael" <mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> wrote: I would be interested in how you initiate the traces at all the hundreds of thousands of servers and clients and how you control the flow of pcap files back to where they need to be processed? How are users and apps not impacted? Currently I work at Cloudflare, not in ops. It's possible some of what I say is wrong. We don't collect all traces if I understand what you mean by trace as a packet capture. I misread your email. No technology I know of would make that possible at our scale. We do log a significant amount of information on requests and our responses include headers that indicate the path taken through the system.(the cf-ray you see when some sites fail behind us) We can quickly determine what went wrong if something did through internal inspection tools starting from those id's and problematic requests. This works to identify, isolate, and fix problems in a complex system with multiple internal services. This architecture scales to what we estimate as x% of all HTTP requests. Not x% of what we see, but of all of them. ( the x is sizeable) The logging is done with open source log collection software. Because packet capture and later decryption was not an option we created other tools. I don't know about internal app troubleshooting. Maybe we are talking at cross purposes, because I don't see why apps cannot log to local disk/ have a good idea of situations where pcap is really necessary and you can't log the keys. If you can log pcaps, you can log to disk somewhere. From: Watson Ladd [mailto:watsonbl...@gmail.com<mailto:watsonbl...@gmail.com>] Sent: Saturday, July 15, 2017 3:26 PM To: Ackermann, Michael <mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> Cc: Matthew Green <matthewdgr...@gmail.com<mailto:matthewdgr...@gmail.com>>; Dobbins, Roland <rdobb...@arbor.net<mailto:rdobb...@arbor.net>>; IETF TLS <tls@ietf.org<mailto:tls@ietf.org>> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 On Jul 15, 2017 11:16 AM, "Ackermann, Michael" <mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> wrote: YES! I tried to say in my message that collecting traces on thousands, or hundreds of thousands of hosts, is just not practical or possible. Not to mention the administrative domain barriers to this. We do it every day at my current employer. Guess we do the impossible. From: Dobbins, Roland [mailto:rdobb...@arbor.net<mailto:rdobb...@arbor.net>] Sent: Saturday, July 15, 2017 2:03 PM To: Ackermann, Michael <mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> Cc: Ted Lemon <mel...@fugue.com<mailto:mel...@fugue.com>>; IETF TLS <tls@ietf.org<mailto:tls@ietf.org>>; Matthew Green <matthewdgr...@gmail.com<mailto:matthewdgr...@gmail.com>> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 On Jul 15, 2017, at 22:36, Ackermann, Michael <mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> wrote: That being the unencrypted stream is available to the endpoints Even where it is eventually available, they don't have the horsepower to capture & forward. ----------------------------------- Roland Dobbins <rdobb...@arbor.net<mailto:rdobb...@arbor.net>> The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
