Re: draft-ietf-nat-protocol-complications-02.txt
At 05:38 PM 4/21/2000 -0400, Keith Moore wrote: >doesn't this require the NAT to use the same inside<->outside address >binding for the connection between the client and the KDC as for >the connection between the client and the application server? >e.g. it seems like the NAT could easily change address bindings >during the lifetime of a ticket. Yup, so far I have always been able to work around this by opening up an SSL IMAP connection to remote server to stablize the address while I need to do other work. Oh the fun games we encounter when mixing security and NATs :) Paul
Re: draft-ietf-nat-protocol-complications-02.txt
> > doesn't this require the NAT to use the same inside<->outside > > address binding for the connection between the client and the KDC as > > for the connection between the client and the application server? > > e.g. it seems like the NAT could easily change address bindings > > during the lifetime of a ticket. > > True. However, the same problem applies without NAT if the client > changes address bindings, granted, but how often do clients change address bindings in practice? > so I wouldn't say this is really a NAT-related problem. of course it's a NAT-related problem, in the sense that if you have a NAT box and want to use Kerberos you are highly likely to observe the problem. for almost every kind of harm that NATs do to applications you can find some other means of causing the same problem. but just because the problem can be caused by other things doesn't mean it's not related to NATs. Keith
Re: draft-ietf-nat-protocol-complications-02.txt
> > doesn't this require the NAT to use the same inside<->outside > > address binding for the connection between the client and the KDC as > > for the connection between the client and the application server? > > e.g. it seems like the NAT could easily change address bindings > > during the lifetime of a ticket. > > True. However, the same problem applies without NAT if the client > changes address bindings, so I wouldn't say this is really a > NAT-related problem. > Under what conditions transparent to the user does a client change address bindings? Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
Re: Universal Network Language
At 11:01 PM 4/20/00 +0200, Anders Feder wrote: >The translation system being developed for the United Nations, the Universal >Network Language (UNL), looks quite promising. Does the IETF have any plans >regarding this system? not specifically. Care to make an argument that we should?
Re: draft-ietf-nat-protocol-complications-02.txt
> doesn't this require the NAT to use the same inside<->outside > address binding for the connection between the client and the KDC as > for the connection between the client and the application server? > e.g. it seems like the NAT could easily change address bindings > during the lifetime of a ticket. True. However, the same problem applies without NAT if the client changes address bindings, so I wouldn't say this is really a NAT-related problem.
Re: draft-ietf-nat-protocol-complications-02.txt
> doesn't this require the NAT to use the same inside<->outside address > binding for the connection between the client and the KDC as for > the connection between the client and the application server? > e.g. it seems like the NAT could easily change address bindings > during the lifetime of a ticket. Correct. I think Greg was thinking only of NATs which share a single global address among multiple clients on a private network... - Bill
Re: draft-ietf-nat-protocol-complications-02.txt
> In Kerberos 4, when the KDC receives a ticket request, it includes the > source IP address in the returned ticket. This works fine if the KDC > is across a NAT gateway, as long as all of the Kerberos services are > also across a NAT gateway. doesn't this require the NAT to use the same inside<->outside address binding for the connection between the client and the KDC as for the connection between the client and the application server? e.g. it seems like the NAT could easily change address bindings during the lifetime of a ticket. Keith
RE: Digital Radio Configuration Question
John, I called it the "Limited Broadcast Address" because that is what Richard Stevens calls it in his book, "TCP/IP Illustrated Volume 1", which I had thought was considered the BIBLE amongst networking professionals. Secondly, I am aware that no router in the world forwards this address. It says so in the book, and it would be rediculous to do so in the first place. My problem relates to obtaining the IP address of a digital radio which is connected to the same physical network as the host, but which you do not know it's IP address. You have no other means of finding out its IP address, i.e. no look inside the box. It does support SNMP, however you need an IP address to read its configuration. Hence, the thought about using the limited broadcast address and an ICMP Echo Request message. As for VxWorks being cautious, no I think it is more of an oversight on their part. I'll have to ask them why Thanks, Rick. -Original Message- From: John Stracke [SMTP:[EMAIL PROTECTED]] Sent: Friday, April 21, 2000 11:36 AM To: [EMAIL PROTECTED] Subject:Re: Digital Radio Configuration Question "Richard C. Ascheri" wrote: > I wrote a simple program that sends an ICMP Echo Request message to the > limited broadcast address of 255.255.255.255. That's not the limited broadcast address; that's the universal broadcast address, the one that would send a packet to every host in the Internet. I say "would" because it's such an obviously bad idea that essentially every router in the world comes out of the box refusing to forward it. Most host software will respond to it, though; VxWorks is probably being cautious. -- /==\ |John Stracke| http://www.ecal.com |My opinions are my own.| |Chief Scientist |=| |eCal Corp. |Do not suspect that I am not human. | |[EMAIL PROTECTED]| | \==/
Re: SNMPv3 deployment & Wind River Systems
This note is simply to update the record. As the whole discussion is dealing with a single vendor followups should probably be taken off-line. Anyway, the port of Envoy and SNMPv3 to VxWorks is in the hands of the manufacturing and shipping department and should be shipped to customers shortly (next week or so). Envoy with SNMPv3 was released on pSOS somewhat over a year ago. regards, Shawn A. Routhier Epilogue, Integrated Systems (pSOS), WindRiver (VxWorks) Hi, Lack of SNMPv3 availability in networking products is a serious operational problem in the Internet today, IMHO. A large number of networking vendors are telling @Home that the vendor has difficulty in offering SNMPv3 because WindRiver won't take the Epilogue SNMP Agent software (Epilogue is now owned by WindRiver so that code would be the obvious choice) and port it across to VxWorks (and for that matter, PSOS). VxWorks and PSOS are only available with a SNMPv1/v2c agent even today, with no prospect for SNMPv3 anytime soon. While theoretically anyone could port the code, in practice a lot of the affected companies aren't big enough to have that amount of extra staff lying around. By the way, this also means there is a market for a pre-ported (to VxWorks/PSOS) version of any other SNMP code, if someone is feeling like a capitalist. If anyone here has the ear of anyone in management at WindRiver Systems, it would be a public service to push them to get an SNMPv3 agent available to their VxWorks customers ASAP. The downstream customer demand exists. Sorry for the interruption and thanks for listening. Ran [EMAIL PROTECTED]
RE: SNMPv3 deployment & Wind River Systems
The facts, as stated, are simply not true. SNMPv3 is ported and supported for both VxWorks and pSOS+. Prior to the merger of Wind River and Integrated Systems (which owned Epilogue), there was no SNMPv3 solution for VxWorks. But it is available today. SNMPv3 has been available for pSOS+ for as long as Epilogue had an SNMPv3 solution (about 18 months now). Robb Swanson voice : 781-643-5222 Field Engineering Specialist fax : 781-643-5225 Wind River www : http://www.windriver.com > -Original Message- > From: RJ Atkinson [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 21, 2000 4:32 AM > To: ietf > Subject: SNMPv3 deployment & Wind River Systems > > > Hi, > > Lack of SNMPv3 availability in networking products is a serious > operational problem in the Internet today, IMHO. > > A large number of networking vendors are telling @Home that the > vendor has difficulty in offering SNMPv3 because WindRiver > won't take the > Epilogue SNMP Agent software (Epilogue is now owned by WindRiver > so that code would be the obvious choice) and port it across > to VxWorks > (and for that matter, PSOS). VxWorks and PSOS are only > available with > a SNMPv1/v2c agent even today, with no prospect for SNMPv3 > anytime soon. > > While theoretically anyone could port the code, in > practice a lot > of the affected companies aren't big enough to have that > amount of extra staff > lying around. By the way, this also means there is a market for > a pre-ported (to VxWorks/PSOS) version of any other SNMP > code, if someone > is feeling like a capitalist. > > If anyone here has the ear of anyone in management at > WindRiver Systems, > it would be a public service to push them to get an SNMPv3 > agent available to > their VxWorks customers ASAP. The downstream customer demand exists. > > Sorry for the interruption and thanks for listening. > > Ran > [EMAIL PROTECTED] > > >
Re: draft-ietf-nat-protocol-complications-02.txt
I'd like to make some clarifications about Kerberos and NAT. >> When AUTH is used with Kerberos 4 and Kerberos 5 there are issues >> related to the IP addresses which are embedded into the Kerberos >> tickets which specify the valid machines from which the tickets are >> valid. > Are you saying that IP address of the senders is always embedded in > the kerberos-4 tickets? In Kerberos 4, when the KDC receives a ticket request, it includes the source IP address in the returned ticket. This works fine if the KDC is across a NAT gateway, as long as all of the Kerberos services are also across a NAT gateway. In Kerberos 5, the client specifies a list of IP addresses which the ticket should be valid for, or it can ask for a ticket valid for all IP addresses. By asking for an all-IP-addresses ticket or a ticket containing the NAT gateway address, you can get krb5 to work with a NAT gateway, although it isn't very transparent (it requires the clients to behave differently than they otherwise would). The MIT krb5 1.0 implementation didn't have any configurability for what IP addresses the client asked for (it always asked for the set of its interface addresses) and did not interact well with NAT. The MIT krb5 1.1 implementation allows you to put "noaddresses" somewhere in krb5.conf to request all-IP-addresses-valid tickets. Not all Kerberos 4 or 5 services actually check source IP addresses. (I don't have a list of common Kerberos services which do or do not check source IP addresses, unfortunately. AFS is a good example of a Kerberos 4 service which does not.) Services which don't check are obviously not picky about NAT gateways. There are, of course, a substantial number of people who believe that Kerberos source IP address checking is not worth the trouble, since it is not a central part of the Kerberos security model. (Basically, it means if someone steals Kerberos tickets, they can't use them from a different IP address unless they can forge the source IP address or use services which don't check.)
RE: Digital Radio Configuration Question
I'm trying to announce to the host connected to the Ethernet interface. Yes the digital radio does have other interfaces, but I believe that only one type of interface (ethernet or PPP) will be active at any one time, i.e. we won't have the PPP interface working at the same time as the Ethernet. At least that is not the plan so far. To bring you up to date: I started down the path of using the Limited Broadcast address and an ICMP Echo Request message to get the Digital Radio to announce it's IP address. I wrote a simple program that sends an ICMP Echo Request message to the limited broadcast address of 255.255.255.255. This appeared to work when testing it with many of the hosts on our network, i.e. numerous hosts responded with their own IP address... However, the digital radio does NOT respond because the VxWorks operating system apparently doesn't support answering the limited broadcast address...(The documentation suggests that you have to set the broadcast address for the interface, and 255.255.255.255 is illegal). So that method looks like a dead end. That was going to be the easiest and the cleanest. The next method I plan to try is to use a Multicast address to exchange maybe an ICMP Echo Request message (or some other message) with one another. First idea is to identify a Multicast address to use to do this. I want to try and use one of the predefined multicast addresses. Any suggestions from anyone as to which one might be appropriate for this kind of thing? If the above methods fail then my final attempt will be to implement a minimum Service Location Protocol V2 Implementation in the digital radio, and have it announce some kind of configuration service. The host could then look for this configuration service and get the information it needs from the SLP messages. The thing I like about this method is that it is a standard RFC, and I can later expand on the other services that I might want the digital radio to announce. Any other suggestions would be greatly appreciated. Thanks in advance, Rick. -Original Message- From: Michael B. Bellopede [SMTP:[EMAIL PROTECTED]] Sent: Friday, April 21, 2000 7:20 AM To: Richard C. Ascheri Subject:RE: Digital Radio Configuration Question If you have more than one physical interface, each with its own IP, than this device definitely is considered a router. Are you trying to announce the IP of the ethernet interface to the connected ethernet host (via ethernet interface), or announce to a host communicating with the radio interface? -Michael B. Bellopede [EMAIL PROTECTED] "There is no spoon." -Original Message- From: Richard C. Ascheri [mailto:[EMAIL PROTECTED]] Sent: Monday, April 17, 2000 1:32 PM To: '[EMAIL PROTECTED]' Subject: Digital Radio Configuration Question Hello, I'm a Systems Engineer at Raytheon Company. I have been working on the development of a digital IP based radio for some time now. The radio has an Ethernet interface, PPP interface, and an ADDSI X.25 interface. My question relates to the configuration of the radio. To configure the radio we have an implementation of SNMPv2. This implementation allows the radio to be configured over the Ethernet or PPP interfaces using the SNMPv2 protocol. My question relates to configuring the radio without knowing it's IP address. I understand that SNMP requires the IP address of the device you want to configure. I am interested in a standard method of announcing the IP address of the Ethernet interface. This would allow a configuration tool to look for the announcements and then send SNMP configuration messages to modify the radios configuration. For this scenario you can assume that the radio will be attached to a single host over an Ethernet interface. There will be no other hosts or radios on the network. Assume that the IP address of the radio is NOT known. It could be set to anything, even an address outside of the range of the hosts subnet. I have looked at a number of RFC's but have found these two that may work: RFC 1256 - ICMP Router Discovery. This rfc does announce the IP address, however, for this scenario I'm not interested in saying that this radio is the next hop gateway. Given that the radio has numerous interfaces and an TCP/IP stack you might consider this a router. However, I don't really feel that this RFC directly relates to solving the configuration problem. The host is not really looking for it's next hop gateway. It's looking for devices that can be configured through SNMP. RFC 2608 - Service Location Protocol v2. This rfc does imply that I could create a "Configuration-Service" and announce its availability using the SNMP protocol. This actually sounds like the right kind of solution to my problem. But now I'm wondering whether or not there is something else that I haven't found. Maybe something in the works, as a draft, or a working group that is responsible for lookin
SNMPv3 deployment & Wind River Systems
Hi, Lack of SNMPv3 availability in networking products is a serious operational problem in the Internet today, IMHO. A large number of networking vendors are telling @Home that the vendor has difficulty in offering SNMPv3 because WindRiver won't take the Epilogue SNMP Agent software (Epilogue is now owned by WindRiver so that code would be the obvious choice) and port it across to VxWorks (and for that matter, PSOS). VxWorks and PSOS are only available with a SNMPv1/v2c agent even today, with no prospect for SNMPv3 anytime soon. While theoretically anyone could port the code, in practice a lot of the affected companies aren't big enough to have that amount of extra staff lying around. By the way, this also means there is a market for a pre-ported (to VxWorks/PSOS) version of any other SNMP code, if someone is feeling like a capitalist. If anyone here has the ear of anyone in management at WindRiver Systems, it would be a public service to push them to get an SNMPv3 agent available to their VxWorks customers ASAP. The downstream customer demand exists. Sorry for the interruption and thanks for listening. Ran [EMAIL PROTECTED]
Re: draft-ietf-nat-protocol-complications-02.txt
I have so many issues with this reply that I am only going to focus on one. > Agreed. How do you expect the intruders will steal the tickets, without > being recipients of the ticket? Unless, you are assuming that the private > network is not trusted and that there are intruders within the private > network. There is no such thing as a trusted network. One of the first things you learn about security (having nothing to do with computer security) is that most attacks occur from inside the organization. There is no such thing as a trusted network. I have pointed you in directions you need to follow. Stating that the a problem in one context is described in the described in another context is not useful in this document. It is exactly because of this approach that the document comes across sounding as if the problems described are trivial and inconsequential. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
The RFC-Editor and IANA (part II)
Quoted from another thread: However, we believe that there is a fairly general understanding among IAB, ICANN, and US DoC that the IAB could, indeed, transfer the portions of the IANA efforts that relate to IETF work elsewhere if that were necessary or desirable. I like this bold statement very much, and I believe that this is the way that the IAB should go! And, I assume that it was not a humorous intentional. It is still not clear, however, why both IANA and the RFC-Editor have never explicitly acknowledged that they were chartered by the IAB. If the funding of the RFC Editor function is $1,295,517 and it produces 1300 RFCs, the production cost of one RFC will be about $1000. This is equivalent to 10 third world man month. No complain, since this is funded by Uncle Sam's tax payers or its derivative. (Unfortunately, parts of ICANN and regional *NIC registries funds will come from the third world). References: * http://ittf.vlsm.org/ietf/164.txt * http://ittf.vlsm.org/ietf/00/1.txt * http://gtm.vlsm.org/in-i-iana1.html -- - Rahmat M. Samik-Ibrahim -- VLSM-TJT -- http://rms46.vlsm.org/ - - You have to let me go, I just wanna tell you! - 5IVE INVINCIBLE -
Re: draft-ietf-nat-protocol-complications-02.txt
--- Jeffrey Altman <[EMAIL PROTECTED]> wrote: > This draft is very incomplete and in my opinion not ready for prime > time. The working group has in the past requested lists of protocols > and applications which do not work with NATs. I have replied > discussing those items for which I am most familiar: Hmm.. I do not recall seeing your e-mail on this matter before. I dont know how we could have lost it. Anyways, sorry about that. <... stuff deleted> > > > Telnet: > > Transmits IP addresses from the client to the server for the purposes > of setting the DISPLAY variable. When set the DISPLAY variable is > used for subsequent connections from X clients on the host to an > X server on the workstation. > Agreed, if you use IP address of the X-server, instead of DNS name (in the case of Basic-NAT en-route). In the case of NAPT enroute, it is a non-issue, as you would have used just the IP address of the NAPT device, right? We covered this in section 3.1, but not in the context of telnet (X-Windows client). Good point. > When AUTH is used with Kerberos 4 and Kerberos 5 there are issues > related to the IP addresses which are embedded into the Kerberos > tickets which specify the valid machines from which the tickets are > valid. > Are you saying that IP address of the senders is always embedded in the kerberos-4 tickets? Section 6 attempts to state that any application that has private IP address in the payload and its payload secured (and NAT is not party to the security key) cannot traverse NAT device. We can certainly include this application there. Section 8.1 of RFC 2663 also talks about NAT limitations with regards to applications with IP address content(especially, encrypted/authenticated) > When START_TLS is used there may be client certificate verification > problems caused by the NAT depending on the information provided in > the certificate. > Agreed. Same comment as before. > FTP: > > As stated FTP, uses multiple sessions. But what it fails to state > is that if any form of PROT is used to secure the command channel > then it is impossible to implement an ALG to perform IP Address swaps. > Agreed. Will add text to clarify this. > When AUTH is used with Kerberos 4, Kerberos 5, and TLS the same > problems that occur with Telnet occur with FTP. > I guess, you are talking about sending IP address data encrypted from a telnet station. Please elaborate, if I am missing something. > RSH/RLOGIN: > > RSH uses multiple sessions to support separate streams for stdout and > stderr. The stderr socket is a connection from the server to the > client. And unlike FTP, there is no equivalent to PASV mode. > Are you saying that there is a problem when a private host does rsh into an external server? If so, can stderr be directed to the client-host by name, as opposed to IP-address? I donot know much about the inner-working of "rsh" to state whether it can work with a NAPT device between client and server. > RLOGIN does not use multiple sessions. What is the problem here? > > But the Kerberos protoected versions of RSH and RLOGIN will not work > in a NAT environment due to the ticket problems and the use of > multiple sessions. > What is the issue with multiple sessions? Are you refering to one of the sessions being redirected to the originator by address? > Kerberos 4: > > Kerberos 4 tickets are encrypted. Therefore, an ALG cannot be > written. The K4 ticket contains a single IP address describing the > interface used by the client to retrieve the ticket from the TGT from > the perspective of the KDC. If the KDC and all services are on the > far side of the NAT, the end user will not notice any problems. But > the ticket will be valid from any IP address inside the NAT (on the > private network.) How so? Are you assuming that AUTH is not used? > Without a NAT, an attacker needs to be able to > spoof the source IP addresses of a connection that is being made in > order to use a stolen ticket on a different host.With a NAT, all > the attacker needs to do from the near side of the NAT is to simply > gain possession of a ticket. > An attacker can be resourceful in many ways. An attacker does not need a NAT to spoof an IP address. Private users of a NAT domain are assumed to be within a trusting domain. > Kerberos 5: > > Kerberos 5 tickets are encrypted. Therefore, an ALG cannot be > written. The K5 ticket contains a list of IP addresses from which > the ticket is to be considered valid. The list is generated by the > client machine, not the KDC. If the services being accessed with > Kerberos authentication are on the public side of the NAT, then > the Kerberos authentication will fail because the IP address used > by the NAT is not in the list of acceptable addresses. > OK. > There are two workarounds in Kerberos 5 both of which reduce the > security of the tickets. The first is to have the clients specify > the
Re: draft-ietf-nat-protocol-complications-02.txt
--- Vernon Schryver <[EMAIL PROTECTED]> wrote: > > From: Matt Holdrege <[EMAIL PROTECTED]> > > > ... > > Just so there is no more confusion, in no way is the IETF endorsing the use > > > or development of NAT. You've completely missed the point of the draft. > > It's purpose is to clearly point out the problems that NAT causes to a > > given set of protocols. > > > > Also please do not steer this thread towards a NAT bashing-fest. We need to > > > complete this document and we need constructive input to this draft. Thanks > > > again for your original input. > > > If the document is not intended to be read as advocating NAT, it also > needs substantial non-technical changes. It currently comes across as > a list of fairly minor, generally easily fixed problems or problems that > don't matter. I don't mean to say that is the intended point of the > document, but is how I read it. Since I'm among those who feel that the > situation with NAT is not quite as bad things would have been if we had > waited for IPv6, you might expect my prejudices to make me read it the > other way. > If you an issue with specific portions of the draft, please let us know. Minor edits could be sent to the authors privately. Thanks. > Instead of appearing to be a complete list of problem and their complete > and easy solutions, the document needs to have more words in each section > saying that the sublist of problems is probably incomplete. The > shortcomings of solutions to the problems should be belabored instead of > glossed over. Seeing that the problems are significant must not require > any technical sophistication in the reader. Agreed. The document was not intended to be an exhaustive list of protocols/applications that fail with NAT. The abstract actually captures that sentiment. Anyways, if you have specific input on things being glossed over without sufficient coverage, do let us know, with any proposed textual editions. We will certainly follow through on that. > For example, most people who > should read this document will see nothing but some opaque acronyms > whose problems surely don't matter in Section 5. Why should anyone care > that IPCEC doesn't work with NAT? > Well, readers should know that IPsec that protects the addresses in IP header cannot work with NAT enroute. Dont you think? > > Vernon Schryver[EMAIL PROTECTED] > cheers, suresh = __ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com
