NAT behavior for IP ID field
I'm trying to locate an RFC that spells out the behavioral requirements, expectations or guidelines for NAT handling of the IP ID field, particularly for UDP messages. Section 3.2.5 in RFC 3235 briefly mentions issues surrounding IP fragmentation and reassembly, but it doesn't specifically say if NATs should re-write IDs as a general rule. RFC 4787 doesn't seem to address this either. If this is not written down anywhere, do NATs generally rewrite the ID field with or without the MF bit set? For background and reference, I refer you to Steve Bellovin's 'A Technique for Counting NATted Hosts', particularly section IV. Thanks for any pointers, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
On Tue, 2 Oct 2007 01:48:36 -0600 Danny McPherson [EMAIL PROTECTED] wrote: Again, any pointers empirical data along these lines would be appreciated. I said this awhile back: http://www.merit.edu/mail.archives/nanog/msg02196.html As a datapoint I ran some tests against a reasonably diverse and sizeable TLD zone I work with in another forum. I queried the name servers listed in the parent to see if I could successfuly query them for their corresponding domain name they are configured for using TCP. Out of about 9,300 unique name servers I failed to receive any answer from about 1700 of them. That is a bit more than an 18% failure rate. I think I overcompensated as I later found what looked like BIND 8 servers being unresponsive for multiple TCP queries in queue. I let the numbers stay, since the percentage of those servers were fairly small and, well, they were BIND 8 and probably have other problems anyway. :) John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
e2e
Responding to something just overheard in the plenary... No, it's not about complexity, but nor is it about robustness. It's about functionality and where to place it. A simple word search should help highlight this point. I'm a bit surprised I'm contradicting some who I have a great deal of respect and are most assuredly much more well known within the IETF than I. It either signals something fundamentally wrong with the IETF or, much more likely, me. :-) Perhaps all participants can commit to a twice careful read of the original paper that gets referred to so much before the next IETF? John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)
On Fri, 15 Jul 2005 11:48:28 -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: There are certain limitations to the SRV prefix scheme but these are entirely fixable. All we actually need is one new RR to allow one level of indirection to be introduced. With that in place it is possible to use prefixed SRV records in place of port assignments and prefixed TXT records as a means of expressing protocol configuration information. I'm concerned this may usher in DNS SRV message filtering in addition to protocol port filtering. One way of addressing that potential effect is to make the port assignments be negotiated between two communicating end hosts. This could be used with or without DNS. It might also provide some remote attack protection, since only a simple passive listener is used to perform the local/remote address/port selection for any active client before the real communication switches to agreed upon (and bound only to) the two process end points. John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)
On Tue, 19 Jul 2005 09:44:57 -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: I'm concerned this may usher in DNS SRV message filtering in addition to protocol port filtering. Why? My post pointed out that use of SRV is essentially neutral with respect to protocol filtering. It makes it easier to filter well behaved protocols, it does not prevent stenographic approaches. Fundamentally the use of SRV for service location may be a fine idea. Practically, at least in my experience, fundamentally new and easily identified fields (e.g. ECN or in this case SRV or a new RR type), will be ripe for filtering and will be filtered, often by default. This may not be such a big deal architecturally, since it doesn't necessary change current or future network policies. Operationally it will add additional complexity and another unique vector for network fragmentation. From an operational perspective, I'm not interested in any more options to make it easier to increase either. I might question the value of this approach now, though I would certainly encourage experimentations to see how this might turn out. From a security point of view there is a big difference in the accountability structures when dealling with protocols that require prior bilateral discovery (e.g. tunneling botnet control packets over HTTP) and those that allow for unilateral session initiation (e.g. tunneling botnet control packets over IRC). I'm not following what you mean here. Note, there are some, though not as prevalent, botnets that natively use HTTP for control. There is a reason that the botnet herders stick with IRC despite the fact that it is routinely blocked in corporate environments. Systems that require bilateral discovery are very hard to set up and fragile in operation. Systems with a common signaling mechanism are in practice much more robust. Those points are probably debatable. IRC is often used, because it still generally works well to control botnets. I don't think HTTP botnets are necessarily any harder to setup and maintain and I think one could argue that they could be even easier to setup and maintain. Promoting everything to the DNS level means that an ordinary Internet user can enfrachise their Internet connection simply by purchasing their own DNS name. You may be right and it may work better than what we have now. My primary suggestion was to consider making the actual socket parameters negotiated and bound only to the local/remote address/port pair. Though perhaps that may complicate stack implementations with questionable end value. There are security concerns here, but remember that according to today's standard Internet firewall configuration externally facing systems live separated in their own DMZ in any case. The only protocol access allowed is from the inside to the outside. Yes, and many configurations also strictly limit what services are allowed from the inside to the outside. John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
1918bis
Tony, [ Posting this to the main ietf list as well as to you directly in case you don't see it there. I realize this may be a controversial topic that results in an endless thread of heated arguments, but I'll take my chances since I'm curious to hear reasons for or against the draft. ] I must have missed it the first time it came around last year, but I just saw your draft. I didn't find much discussion on the -00 version so I hope this is the best place to discuss it. Can you clarify some things for me? You say this: A number of organizations have expanded their autonomous private networks to the point of exhausting the address space identified in RFC 1918, in addition to the publicly routed space that has been assigned to them. Are there public pointers to discussion about the requirement for new private IPv4 space? I'd be particularly interested in specific organizations that are having this problem if they have been willing to come forward publicly. I'd also be interested to hear what about policies for acquiring space from the registries has been unreasonable. Is it cost, address usage justification, both or something else? Your first example mentions /21 netblocks being allocated to each of 5000 sites. Sounds like there is probably a lot going to waste, but I'm not that interested in criticizing the specific addressing plan of the organization. I know how much of pain it is to try to maximally utilize address space. I am curious if the scale of this addressing scenario is unique to the draft's example or if it is happening at a number of organizations as seems to be implied. I guess one point of this is, if it's relatively uncommon except for a small number of the very largest of organizations in the world, it would seem to make more sense to exhaust all attempts at obtaining public address space. Especially since if the organization does move to IPv6, or simply just goes away, it's allocated address space can be more easily reclaimed and redeployed than private address space could be. Finally, I'm also wondering if there is anything political driving this solution that has not yet been put into the draft. For example, I can imagine some well funded, large organization not wanting to have their name on a specific public /8. You don't have to say you, just wink blink twice for yes, once for no. :-) John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 13 Root Server Limitation
On Sun, 16 May 2004 19:01:17 -0400 Joe Abley [EMAIL PROTECTED] wrote: reconvergence events to non-anycast servers). In addition, before the frequency of the route churn became sufficiently high to cause a problem, it would be well and truly damped to death by anybody running with common BGP damping parameters and the inability to talk to the few root servers which have anycast instances would be the last of your problems. Not necessarily. Common dampening parameters exclude some 'golden networks' such as root name server networks from damping. RIPE 229 and Rob Thomas' Secure BGP template being perhaps the two most widely cited guides that suggest such a practice. John ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: proposal for built-in spam burden email privacy protection
On Mon, 09 Feb 2004 13:49:53 -0800 Ed Gerck [EMAIL PROTECTED] wrote: 8. How about spammers using 100,000 slave PCs to share the burden? [...] Comments? Ed, I'm not sure I see the value in requiring encryption. To me this does not seem to really fix anything. On the one hand, this just forces spammers to begin collecting public keys and email addresses as opposed to just addresses. With the former, they probably end up with a much more reliable and stable form of contact since people are not going to want to have throw-away keys, at least not in the way PGP, for example, is currently used. On the other hand, this just adds some, but not that much in my opinion a processing burden for spammers to encrypt messages. Processing that can currently be found in compromised hosts (today) or in faster CPUs (tomorrow). I think the argument becomes slightly stronger if the delay is an absolute value that can be enforced per TCP segment, connection or whatever, but even that is not ideal. Also note, there is an addition burden placed on end users who rely on receiving encrypted email in your proposal. Under your scheme, a user has to go through the trouble of decrypting the message just to see if it is spam or not. This eliminates almost all forms of automated spam mitigation except those related to the low-level SMTP, DNS or other new authentication/authorization techniques. John
Re: Adding [ietf] considered harmful
On Thu, 18 Dec 2003 13:07:24 -0500 Keith Moore [EMAIL PROTECTED] wrote: I'm a bit surprised at the frequency at which people who claim to be networking protocol engineers fail to appreciate the benefits of clean separation-of-function and layering. Hopefully the drawbacks are appreciated also. Quoting Rich Seifert, Layering makes a good servant, but a poor master. Use layering to organize the way you THINK about networks, but don't let it restrict how you DESIGN networks. If I recall correctly, David Clark used to say something very similiar to this in a protocol workshop class at Interop awhile back. John
Re: www.isoc.org unreachable when ECN is used
On Fri, 12 Dec 2003 21:01:09 +0100 Anthony G. Atkielski [EMAIL PROTECTED] wrote: It sounds like ECN is pretty badly designed; I'm glad it wasn't my idea. Those are pretty bold statements. http://www.icir.org/floyd/ecn.html The above page seems to indicate that there was a lot of thought that went into ECN and other related protocols. Some of links to ECN papers and related congestion issues from Sally's pages make good reading. Some of the work actually goes back quite a ways and not all of it based on TCP/IP. In my opinion, much of what has Sally Floyd's name on it, including ECN, is exceptional. John
Re: national security
On Fri, 28 Nov 2003 14:47:41 +0100 Anthony G. Atkielski [EMAIL PROTECTED] wrote: (or perhaps not diminished at all). However, in reality, dividing the field in this way may reduce the address space by a factor of as much as nineteen orders of magnitude. Again and again, engineers make this mistake, and render large parts of an address space unusable through careless, bit-wise allocation of addresses in advance. The 48-bit addresses in IEEE/L2 protocols are divided in half as well as have a couple bits set aside to denote local/global scope and unicast/multicast addresses. It seems to have worked out pretty well. John
Re: A peer-to-peer trust system model
On Thu, May 29, 2003 at 08:36:55PM -0400, John Stracke wrote: someone who is sending me a human generated message can generally easily afford the 2 minutes worth of CPU time before their mailers can deliver the message to my mail host.) But what CPU? The machines with which I routinely send mail range from a 200MHz handheld to a 2GHz*2 desktop. I would be unhappy with a protocol that required me to run my handheld's CPU at full speed for 2 minutes (the battery life isn't so hot); but that level of hashcash would Rather than actually force the remote CPU be run for 2 minutes, the receiving SMTP host can force the TCP window to 0 for 2 minutes. This could be coupled with a RBL list, but instead of a blackhole, it would be more like a realtime pushback list (RPL), which has some nice properties of punishing known abusers, but not causing complete collateral damage to innocent parties. John
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
On Thu, Mar 27, 2003 at 06:46:10PM -0500, Keith Moore wrote: No, it's more than that. SLs impose burdens on hosts and apps. SLs break the separation of function between apps and the network that is inherent in the end-to-end principle. Is it safe to assume that the arguments (on either side) would also apply to such things as multicast addressing and SCTP path management? Actually we are working toward an architecture that provides a level of consistency. Which is essentially what I'm rephrasing into a question above. I think I know the answer, but I want to make sure. John
Re: IAB policy on anti-spam mechanisms?
On Tue, 11 Mar 2003 15:42:00 -0500 John Stracke [EMAIL PROTECTED] wrote: Perhaps the notion of a well known port is a concept whose time has passed. At least for connection oriented protocols, doing away with well known ports might have some good properties for some basic authentication/cookie mechanism as well. Well, there's SRV records; but that basically pushes the problem up a layer. If services are identified by well-known service names in the SRV record, then people will start filtering at the DNS level. What I was inferring was not to do away with ports entirely, but to make them so they are all ambiguous. Somehow knowing the application and its associated port would be learned rather than well known. John
Re: IAB policy on anti-spam mechanisms?
On Thu, 27 Feb 2003 10:15:34 -0600 Spencer Dawkins [EMAIL PROTECTED] wrote: It might be interesting for IAB to think about the estimated half-life of well-known port numbers in the Internet architecture, since we've been seeing It might be interesting to find a way to make port numbers so meaningless that you either have to let them all through or none of them through (which obviously isn't useful). Perhaps the notion of a well known port is a concept whose time has passed. At least for connection oriented protocols, doing away with well known ports might have some good properties for some basic authentication/cookie mechanism as well. Or we could just let HTTP become the transport layer until blocking is done within the content of those messages, but we can just keep building transports on top until some MTU is reached. :-) John
Re: filtering of mailing lists and NATs
James Aviani wrote: I know this is fairly low-tech, but it seemed like a reasonable and practical solution to spamming. This is a interesting if not good idea. Some of the details may need to be worked out (like perhaps certain people opt in or opt out of being a moderator), but the technical implementation is probably the easy part. If you've given the IETF a solution without causing a theological debate over the 'technical purity' of it, you've left your mark for posterity. John
Re: Multicast File Distribution protocols?
Mark Atwood wrote: Can anyone post a pointer? Here's one: http://www.globecom.net/ietf/draft/draft-miller-mftp-spec-03.html I'm curious what happened to Starburst http://www.starburstcom.com. Their mftp was pretty cool, but it looks like they are no longer around. John
Re: [midcom] WG scope/deliverables
On Wed, Feb 14, 2001 at 10:44:47PM -0500, Keith Moore wrote: it's hardly surprising that professional network administrators are more likely than the average home user to understand the limitations of NATs, [...] a significant percentage of the folks who will drive v6 deployment will be those who have learned about those problems the hard way and are in need of a real solution. they won't be fooled again. Keith, It has been my experience that many of the current network admins today believe NAT is the de facto way of connecting to the Internet. In fact, in one of the network classes I teach, it takes a lot of convincing on my part to show that NAT offers them very little security. Most net admins today have only seen a world through NAT eyes so they don't see the benefits of not having it. If you want people to live in a world without NAT, I think you have to have the killer application that simply will not function properly with it. This is much more difficult than it sounds. As hard as people like the IETF try, many new network protocols will continue to fail if 1) legacy applications are not supported or 2) killer applications are not available to drive the demand. John
IP over DNS
This is interesting consequence of a restrictive perimeter. As long as one application is allowed in and out of your jail, the application is doomed to become the network layer. http://nstx.dereference.de/ http://slashdot.org/articles/00/09/10/2230242.shtml John
Re: Sequentially assigned IP addresses--why not?
"Corzine, Gordie" wrote: Look, my days as an engineer are a distant memory, so I won't try to work this out in detail. Maybe there are irrefutable reasons why this can't be done, but I do believe the current architecture will lead to premature exhaustion of the address space. It will take far longer to design and deploy something that is so technically elegant it solves all problems and pleases everyone. At some point you simply have to move forward. To do nothing can be far more dangerous (as proven by the disdain for NAT). Can IPv6 be worse for the net than NAT? If premature depletion of IPv6 addresses is the biggest problem IPv6 ends up encountering I'd say the net is in good shape. It's probably more likely that new problems no one had considered will arise. I see rough consensus, move forward. John
Re: VIRUS WARNING
John Stracke wrote: Well, there's basic formatting: [...] And even simple links (never mind forms, applets, etc.) are great for, say, workflow applications. When I worked for Netscape, HR made great use of HTML mail in the internal network. When I wanted to take some Email is not the web. John
