Re: Using UDP port 514 in z/VM TCPIP...
I did find my problem, and as usual, it was of my own making I mis-read the PIPE UDP help, and had specified 514 as the sending port, rather than specifying 0 and allowing it to choose a port above 1024. I can fix this But, while I understand that, once a UDP message leaves my hands, there is no guarantee of delivery, I would think that the RFC would kick in once the message had actually been sent. The fact that the failure was still inside my box, and completely detectable, bothers me. Is it really right to say ³Oh, it¹s a UDP message, so I won¹t bother to check any return codes from anything I do, cause the RFC says I don¹t have¹ta care...² If you were reading a disk file, and writing the records out to another machine via UDP, and there was a disk failure, should you just ignore it because the RFC for UDP says that there¹s no guarantees? Are are you responsible for checking for disk errors, because your message isn¹t actually out on the wire as yet? -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different. On 3/7/08 7:39 PM, David Boyes [EMAIL PROTECTED] wrote: Also: If I violate this using Pipe and the UDP stage, why don¹t I get a non-zero return code? Because there are no guarantees in the IP protocol specifications that UDP packets are ever delivered. UDP was designed to have those semantics, and thus if you use UDP, you're expected to handle missing packets yourself. If you want guaranteed delivery, you're expected to use TCP. Direct quote from the RFC: UDP does not guarantee reliability or ordering in the way that TCP does. Datagrams may arrive out of order, appear duplicated, or go missing without notice.
Re: Using UDP port 514 in z/VM TCPIP...
On Mon, Mar 10, 2008 at 2:55 PM, RPN01 [EMAIL PROTECTED] wrote: But, while I understand that, once a UDP message leaves my hands, there is no guarantee of delivery, I would think that the RFC would kick in once the message had actually been sent. The fact that the failure was still inside my box, and completely detectable, bothers me. Is it really right to say Oh, it's a UDP message, so I won't bother to check any return codes from anything I do, 'cause the RFC says I don't have'ta care... Use LISTRC option on your pipeline to see whether you're hiding something. My pipeline says: PIPTCQ1015E ERRNO 13: EACCES. PIPMSG003I ... Issued from stage 1 of pipeline 1. PIPMSG001I ... Running udp 53 user tcposdl. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: Using UDP port 514 in z/VM TCPIP...
But, while I understand that, once a UDP message leaves my hands, there is no guarantee of delivery, I would think that the RFC would kick in once the message had actually been sent. The fact that the failure was still inside my box, and completely detectable, bothers me. Is it really right to say Oh, it's a UDP message, so I won't bother to check any return codes from anything I do, 'cause the RFC says I don't have'ta care... That's the way it works because there's no other way to do it if you use UDP. If you use UDP, the U stands for user - it is *your* problem. The only thing the API return code can tell you in a UDP-based application is that the stack accepted the packet - which it did; the packet was accepted by the stack, and you got a RC=0. UDP does not offer anything else, and there is no mechanism in IP to tell you anything else. How is the API supposed to return anything else? If you were reading a disk file, and writing the records out to another machine via UDP, and there was a disk failure, should you just ignore it because the RFC for UDP says that there's no guarantees? Are are you responsible for checking for disk errors, because your message isn't actually out on the wire as yet? You are completely responsible for *all* the application function. UDP guarantees *nothing* other than the packet is constructed and handed to the stack. Take a look at the way NFS is constructed - all the timeouts, responses, error checking, etc is ALL in the application. Anything above the physical act of transferring data is done in the RPC layer, and everything in NFS is stateless to allow it to fit in the UDP cast it out in the void and pray design model. So, yes, working as designed. You want guarantees, use TCP. You want lightweight transport without the TCP overhead, you gotta do the work yourself if you want more reliable semantics.
Re: Using UDP port 514 in z/VM TCPIP...
On Monday, 03/10/2008 at 08:56 EDT, RPN01 [EMAIL PROTECTED] wrote: But, while I understand that, once a UDP message leaves my hands, there is no guarantee of delivery, I would think that the RFC would kick in once the message had actually been sent. The fact that the failure was still inside my box, and completely detectable, bothers me. Is it really right to say ?Oh, it?s a UDP message, so I won?t bother to check any return codes from anything I do, ?cause the RFC says I don?t have?ta care...? Whoever said you don't have to check return codes is smoking something. I don't know of any RFC that says you don't have to check return codes on APIs. (You'll notice that they don't talk about APIs at all!) Can you quote your source? You could have buffer shortages, interface failures, a bad specification, authorization errors, or something else unrelated to the success or failure of the other guy receiving your datagram. Alan Altmark z/VM Development IBM Endicott
Re: Using UDP port 514 in z/VM TCPIP...
On Fri, Mar 7, 2008 at 9:44 PM, RPN01 [EMAIL PROTECTED] wrote: Also: If I violate this using Pipe and the UDP stage, why don't I get a non-zero return code? The UDP stage quietly accepts records, and the pipe returns a zero return code, but no data is actually sent. There's no errors Most certainly CMS Pipelines will slap you on the hand when you try (eg error 1015). But your code may be hiding it. You're right that this has nothing to do with the nature of the UDP network protocol. In general IUCV statements in the CP directory can be used to keep CMS users away from the stack (apart from the old VMCF API). But last time I looked the sample CP directory entries had IUCV ANY and IUCV ALLOW scattered all over the place (a bad example, imho). Since some time, VM TCP/IP by default protects the low port numbers. This is good for the target port of conversations since it prevents the average VM user from acting like a standard service. Though the ports will normally be bound to the standard application, you could think of a denial of service scheme where the application can be tricked into a failure, and the attacker could use the moment until restart to steal the port. At that point, it would also prevent the legitimate server from using it. Basically the only ones that require a low port are the standard services. So when you have put them on the PORT list in VM TCP/IP that is enough to grant access and also to keep others away from that port (DoS). Most applications have two-way traffic, and response goes back to the port number that sent the request. You cannot have different processes use the same port for sending and receiving. So the effect is that conversations that originate from low ports are typically standard applications. The idea is that when it takes root to have that port, the application could be trusted since it was managed by a system admin. Now that each windows user is his own admin on the workstation, this does not make a lot of sense anymore. And finally, there is the issue of re-use of a port number. When someone has used a port, VM TCP/IP will prevent re-use of that port for a short period of time (so that any incoming late traffic is not delivered to the next owner of the port). The example I gave you carefully keeps the port for live while sending UDP datagrams. If you have coded it into an EXEC that establishes a new conversation for each message or each set of messages, you will find VM TCP/IP reject that connection (unless you have reuseaddr). And when you try this trick without specifying the source port number, the stack will have all ports in don't use for a while status and runs out of resources. The TCP/IP support in CMS Pipelines requires some delicate plumbing. You really can't get it straight with a crow bar. You want the pipeline segment with the UDP stage to run permanently. You can use a REXX stage to gets the records out of a spool file or whatever, as long is you don't make the UDP stage part of the sipping pipeline. But that's probably something for CMSPIP-L instead. IIRC you can make syslogd accept traffic from other ports than 514. Unless you can fully trust everyone on VM and Linux, you may at least want to define that port in VM TCP/IP and syslogd. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Using UDP port 514 in z/VM TCPIP...
I was going to ask what I was doing wrong... But I figured that out just a moment ago. My question now is what is the logic behind requiring a user to be in TCPIP¹s Obey list to allow it to use certain TCP/IP ports and protocols. It isn¹t everything, because things like FTP work, and I think you can play fairly fast and loose with higher numbered ports. But trying to connect to port 514 on another virtual machine wasn¹t allowed until I put the user in the Obey list in the PROFILE TCPIP file. Also: If I violate this using Pipe and the UDP stage, why don¹t I get a non-zero return code? The UDP stage quietly accepts records, and the pipe returns a zero return code, but no data is actually sent. There¹s no errors in the TCPIP console log either; the data is just ignored and not sent anywhere. Shouldn¹t there be an indication somewhere that the data wasn¹t sent? Or (and I confess I haven¹t tried to decode anything in the output string yet) is there something in the output of the UDP stage that would indicate that the message failed to send? -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different.
Re: Using UDP port 514 in z/VM TCPIP...
I am not an expert, but from what little I know, the lower ports (1024) were considered to be privileged. The convention was that if the originating port was 1024, then the remote end could __assume__ that the originator was authorized in some special way. And so, by convention, the lower ports were considered to be more secure than the higher ports. Silly, but this dates from a long time ago. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of RPN01 Sent: Friday, March 07, 2008 2:44 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Using UDP port 514 in z/VM TCPIP... I was going to ask what I was doing wrong... But I figured that out just a moment ago. My question now is what is the logic behind requiring a user to be in TCPIP's Obey list to allow it to use certain TCP/IP ports and protocols. It isn't everything, because things like FTP work, and I think you can play fairly fast and loose with higher numbered ports. But trying to connect to port 514 on another virtual machine wasn't allowed until I put the user in the Obey list in the PROFILE TCPIP file. Also: If I violate this using Pipe and the UDP stage, why don't I get a non-zero return code? The UDP stage quietly accepts records, and the pipe returns a zero return code, but no data is actually sent. There's no errors in the TCPIP console log either; the data is just ignored and not sent anywhere. Shouldn't there be an indication somewhere that the data wasn't sent? Or (and I confess I haven't tried to decode anything in the output string yet) is there something in the output of the UDP stage that would indicate that the message failed to send? -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different.
Re: Using UDP port 514 in z/VM TCPIP...
That is part of the UDP design. If an error occurs the data is silently discarded. RPN01 wrote: I was going to ask what I was doing wrong... But I figured that out just a moment ago. My question now is what is the logic behind requiring a user to be in TCPIP’s Obey list to allow it to use certain TCP/IP ports and protocols. It isn’t everything, because things like FTP work, and I think you can play fairly fast and loose with higher numbered ports. But trying to connect to port 514 on another virtual machine wasn’t allowed until I put the user in the Obey list in the PROFILE TCPIP file. Also: If I violate this using Pipe and the UDP stage, why don’t I get a non-zero return code? The UDP stage quietly accepts records, and the pipe returns a zero return code, but no data is actually sent. There’s no errors in the TCPIP console log either; the data is just ignored and not sent anywhere. Shouldn’t there be an indication somewhere that the data wasn’t sent? Or (and I confess I haven’t tried to decode anything in the output string yet) is there something in the output of the UDP stage that would indicate that the message failed to send? -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Using UDP port 514 in z/VM TCPIP...
But my port wasn¹t specified; I was trying to talk to port 514 on the destination. If what you¹re implying was true, then only OBEY users could use FTP, since it¹s port number is 21. -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different. On 3/7/08 2:57 PM, McKown, John [EMAIL PROTECTED] wrote: I am not an expert, but from what little I know, the lower ports (1024) were considered to be privileged. The convention was that if the originating port was 1024, then the remote end could __assume__ that the originator was authorized in some special way. And so, by convention, the lower ports were considered to be more secure than the higher ports. Silly, but this dates from a long time ago. -- John McKown
Re: Using UDP port 514 in z/VM TCPIP...
I'd buy that, except that it wasn't a protocol error; the problem was entirely inside z/VM and TCPIP, in that a parameter was missing in the PROFILE TCPIP, which isn't part of any of the standards. If I put my UDP message out on the wire and it gets lost, I'll accept that. But if my own interface refuses the message before ever sending it, I think it might be useful to report that as an error, or at least log it in the TCPIP console log. -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different. On 3/7/08 2:57 PM, Stephen Frazier [EMAIL PROTECTED] wrote: That is part of the UDP design. If an error occurs the data is silently discarded.
Re: Using UDP port 514 in z/VM TCPIP...
My point exactly. On 3/7/08 3:12 PM, McKown, John [EMAIL PROTECTED] wrote: An ftp client talks to an ftp server. The ftp server (an authorized user) listens on port 21 (control connection). The ftp client uses an ephemeral port (high port) to connect to the ftp server (on port 21). The ftp client does not use port 21 as the source port. -- John McKown . -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of RPN01 Sent: Friday, March 07, 2008 3:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using UDP port 514 in z/VM TCPIP... But my port wasn't specified; I was trying to talk to port 514 on the destination. If what you're implying was true, then only OBEY users could use FTP, since it's port number is 21.
Re: Using UDP port 514 in z/VM TCPIP...
My question now is what is the logic behind requiring a user to be in TCPIP¹s Obey list to allow it to use certain TCP/IP ports and protocols. It isn¹t everything, because things like FTP work, and I think you can play fairly fast and loose with higher numbered ports. Port number 1024 are considered privileged on Unix TCP/IP stacks, and imply that the process operating on them is somehow authorized. The virtual machine manipulating a low port has to be either in the OBEY list OR listed on the PORT statement in the TCPIP profile. Also: If I violate this using Pipe and the UDP stage, why don¹t I get a non-zero return code? Because there are no guarantees in the IP protocol specifications that UDP packets are ever delivered. UDP was designed to have those semantics, and thus if you use UDP, you're expected to handle missing packets yourself. If you want guaranteed delivery, you're expected to use TCP. Shouldn¹t there be an indication somewhere that the data wasn¹t sent? Nope. That's the risk one takes with UDP. This is why syslog-NG uses TCP.
Re: Using UDP port 514 in z/VM TCPIP...
My point exactly. FTPSERVE is listed as an authorized virtual machine in the PORTS list in the TCPIP PROFILE. This permits it to listen on a low port. The FTP client does not use a low source port, so is not subject to the restriction.
Re: Using UDP port 514 in z/VM TCPIP...
Also: If I violate this using Pipe and the UDP stage, why don¹t I get a non-zero return code? Because there are no guarantees in the IP protocol specifications that UDP packets are ever delivered. UDP was designed to have those semantics, and thus if you use UDP, you're expected to handle missing packets yourself. If you want guaranteed delivery, you're expected to use TCP. Direct quote from the RFC: UDP does not guarantee reliability or ordering in the way that TCP does. Datagrams may arrive out of order, appear duplicated, or go missing without notice.
