7 ms·

Um, you're aware that he wrote http://insecure.org/stf/secnet_ids/secnet_ids.html http://insecure.org/stf/secnet_ids/secnet_ids.html, worked for a networking (s

Um, you're aware that he wrote http://insecure.org/stf/secnet_ids/secnet_ids.html http://insecure.org/stf/secnet_ids/secnet_ids.html, worked for a networking (security) company (Arbor) for years, etc.? He may be wrong, and he may think that he knows more than he actually does, but he does know a thing or two. ;-) Regarding overlay networks: note that HTTP, WebSocket, Skype, BitTorrent and such are already looking quite a bit like an overlay network, and that increasing amounts of NAT-ting are making the classic point-to-point model of the internet more and more irrelevant. I'm not sure I particularly like this vision of the future, and I agree that the performance will be worse, but it's far from insane. (As to performance, note how everything is routed over HTTP these days, despite it being rather inefficient for lots of use cases.)

nknighthb 13y ago
Forgive me, as I don't have time at the moment to review the paper in detail, but none of what I see skimming through it really contradicts what I already believed. Knowing how the protocols work is not the same thing as knowing how to architect and manage large networks. The "overlay" networks you speak of are already hamstrung by the shrinking ability to directly address endpoints on the Internet. IPv4's fundamental flaws when applied to billions of nodes cannot be papered over forever.
- wglb 13y ago
  I don't have time at the moment to review the paper in detail, But you have time to make multiple complaints about tptacek not knowing what he is talking about? May I suggest you withdraw from this line of argument?
  - nknighthb 13y ago
    > May I suggest you withdraw from this line of argument? May I suggest that you look at the paper in question and realize it is one that requires careful and uninterrupted attention for an extended period of time to properly understand? May I also suggest that you not make assumptions as to what another person is or is not doing, and how it may interfere with their ability to do some things but not others? Or would you rather just be a judgmental, holier-than-thou asshole?
    - tptacek 13y ago
      As a reminder, this is what you said upthread: My conclusion is that his application-level networking experience has fooled him into thinking he knows more than he does about actual network architecture, management, and performance issues. Or maybe he doesn't realize the issues even exist. My conclusion is that you made that comment having absolutely no idea what my experience was, and then decided to get pissy when the facts didn't line up with your bet. I've made the same dumb bet on HN a bunch of times. "This is just some Ruby dork who knows fuck all about", I don't know, "tax law". It never works out for me, either. The thread is now full of technical commentary about the point I made. Lots of smart people disagree with me; no surprise! You've contributed none of that commentary. Maybe now's a good time to start? You seem to feel passionately about the issue.
      - nknighthb 13y ago
        > you made that comment having absolutely no idea what my experience was I made the comment based on the fact that the only thing you ever talk about actually doing is security-related. On everything else, you just pontificate context-free. You implied earlier I should have looked at your "public linkedin profile". You should know that, for me, your profile contains nothing but your current and past employers, and your university. Nothing about what you did there. What was I supposed to conclude from that? I've spent most of my career working for companies that do video-related work, but if you ask me a question about MPEG transport streams, I'll refer you to the guy who, y'know, actually deals with MPEG. At this point I am pissy, yes, but that's not because I was wrong, it's because of the asshole who decided he knows better what my personal time commitments are than I do. > The thread is now full of technical commentary about the point I made. No, it isn't. The thread is full of cursory rejections of your equally cursory commentary. There is absolutely nothing interesting about any of it, because it's all surface bullshit that everybody already knows. There are no details. There's nothing concrete. There's nothing new. Boring, hand-wavy crap. Propose something concrete, something that actually addresses the obvious criticisms you already know are going to be leveled, and I might get interested. Right now, all I'm interested in is ignoring HN for a while.
        13y ago
ginko 13y ago
>increasing amounts of NAT-ting are making the classic point-to-point model of the internet more and more irrelevant. which is a bad thing.
- tptacek 13y ago
  It's a bad thing now, because the only way to get assured direct connectivity to the "Internet" is via IPv4 connectivity. It would be less of a bad thing if IPv4 connectivity (specifically: what ASN was advertising the IPv4 prefixes your traffic was associated with when it traversed, say, Telecom Malaysia) wasn't the sine qua non of global connectivity, in the same sense that nobody cares what IP address you use when you connect to IRC.
  - ay 13y ago
    You can connect to IRC because the IRC server is not behind a NAT. Try to run an IRC server on your host which runs behind the consumer NAT which runs behind the CGN. Yes, if the gear supports it, you can use uPNP for the first, and PCP for the second, to open up a port. Unless someone is using it already. Then you need to choose another port. Which you need to communicate to the other clients behind the NATs around the world. Fine, we'll just update the DNS server with an SRV record. You probably will always have a spare public IPv4 address to map the ports 53 to something on the inside network, so this might work. Until your CGN does not have enough IPv4 addresses/ports to permanently allocate one to you. Oh, by the way this is a great way to introduce a "premium" tier service with a public IP address - if you really want to run a server then you can buy an address. So doing the PBX-style circuit switching with NATs is not really in the economic interest of the ISPs. (Not saying that they need to do all the accounting/logging). If the app is awesome enough that the users will pay extra to get the public address - great. That will help to further exhaust the IPv4 addresses and drive the prices up. Rinse, repeat. I am of course exaggerating. But this presentation from NANOG may be a less biased view (though Lee's employer does deploy IPv6, so you can argue it is biased): http://www.nanog.org/sites/default/files/wed.general.howard.gametheory.17.pdf http://www.nanog.org/sites/default/files/wed.general.howard.... Full disclosure: I am into this IPv6 thing. Before that, I spent ~10 years of my life at a random 5-letter vendor to find the bugs in the code and misconfigurations causing outages in people's NATs. It's refreshing to be able to use access-lists again. (the latter statement is only partially correct, but this is a topic for another rant, IPv6 has tons of its warts as well :-)

nknighthb 13y ago

Forgive me, as I don't have time at the moment to review the paper in detail, but none of what I see skimming through it really contradicts what I already believed. Knowing how the protocols work is not the same thing as knowing how to architect and manage large networks. The "overlay" networks you speak of are already hamstrung by the shrinking ability to directly address endpoints on the Internet. IPv4's fundamental flaws when applied to billions of nodes cannot be papered over forever.

wglb 13y ago
I don't have time at the moment to review the paper in detail, But you have time to make multiple complaints about tptacek not knowing what he is talking about? May I suggest you withdraw from this line of argument?
- nknighthb 13y ago
  > May I suggest you withdraw from this line of argument? May I suggest that you look at the paper in question and realize it is one that requires careful and uninterrupted attention for an extended period of time to properly understand? May I also suggest that you not make assumptions as to what another person is or is not doing, and how it may interfere with their ability to do some things but not others? Or would you rather just be a judgmental, holier-than-thou asshole?
  - tptacek 13y ago
    As a reminder, this is what you said upthread: My conclusion is that his application-level networking experience has fooled him into thinking he knows more than he does about actual network architecture, management, and performance issues. Or maybe he doesn't realize the issues even exist. My conclusion is that you made that comment having absolutely no idea what my experience was, and then decided to get pissy when the facts didn't line up with your bet. I've made the same dumb bet on HN a bunch of times. "This is just some Ruby dork who knows fuck all about", I don't know, "tax law". It never works out for me, either. The thread is now full of technical commentary about the point I made. Lots of smart people disagree with me; no surprise! You've contributed none of that commentary. Maybe now's a good time to start? You seem to feel passionately about the issue.
    - nknighthb 13y ago
      > you made that comment having absolutely no idea what my experience was I made the comment based on the fact that the only thing you ever talk about actually doing is security-related. On everything else, you just pontificate context-free. You implied earlier I should have looked at your "public linkedin profile". You should know that, for me, your profile contains nothing but your current and past employers, and your university. Nothing about what you did there. What was I supposed to conclude from that? I've spent most of my career working for companies that do video-related work, but if you ask me a question about MPEG transport streams, I'll refer you to the guy who, y'know, actually deals with MPEG. At this point I am pissy, yes, but that's not because I was wrong, it's because of the asshole who decided he knows better what my personal time commitments are than I do. > The thread is now full of technical commentary about the point I made. No, it isn't. The thread is full of cursory rejections of your equally cursory commentary. There is absolutely nothing interesting about any of it, because it's all surface bullshit that everybody already knows. There are no details. There's nothing concrete. There's nothing new. Boring, hand-wavy crap. Propose something concrete, something that actually addresses the obvious criticisms you already know are going to be leveled, and I might get interested. Right now, all I'm interested in is ignoring HN for a while.
      - 13y ago

ginko 13y ago

>increasing amounts of NAT-ting are making the classic point-to-point model of the internet more and more irrelevant. which is a bad thing.

tptacek 13y ago
It's a bad thing now, because the only way to get assured direct connectivity to the "Internet" is via IPv4 connectivity. It would be less of a bad thing if IPv4 connectivity (specifically: what ASN was advertising the IPv4 prefixes your traffic was associated with when it traversed, say, Telecom Malaysia) wasn't the sine qua non of global connectivity, in the same sense that nobody cares what IP address you use when you connect to IRC.
- ay 13y ago
  You can connect to IRC because the IRC server is not behind a NAT. Try to run an IRC server on your host which runs behind the consumer NAT which runs behind the CGN. Yes, if the gear supports it, you can use uPNP for the first, and PCP for the second, to open up a port. Unless someone is using it already. Then you need to choose another port. Which you need to communicate to the other clients behind the NATs around the world. Fine, we'll just update the DNS server with an SRV record. You probably will always have a spare public IPv4 address to map the ports 53 to something on the inside network, so this might work. Until your CGN does not have enough IPv4 addresses/ports to permanently allocate one to you. Oh, by the way this is a great way to introduce a "premium" tier service with a public IP address - if you really want to run a server then you can buy an address. So doing the PBX-style circuit switching with NATs is not really in the economic interest of the ISPs. (Not saying that they need to do all the accounting/logging). If the app is awesome enough that the users will pay extra to get the public address - great. That will help to further exhaust the IPv4 addresses and drive the prices up. Rinse, repeat. I am of course exaggerating. But this presentation from NANOG may be a less biased view (though Lee's employer does deploy IPv6, so you can argue it is biased): http://www.nanog.org/sites/default/files/wed.general.howard.gametheory.17.pdf http://www.nanog.org/sites/default/files/wed.general.howard.... Full disclosure: I am into this IPv6 thing. Before that, I spent ~10 years of my life at a random 5-letter vendor to find the bugs in the code and misconfigurations causing outages in people's NATs. It's refreshing to be able to use access-lists again. (the latter statement is only partially correct, but this is a topic for another rant, IPv6 has tons of its warts as well :-)