Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
On 2007-07-14 00:07, Melinda Shore wrote: On 7/13/07 5:43 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I believe that we need a more general protocol for hosts inside a site perimeter to communicate with the perimeter gateways and request services from them. We've actually got several of them, starting with SOCKS (which could have been extended), continuing through RSIP, on to midcom and SIMCO. Note that midcom was so named under the assumption that whatever was done would be extensible to other sorts of middleboxes than firewalls and NATs We could spend an awful lot of time talking about why none of them has caught on, but I think it's fair to say that that failure has not been caused by a perceived lack of generality. Maybe by a lack of simplicity? draft-woodyatt-ald-01 is a recent proposal. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
Hi Brian, regarding lack of simplicity: Different solutions build on different assumptions. If you make specific assumptions then the solution is much simpler. There is a recent document that aims to compare some of the NAT / firewall protocol proposals: http://www.ietf.org/internet-drafts/draft-eggert-middlebox-control-survey-01.txt It is not yet finished but might give you an idea what the different assumptions of some of the proposals are. Ciao Hannes Brian E Carpenter wrote: On 2007-07-14 00:07, Melinda Shore wrote: On 7/13/07 5:43 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I believe that we need a more general protocol for hosts inside a site perimeter to communicate with the perimeter gateways and request services from them. We've actually got several of them, starting with SOCKS (which could have been extended), continuing through RSIP, on to midcom and SIMCO. Note that midcom was so named under the assumption that whatever was done would be extensible to other sorts of middleboxes than firewalls and NATs We could spend an awful lot of time talking about why none of them has caught on, but I think it's fair to say that that failure has not been caused by a perceived lack of generality. Maybe by a lack of simplicity? draft-woodyatt-ald-01 is a recent proposal. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: chicago IETF IPv6 connectivity
Your old one is 802.11B or G and you want G or N Your old one is IPv4 and you want IPv6. Does anybody believe that the transition to IPv6 at the edge is *NOT* going to require a complete replacement of gateway devices? Given that transitioning the Internet provider edge to IPv6 is going to result in a wholesale replacement of Internet gateway devices, shouldn't the IETF have some clear guidance on the capabilities of an IPv6 gateway? Such a device is not merely a router/switch, but also manages the site boundary (ULA addressing), probably should include firewalling with sensible defaults, and so on. And given that IPv6 is uncharted territory, wouldn't it make sense to specify that the software in an IPv6 gateway should be easily upgradeable? New technology washing machines use less water and power, destroy fewer clothes and clean better, but when was the last time you upgraded? Water, detergent and clothes have not changed as much as IPv6. In any case, at least one chain of stores in the UK advertises that they will take away your old appliance free if you order a new A-rated energy-saving appliance from them. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
The way I look at the problem we have a gateway issue similar to those that we used to have with smtp in the days of decnet sna etc. The only difference is that we have both sides of the gateway running IP albeit with different numbering schemes. So terminating the application session at layer 7 and then originating a fresh one at the point where the numbering scheme changes appears to me to be a simple and principled approach. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Hannes Tschofenig [mailto:[EMAIL PROTECTED] Sent: Monday, July 16, 2007 01:30 AM Pacific Standard Time To: Brian E Carpenter Cc: Melinda Shore; ietf@ietf.org Subject:Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition Hi Brian, regarding lack of simplicity: Different solutions build on different assumptions. If you make specific assumptions then the solution is much simpler. There is a recent document that aims to compare some of the NAT / firewall protocol proposals: http://www.ietf.org/internet-drafts/draft-eggert-middlebox-control-survey-01.txt It is not yet finished but might give you an idea what the different assumptions of some of the proposals are. Ciao Hannes Brian E Carpenter wrote: On 2007-07-14 00:07, Melinda Shore wrote: On 7/13/07 5:43 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I believe that we need a more general protocol for hosts inside a site perimeter to communicate with the perimeter gateways and request services from them. We've actually got several of them, starting with SOCKS (which could have been extended), continuing through RSIP, on to midcom and SIMCO. Note that midcom was so named under the assumption that whatever was done would be extensible to other sorts of middleboxes than firewalls and NATs We could spend an awful lot of time talking about why none of them has caught on, but I think it's fair to say that that failure has not been caused by a perceived lack of generality. Maybe by a lack of simplicity? draft-woodyatt-ald-01 is a recent proposal. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
Many SBC vendors would agree with your assessment. They would then add a list of the other advantages for putting application layer functionality into the network. The problems of this approach are, however, well-known. Hence, I would like to avoid them by decoupling the two interactions. Ciao Hannes Hallam-Baker, Phillip wrote: The way I look at the problem we have a gateway issue similar to those that we used to have with smtp in the days of decnet sna etc. The only difference is that we have both sides of the gateway running IP albeit with different numbering schemes. So terminating the application session at layer 7 and then originating a fresh one at the point where the numbering scheme changes appears to me to be a simple and principled approach. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Hannes Tschofenig [mailto:[EMAIL PROTECTED] Sent: Monday, July 16, 2007 01:30 AM Pacific Standard Time To: Brian E Carpenter Cc: Melinda Shore; ietf@ietf.org Subject:Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition Hi Brian, regarding lack of simplicity: Different solutions build on different assumptions. If you make specific assumptions then the solution is much simpler. There is a recent document that aims to compare some of the NAT / firewall protocol proposals: http://www.ietf.org/internet-drafts/draft-eggert-middlebox-control-survey-01.txt It is not yet finished but might give you an idea what the different assumptions of some of the proposals are. Ciao Hannes Brian E Carpenter wrote: On 2007-07-14 00:07, Melinda Shore wrote: On 7/13/07 5:43 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I believe that we need a more general protocol for hosts inside a site perimeter to communicate with the perimeter gateways and request services from them. We've actually got several of them, starting with SOCKS (which could have been extended), continuing through RSIP, on to midcom and SIMCO. Note that midcom was so named under the assumption that whatever was done would be extensible to other sorts of middleboxes than firewalls and NATs We could spend an awful lot of time talking about why none of them has caught on, but I think it's fair to say that that failure has not been caused by a perceived lack of generality. Maybe by a lack of simplicity? draft-woodyatt-ald-01 is a recent proposal. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
On 7/16/07 4:13 AM, Brian E Carpenter [EMAIL PROTECTED] wrote: Maybe by a lack of simplicity? Midcom and SIMCO are very simple. I think that there are a few problems, which taken in aggregate make NAT control a hard sell. One is that in even modestly complex networks either the application has to be aware of and make decisions about topology or that the traversal mechanism has to be aware of and make decisions about topology. I started the network-friendly midcom stuff (which turned into the NSIS nat and firewall work) because of that, but after having spent more time with it I really think it is not deployable in real networks, which we can talk about some other time. Another problem is the lack of naming and lookup facilities. DNS SRV records are probably going to be as good as it gets. VoIP protocols and others that make use of embedded addresses actually do have an advantage here, because they're able to transmit an acquired address in the application signaling. However, that won't help with servers, P2P, and so on. And, of course, there are heaps of political issues. Some of them are as crude as being about who controls what, but there are some more subtle ones around business models (the last time I talked about this Keith insisted that the IETF doesn't do business models, and I still encourage him to take a good look at what's going on in what's now the RAI area), as well, that shape the technical decisions that are made. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
On 7/16/07 6:29 AM, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: The way I look at the problem we have a gateway issue similar to those that we used to have with smtp in the days of decnet sna etc. Maybe, but there are differences that make it harder. Chief among these is that there were one or two gateways for CSNet, a handful for BITNET, and so on, and there was just the one application. Furthermore, there was no need to either modify the endpoint or inform the endpoint that it should gateway its email through a particular host. The latter was handled on the server. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
On Mon Jul 16 11:29:54 2007, Hallam-Baker, Phillip wrote: The way I look at the problem we have a gateway issue similar to those that we used to have with smtp in the days of decnet sna etc. The only difference is that we have both sides of the gateway running IP albeit with different numbering schemes. If I read this correctly, you're essentially stating that the Internet terminates at the ISP side of the NAT. So hosts located on the wrong side of the NAT are simply not part of the Internet - they merely happen to use the same technology. Is that a correct paraphrase of what you're saying? That does strikes me as a fundamental failing of NATs if so. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: take the train in Chicago
On Sun, Jul 15, 2007 at 03:55:39PM -, John Levine wrote: ... walk from the Palmer House unless it's raining really hard. ... If it's raining, So there's me thinking Chicago in July will be mid 80's sunshine, and you mention rain twice in one email :) -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: take the train in Chicago
So there's me thinking Chicago in July will be mid 80's sunshine, and you mention rain twice in one email :) You can get the occasional thunderstorm of tropical intensity. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: take the train in Chicago
When I look at the 10 day forecast for Chicago, 5 of the 10 days include some form of rain. But they agree with you about the temperature. Janet Tim Chown [EMAIL PROTECTED] wrote on 07/16/2007 09:58:35 AM: On Sun, Jul 15, 2007 at 03:55:39PM -, John Levine wrote: ... walk from the Palmer House unless it's raining really hard. ... If it's raining, So there's me thinking Chicago in July will be mid 80's sunshine, and you mention rain twice in one email :) -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
Melinda Shore wrote: On 7/16/07 6:29 AM, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: The way I look at the problem we have a gateway issue similar to those that we used to have with smtp in the days of decnet sna etc. Maybe, but there are differences that make it harder. Chief among these is that there were one or two gateways for CSNet, a handful for BITNET, and so on, and there was just the one application. Furthermore, there was no need to either modify the endpoint or inform the endpoint that it should gateway its email through a particular host. The latter was handled on the server. Widespread deployment of ALG's as mediators means you have to upgrade the network to support new applications. or applications are built on top of hostile tunnels over your alg infrastructure (sound familiar?). While some enterprise networks seem to favor this, it's not really the Internet. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
On 7/16/07 10:43 AM, Joel Jaeggli [EMAIL PROTECTED] wrote: Widespread deployment of ALG's as mediators means you have to upgrade the network to support new applications. or applications are built on top of hostile tunnels over your alg infrastructure (sound familiar?). While some enterprise networks seem to favor this, it's not really the Internet. At some point a lot of these things tend to look awfully similar to one another (NATs look like tunnel endpoints look like relays, etc.) but they tend to break out into broad categories. So, you have some mechanisms that operate at the network layer and some that operate at the session or application layer. The lower in the stack they sit the more general they can be, clearly, but then you tend to encounter more problems around reachability and findability. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: take the train in Chicago
On Monday, 16 July 2007, Janet P Gunn wrote: When I look at the 10 day forecast for Chicago, 5 of the 10 days include some form of rain. But they agree with you about the temperature. Janet As a Chicagoan I can assure you that any forecast beyond the next 12 hours is useless. Of course, having just said that, watch those forecasts turn out to be accurate for the first time this century. Kyle ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
So terminating the application session at layer 7 and then originating a fresh one at the point where the numbering scheme changes appears to me to be a simple and principled approach. There are two ways I can read this, and I suspect I've got them both wrong. The first is the flag day meaning for where the numbering scheme changes--that is, re-deploy all applications on some day at which we decide the numbering scheme changes. The second is that you mean that any device which serves as an intersection point between v4 and v6 must also serve as a back-to-back user agent for all applications that run across it. That is, for the scenario v6-endpoint---[boundary]--v4 segment---[boundary]--v6-endpoint there would be a full-on termination of the application at each boundary, and a new application flow, which is itself not guaranteed to reach the original destination of the flow. Is either of those what you meant? If not, can you clarify? thanks, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: take the train in Chicago
[EMAIL PROTECTED] wrote: As a Chicagoan I can assure you that any forecast beyond the next 12 hours is useless. Just like a typical Chicagoan. Ridiculously optimistic about the weather. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Jun-ichiro itojun Hagino wrote: that I personally use? I'm guessing about a half-dozen, though I don't use them all everyday. some other apps work across NAT but with degraded functionality. okay. if you could name them we can try to convince people who are responsible. the people responsible for polluting the network with NATs? it's too late to punish them, I fear :) no, the people who have implemented your applications that are written in IPv4-only and NAT-unfriendly, to be IPv4/v6 bilingual. i do not care about NAT (un)friendliness, i just need it to support IPv6. you have it backwards. It is the NATs that are unfriendly to apps, not the other way around. it's easy to write a distributed app that can handle the case where all nodes are IPv4, or the case where all nodes are IPv6. it is much more difficult to write such an app that can handle the case where some nodes are IPv4, some are IPv6, some are both, and there is a need to communicate between arbitrary pairs of nodes within the app and to allow some nodes to do referrals to other nodes. DNS names are not a good way to solve this problem for reasons of performance and reliability and because a DNS name does not, in practice, uniquely bind to a particular host. we kame are guilty for almost every application IPv6 support, including Python, Apache, Ruby, Postfix (wietse rewrote the whole thing), all tools on *BSD, BSD libc, whatever. honestly noone can beat us on this topic:-P and the rest of us are very appreciative! of course, not all of the applications that people use are those that are shipped with *BSD. and while it's quite helpful if programming languages support IPv6, that doesn't mean that the programs written in those languages will automatically work with IPv6. well, that depends on what kind of programming language you will be using. Python uses a model where you explicitly need to invoke bind(2) and getaddrinfo(3), so the programmer has to be knowledgeable enough to handle IPv4/v6 stuff. iirc Ruby TCPSocket class embeds all the details about getaddrinfo(3) loop within the class/instance method, so you do not have to care about which IP version is in use. it is not reasonable to assume that for all apps the correct model is to do a DNS lookup and then try the resulting IP addresses one at a time until a connection succeeds for one of them. that, and getaddrinfo() is broken in a great many ways: it isn't tied to DNS (so if your app is defined to use DNS then you can't trust getaddrinfo() to do what your app needs); even if the implementation does use DNS, getaddrinfo() can only do A and queries, it's not asynchronous, and the whole idea that a host stack can select a source/destination address pair by trial-and-error and get good results within a reasonable time is, quite frankly, a joke. so, which is your real-world protocol which has the above problem? or is it a theoretical debate? code then spec. no, it's not a theoretical debate. I worked with a number of distributed systems: PVM, some MPI implementations, and one of my own design that didn't become so popular. There are a lot of applications layered on top of one or the other of these. But unless you're into high-performance computing you probably aren't aware of them. may i talk with you/designer of PVM/MPI code so that they can implement them in IPv6-friendly manner? privately. I don't work there any more, and none of the people whom I knew that worked on those codes work there any more either. one way is to have a session-layer protocol (finally!). or, you can switch from TCP to SCTP. for several reasons, SCTP is not a drop-in replacement for TCP. (but I'd love to see further development and standardization of multipath TCP - that seems like a very promising avenue) there were tons of multipath TCP drafts, but there's no real authentication so all of them failed badly. so i see some future in ssh. ssh is not a bad protocol, but it doesn't solve the multiple-addresses-per-host problem, even if you change it to allow peers to re-connect (which would be a nice feature). please tell me, your apps are totally multicast or broadcast? if not, we need to solve 2-nodes communication first, then you can solve communication among n (n could be very big) nodes. this isn't a multicast or broadcast problem I'm speaking of. I'm speaking of the need for the network to provide complete connectivity between arbitrary pairs of nodes in a distributed system. you have to. you cannot be that lazy. our goal in IETF should be to allow programmers to be that lazy. separation of function between the host and the network is a Good Thing. let the hosts exchange packets and
[OT] DNS test of validity of a claim ROOT fracture
I'm looking to see if the european isp tiscalli and the country of turkey (ISPs) are no longer resolving using the iana root servers. According to the UnifiedRoot, a private company in the netherlands they provide resolution services to both the country and the isp. I need help to test to see if they still reolve the UnifiedRoot root zone file. If you use a turkish isp or the european tiscalli isp you can help by letting me know if the following urls resolve. Can you click on ? http://meijburg.kpmg/ http://philip-stein.horloges/ http://parking.schiphol/ Also any ideas what groups i can go to to find people located in those service areas. much thanks joe baptista -- Joe Baptistawww.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (202) 517-1593 Fax: +1 (509) 479-0084 begin:vcard fn:Joe Baptista n:Baptista;Joe org:PublicRoot Consortium adr:;;963 Ford Street;Peterborough;Ontario;K9J 5V5 ;Canada email;internet:[EMAIL PROTECTED] title:PublicRoot Representative tel;fax:+1 (509) 479-0084 tel;cell:+1 (416) 912-6551 x-mozilla-html:FALSE url:http://www.publicroot.org version:2.1 end:vcard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
i guess we are living with very different assumptions. no, the people who have implemented your applications that are written in IPv4-only and NAT-unfriendly, to be IPv4/v6 bilingual. i do not care about NAT (un)friendliness, i just need it to support IPv6. you have it backwards. It is the NATs that are unfriendly to apps, not the other way around. i guess we agree on this point, but recent IETF documents got it backwards so i worded it the way presented in the above. it's easy to write a distributed app that can handle the case where all nodes are IPv4, or the case where all nodes are IPv6. it is much more difficult to write such an app that can handle the case where some nodes are IPv4, some are IPv6, some are both, and there is a need to communicate between arbitrary pairs of nodes within the app and to allow some nodes to do referrals to other nodes. DNS names are not a good way to solve this problem for reasons of performance and reliability and because a DNS name does not, in practice, uniquely bind to a particular host. sorry, you are, too lazy. remember the days when we had bitnet, decnet and compuserve (niftyserve in japan) in email world. we had a lot of technologies, or tricks i would say, to make emails get delivered from/to arbitrary networks. in this analogy, IPv4 is bitnet/decnet/compuserve and IPv6 is the Internet. of course. well, that depends on what kind of programming language you will be using. Python uses a model where you explicitly need to invoke bind(2) and getaddrinfo(3), so the programmer has to be knowledgeable enough to handle IPv4/v6 stuff. iirc Ruby TCPSocket class embeds all the details about getaddrinfo(3) loop within the class/instance method, so you do not have to care about which IP version is in use. it is not reasonable to assume that for all apps the correct model is to do a DNS lookup and then try the resulting IP addresses one at a time until a connection succeeds for one of them. without giving out the details of your correct model we cannot discuss. go by mathematical rules, first you give me axioms and then we talk about your theories. do not call theories a fact or correct model because we cannot define them. that, and getaddrinfo() is broken in a great many ways: it isn't tied to DNS (so if your app is defined to use DNS then you can't trust getaddrinfo() to do what your app needs); even if the implementation does use DNS, getaddrinfo() can only do A and queries, it's not asynchronous, if you want PTR, MX and NS records, use res_send and stuff. use getnameinfo NI_NAMEREQD and getaddrinfo AI_NUMERICHOST if you want DNS resolution to happen for certain. and the whole idea that a host stack can select a source/destination address pair by trial-and-error and get good results within a reasonable time is, quite frankly, a joke. we agree on this point. i'm having trouble understaing the entire source address selection stuff. it won't get deployed nor properly managed. may i talk with you/designer of PVM/MPI code so that they can implement them in IPv6-friendly manner? privately. I don't work there any more, and none of the people whom I knew that worked on those codes work there any more either. ok, you need bump-in-the-stack (hitachi) or bump-in-the-library (erik nordmark/sun microsystems). there were tons of multipath TCP drafts, but there's no real authentication so all of them failed badly. so i see some future in ssh. ssh is not a bad protocol, but it doesn't solve the multiple-addresses-per-host problem, even if you change it to allow peers to re-connect (which would be a nice feature). what is the problem you have with multiple-addresses-per-host problem? i never had any problem even with IPv4. please tell me, your apps are totally multicast or broadcast? if not, we need to solve 2-nodes communication first, then you can solve communication among n (n could be very big) nodes. this isn't a multicast or broadcast problem I'm speaking of. I'm speaking of the need for the network to provide complete connectivity between arbitrary pairs of nodes in a distributed system. describe what is complete connectivity in your definition. are you talking about QoS? then use vendor libraries that are URL-based. my, you have a simplistic view of the application world! you did not give me the details, so i have to guessing. the last note. i guess i have a clear idea about how to make Skype dual stack. current Skype protocol is totally IPv4-only (see silver needle in skype paper), but i can make it dual stack, i mean, mixture of
Re: secdir review of draft-ietf-dkim-ssp-requirements-04
On Jul 16, 2007, at 2:27 PM, David Harrington wrote: Don't overlook 5.1 #1: --- The author is the first-party sender of a message, as specified in the [rfc2822].From field. --- Per RFC2822: --- 3.6.2. Originator fields ... The From: field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The Sender: field specifies the mailbox of the agent responsible for the actual transmission of the message. --- The From: field does not actually refer to who sent the message. Here 'sender' is being used in poorly defined fashion. This field refers to originators of the message, and specifically _not_ the sender. Even the Sender: field does not directly indicate who administers the SMTP client physically transmitting the message. Here the term Author's domain is considered to include any parent domain extending all the way up to TLDs. Don't overlook 5.1 #3 resource record location prohibition. It is very common for different protocol's RRs to reside at a common location. These records are resolved by different RR types. Why was this statement incorrectly worded? 2) section 5.1, bullet #4 says the WG might not be able to reach a consensus on a solution that completes within a deterministic number of steps, and if they do not reach consensus, then they MUST document the relevant security considerations. Even if they DO reach consensus, they will need to document the security considerations. I'm not sure how they will document the security considerations of not reaching consensus. I think there are range of topics mixed into bullet#4, and they need to be broken out before security for these things can be considered. This requirement is for an uncertain concept that DNS can safely establish policy in a hierarchal fashion. It is uncertain whether this can be accomplished within a reasonable number of transactions without also creating a potential for DDoS attack. This uncertainty is further exacerbated by there not being any safe existing hierarchal email policy structures within DNS. Absence of policy records is normal for existing email. It would be possible to establish policy in conjunction with SMTP discovery RRs required to support the email-address domain in question. This approach precludes a need to extend SSP coverage into subdomains, or a need to traverse domains searching for parent domain's SSP records. A strategy that depends upon a policy hierarchy is sure create dangerously excessive traffic at second level domains, and result in possible DDoS exploits. 3) section 5.3 bullet #2 calls for a concise linkage between the identity in the From field and the DKIM i= tag. Isn't the concise linkage that you need here some type of identity authentication? If not, how do you know the mapping is actually valid? This is made worse by a lack of clarity with respect to 5.1 #1 and goes to the heart of a major security problem. It is a normal practice to employ email service providers who transmit messages from domains independent of the email-address domain signed by a DKIM header. Per-users keys will call into question the caching ability of DNS. Domain centric keys will preclude an architecture where messages are normally signed prior to submission. So how can an email-address authoritatively be signed to convey assurances to recipients? This can be done by: 1) an authorization-by-name RR in DNS at SMTP discovery RRs (A concept currently excluded from consideration.) 2) an ad-hoc exchange of keys between domains 3) delegation of key domain to email providers Both methods 2 3 lead to a rather serious difficulty when attempting to resolve the messages at risk of having been spoofed when a provider's server has been compromised. Instead of reporting the domain of the provider as being compromised, method 2 3 requires a comprehensive list of perhaps thousands of a provider's customer's domains will need to be reported instead. Private keys will be distributed to servers directly connected to the Internet, where of course there is a high risk keys may become compromised. 4) security requirement#1 - What must SSP do to prevent such DoS attacks? what must SSP do to prevent being vulnerable to such DoS attacks? Note that these are two separate questions with potentially different mitigation strategies. Not attempting to establish a hierarchal policy within a domain should be the first step to assure against DDoS risks. Instead limit policy to SMTP discovery RRs locations instead. Unfortunately, the SSP requirements draft anticipates use of hierarchal policy instead, hence what may appear to be double-speak. 5) security requirement#2 - what must SSP do to prevent such attacks? Keeping exchanges small might help, but how about establishing a secure channel, and using data
Re: chicago IETF IPv6 connectivity
i guess we are living with very different assumptions. it's just that the needs of applications vary as widely as the needs of users. it's not as if all Internet users do nothing but email and the web, and neither is it as if all Internet applications are like HTTP or ssh. if you are not under NDA, could you please be more specific? source code, RFC/draft for the protocol, whatever? i'm getting tired of this guessing games. sorry, you are, too lazy. remember the days when we had bitnet, decnet and compuserve (niftyserve in japan) in email world. we had a lot of technologies, or tricks i would say, to make emails get delivered from/to arbitrary networks. in this analogy, IPv4 is bitnet/decnet/compuserve and IPv6 is the Internet. of course. yes, I remember those, and I also remember the problems we had trying to make all of that work well - in particular, the problem of rewriting addresses so that the mail would still be replyable after it crossed multiple gateway boundaries. (actually I wrote a thesis on the topic). I'm sure my experience with email addressing and gateways is part of why I could see the problems with NAT earlier than most people. of course, it's not as if every application in the v4/v6 world is like email. at least some of those email protocols were designed to be store-and-forward and to allow email to be transmitted across networks without end-to-end connectivity.store-and-forward isn't appropriate for every applications protocol. (and I'd even argue that it probably shouldn't be used for email anymore, at least not in the way that SMTP currently does it, because it's really hard to arrange for errors to be reliably reported to the party that needs to know about them.) well, i'm sure there still are instances of Lotus Notes running in ancient enterprises. once you run ALG (which i guess you do not like) IPv6-to-IPv4 or IPv4-to- IPv6 looks much like SMTP relaying. if you could give v6ops people your comments from your experiences, it would be helpful. i know we have been trying and tired to death, but this year is THE right time. without giving out the details of your correct model we cannot discuss. go by mathematical rules, first you give me axioms and then we talk about your theories. do not call theories a fact or correct model because we cannot define them. I don't think there is a single correct model for all apps that works in a network where hosts have multiple addresses and the performance can vary significantly depending on which address pair you choose. yup, there's no single truth. we agree on that. ideally, from the application's point-of-view, the network would always perform well enough to suit the needs of the application and it wouldn't matter which source and destination address were used. also, any address would be reachable from any point in the network. the traditional IPv4 network approximately fulfilled both conditions; the current IPv4 network with NATs still mostly fulfills the first one. having multiple addresses per host/network be the normal case in IPv6 threatens to remove the first condition, and having a mixed v4/v6 network nixes the second one. if you want PTR, MX and NS records, use res_send and stuff. use getnameinfo NI_NAMEREQD and getaddrinfo AI_NUMERICHOST if you want DNS resolution to happen for certain. I don't recall that this guaranteed by the API specification. do not underestimate my paranoid-ness, i'm an OpenBSD developer, and i'm proud of it! i've met both Steve Mann and Richard Stallman face to face, though i don't think they remember me. - getaddrinfo/getnameinfo standards do not say a thing about DNS lookup so you cannot trust it. of course if analyze the source code, you may. - res_send/res_query are not a standard so the behavior is not defined in documents. of course if analyze the source code, you may. - even if you write code that plays with UDP/TCP socket, you are unsure if there's any tricks inside OS kernel, like host firewall blocking or rewriting your queries/responses. of course if analyze the source code, you may. - even if you trust your OS kernel, you cannot trust your router, especially when it implements NAT and you are using it with NAT disabled. of course if analyze the source code, you may, but the likelyhood of getting source code is rather low. - even if you trust your router, you would not be able to trust your ISP, or peering ISPs. now it became impossible to look at source code, and/or configuration of all the routers. - even if you trust your L3 stuff, you cannot trust DNS trees.
IAOC Scribes
All, The IAOC minutes are posted, whenever available, at http:// iaoc.ietf.org/minutes.html. Since the days of the IASA transition team, Marshall Eubanks has acted alone as the scribe for the IAOC. On behalf of the IAOC I would like to take this opportunity to thank Marshall for the extraordinary work he has done and the dedication he has showed since the IASA-TT days! In order to off-load Marshall the IAOC now would like to recruit a second scribe for it's meetings. Volunteers should write to [EMAIL PROTECTED] by July 20th. We'll keep names confidential, unless people choose to volunteer in public. The general guidelines are: - at least one scribe attends the regular IAOC and IETF Trust telechats (10:00-11:00 US ET on 1st and 3rd Thursdays of the month). - the scribe(s) will record narrative minutes of the discussions, but they will not take part in the discussions except to ask for clarifications. - Minutes are expected to be approved by the IAOC at the next scheduled meeting. - kurtis - IAOC chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
