From deepakpad@yahoo.com Mon Nov 21 04:01:25 2011 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A6A21F8BF4 for ; Mon, 21 Nov 2011 04:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zCSL9zkxhbI for ; Mon, 21 Nov 2011 04:01:24 -0800 (PST) Received: from nm37-vm2.bullet.mail.bf1.yahoo.com (nm37-vm2.bullet.mail.bf1.yahoo.com [72.30.238.202]) by ietfa.amsl.com (Postfix) with SMTP id 4EE5D21F8BB8 for ; Mon, 21 Nov 2011 04:01:24 -0800 (PST) Received: from [98.139.212.144] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 21 Nov 2011 12:01:18 -0000 Received: from [98.139.212.246] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 21 Nov 2011 12:01:18 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 21 Nov 2011 12:01:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 860526.74593.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 89635 invoked by uid 60001); 21 Nov 2011 12:01:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1321876878; bh=qrswydc9zcrq/cUdo09H6RSRQ8eHI2/XIb3O+VyTyJg=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=z4AlEgyXdOeFOo9SLbuXr8tmWMcLpByr9hvtc1WlpY/lV9KvKontVnxgXWMG8PtazrhUv8+/xOIu7XqugAtSGQ+O67muP8L+Tzeedvnq46oe8APj1Mbl7wNb2SagvU3OFunrSe6oTlbdB/DSExCMaJp4MpzQUFuYsIW7c94aZYQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=0s2qhzazHL7jYGuTFtfzAEOLhpgLfP+4epDGImia8NM3kU+/bJIxIxGUofe4+x/YQlIsSGKDdujtmtmAcNwnWm7rLy5ItweZsRL7gBhRY7zwvrY5nknojGYwkssW7MM+GnBgg7N7gO/gz3V87OazmgJgKz4A0Iq60+9qL3aP5sY=; X-YMail-OSG: sWOohlkVM1l9jPcotmiynBILxjFfp_KScmFGxjS5Tur.jNB sPrW7lUnOJEh6wkXaI64e9jobo6Af7yCSTE7D3WLHrptjP8jqtn2xT1wfYYM 6Bqlpm9rWhG9giRRCGidHxkGR__XMJ1E1_.9DbR4vH7P8FiAsQNqxeP2n5Jv Viv_MHw8jkDv_2Affmb_0.cw2TzQAcqzbQ0e0fTMdWd9_tknrNtJco1gtE.u aGAG5S65g1TYK6zeA7hisNoz7ZXgUQ4StLKVnCRZj0HHu3vlaBSnKYAA88FP 73SESzfqahJMuQWy2pkJ0akssTV8t1XjzEc_2wL.J48lor.YfmVXwXPeze1. Pv9IckvjilneDR9CFgHUsTkkwzoJ2y02qr6Fgu0AGF1nNmKO2wn5R2V4eEZu _JmWBGEetow_DBybEYUhSqlfYCd6kXgp9MMJPExXZ00ICnoPi2A3UhvF78Qf sFBIQqZhNMA-- Received: from [135.245.168.35] by web160305.mail.bf1.yahoo.com via HTTP; Mon, 21 Nov 2011 04:01:18 PST X-Mailer: YahooMailWebService/0.8.115.331698 Message-ID: <1321876878.89529.YahooMailNeo@web160305.mail.bf1.yahoo.com> Date: Mon, 21 Nov 2011 04:01:18 -0800 (PST) From: deepak rajaram To: "architecture-discuss@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-360795340-765327934-1321876878=:89529" X-Mailman-Approved-At: Mon, 21 Nov 2011 08:06:37 -0800 Subject: [arch-d] UDP Client-Server Behavior X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: deepak rajaram List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 12:06:12 -0000 ---360795340-765327934-1321876878=:89529 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0A=0AThere are two questions on UDP sessions=0A=0A=0A1> I would like to= know if there is any way to send a message to a UDP client "from" a server= for disconnecting the session.=0AWhile i do realize that a ICMP message co= uld be sent by a server during port scan, That would be only on the server = side. is there a possibility that a server could send out a message to the = client =A0to close the session?=0A=0AFor Eg:=0A-- A client tries to establi= sh a session with source port x(on client) to a destination port y on a ser= ver=A0=0A-- The server should reply to x with some message for informing th= e client to disconnect the session=0A=0A2> Is there any limit on the number= of bytes to be sent on a UDP socket, i have seen implementations where, a = single byte data will disconnect the session, can this logic be used to ach= ive the above point?=0A=0AEg:=A0=0AA Server sends a 1 byte data to client a= nd the client closes the session?=0Aor=0AA Client sends a 1 byte data and t= he sever closes the UDP session?=0A=0ARegards,=0ADeepak ---360795340-765327934-1321876878=:89529 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=

There are two questions on= UDP sessions
1> I would like to know if there is any way to send a message to a= UDP client "from" a server for disconnecting the session.
While = i do realize that a ICMP message could be sent by a server during port scan= , That would be only on the server side. is there a possibility that a serv= er could send out a message to the client  to close the session?
=

For Eg:
-- A client tries to establish a sess= ion with source port x(on client) to a destination port y on a server 
-- The server should reply to x with some message f= or informing the client to disconnect the session

2> Is there any limit on the number of byte= s to be sent on a UDP socket, i have seen implementations where, a single b= yte data will disconnect the session, can this logic be used to achive the = above point?
Eg: 
A Server sends a 1 b= yte data to client and the client closes the session?
or
A Client sends a 1 byte data and the sever closes = the UDP session?

Regards,=
Deepak
 
<= br>
---360795340-765327934-1321876878=:89529-- From touch@isi.edu Mon Nov 21 08:48:31 2011 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A148221F8B10 for ; Mon, 21 Nov 2011 08:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.117 X-Spam-Level: X-Spam-Status: No, score=-103.117 tagged_above=-999 required=5 tests=[AWL=-1.118, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwMytGiXd2WV for ; Mon, 21 Nov 2011 08:48:31 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3E18721F8B0B for ; Mon, 21 Nov 2011 08:48:31 -0800 (PST) Received: from [192.168.1.94] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id pALGlviL005159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 Nov 2011 08:48:05 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Joe Touch In-Reply-To: <1321876878.89529.YahooMailNeo@web160305.mail.bf1.yahoo.com> Date: Mon, 21 Nov 2011 08:47:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3D169D8C-EC79-4C65-9C4E-1554AE2F253D@isi.edu> References: <1321876878.89529.YahooMailNeo@web160305.mail.bf1.yahoo.com> To: deepak rajaram X-Mailer: Apple Mail (2.1251.1) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "architecture-discuss@ietf.org" Subject: Re: [arch-d] UDP Client-Server Behavior X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 16:48:31 -0000 On Nov 21, 2011, at 4:01 AM, deepak rajaram wrote: > Hi, >=20 > There are two questions on UDP sessions >=20 > 1> I would like to know if there is any way to send a message to a UDP = client "from" a server for disconnecting the session. > While i do realize that a ICMP message could be sent by a server = during port scan, That would be only on the server side. is there a = possibility that a server could send out a message to the client to = close the session? >=20 > For Eg: > -- A client tries to establish a session with source port x(on client) = to a destination port y on a server=20 > -- The server should reply to x with some message for informing the = client to disconnect the session UDP is connectionless and includes only demultiplexing information; it = has no signaling. There are two options: 1) send an application message that indicates the association has ended 2) send an ICMP error that the port is no longer reachable (2) might legitimately be interpreted as terminating all application = sessions to that UDP port, though - it's not source port/destination = port specific. (1) is the only safe option > 2> Is there any limit on the number of bytes to be sent on a UDP = socket, i have seen implementations where, a single byte data will = disconnect the session, can this logic be used to achive the above = point? >=20 > Eg:=20 > A Server sends a 1 byte data to client and the client closes the = session? > or > A Client sends a 1 byte data and the sever closes the UDP session?\ There should be no limit to the number of bytes sent on a UDP socket; = each SEND call is supposed to emit a separate UDP message that is = completely unrelated to any other at the transport layer.=20 An *application* can decide that an application-layer association is = terminated when it receives a specific number of bytes or a specific = response, but that's at the application layer. Overall, it seems like you're expecting TCP-like semantics from UDP. Joe= From deepakpad@yahoo.com Tue Nov 22 06:17:07 2011 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D0221F8E0A for ; Tue, 22 Nov 2011 06:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.517 X-Spam-Level: X-Spam-Status: No, score=0.517 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Dy9A0z-QsgS for ; Tue, 22 Nov 2011 06:17:06 -0800 (PST) Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) by ietfa.amsl.com (Postfix) with SMTP id 6C84321F8B44 for ; Tue, 22 Nov 2011 06:17:06 -0800 (PST) Received: from [98.139.212.153] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 22 Nov 2011 14:17:00 -0000 Received: from [98.139.212.204] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 22 Nov 2011 14:17:00 -0000 Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP; 22 Nov 2011 14:17:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 2441.50944.bm@omp1013.mail.bf1.yahoo.com Received: (qmail 87443 invoked by uid 60001); 22 Nov 2011 14:16:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1321971419; bh=hCRPa3nSFkjUlwUU20a9QfO0hOzI/JfsNWME+WPT7gM=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=anEXPEogSNFptXCcp+nXG2vWwFUqqSKn6GzHj7NpCdIgRCztxW+KtnS53yC0/NigEJ2PsI1SUcEgB8TuXvcE+Z12l6+aiiyjJ9prJKW0rNk65wg6FOlrBjjAkMPP6hiVbmIleNt/O+AzRFD0VHzXjY7tOpNegkRUGQxT18v08d8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Tb6AnkKVFkBJTGfKKNBoZk9i8k6M4ecj2CxJ7JcIHcfAsh87WXUMdahzh7iRdeg/xP0+7mY+52VPAgpxedfCEtfm+pP5kDxrxHnsNkhVkNSDzs8Nb8G3pyJP2ds/j1LsY7coN6QXPyVyzFow6jPjJBAs0yTXiA2xKWmxtVQ3M8E=; X-YMail-OSG: A7.jR8oVM1na_.RmdhqxRJOusloDhfbP7zmR1Xrt6KwG9aa 0w2cvrhNcJAYdoTdsZNLVq9JLxka3Z9ULyvPAZyTG3L1Or6Fs56ryVE2hGrb 2IvkwTFv25Xmmzxf4_AFbt4yX1fMYuy2x7OZIXtIhAz7mO0BI0DnKfGzykpd SbGyQ3uz81WP88pIu74YSyp5OpjHAyjsHpCVuXgZjzGAFH1LzvbaFWzwrZJV AyQvm40nXgdQ86Mvuo4h0koE3fre2Uonq49rxWuGdgvGV.JeBL5luCIN2Pcv 3PRULO5wkGjTmxwWj_1RCyPH86NTrY4kng1amU7ttIcIJlOFHUk.ogXTgpsW nw1S3V_.4bnP3OAU_2HmIHC37lPhXK3JFrlJ7CuKHlBh2uk9b3k6rm7ic.S. n1oO5H8dPmEkC8hNG_bLj2aCDwEtMG19_GmwPBocfywZ6mvo2rgrpcipIG4M BjfIExA-- Received: from [135.245.168.34] by web160301.mail.bf1.yahoo.com via HTTP; Tue, 22 Nov 2011 06:16:59 PST X-Mailer: YahooMailWebService/0.8.115.331698 References: <1321876878.89529.YahooMailNeo@web160305.mail.bf1.yahoo.com> <3D169D8C-EC79-4C65-9C4E-1554AE2F253D@isi.edu> Message-ID: <1321971419.59142.YahooMailNeo@web160301.mail.bf1.yahoo.com> Date: Tue, 22 Nov 2011 06:16:59 -0800 (PST) From: deepak rajaram To: Joe Touch In-Reply-To: <3D169D8C-EC79-4C65-9C4E-1554AE2F253D@isi.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="942134078-1367346551-1321971419=:59142" Cc: "architecture-discuss@ietf.org" Subject: Re: [arch-d] UDP Client-Server Behavior X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: deepak rajaram List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 14:17:07 -0000 --942134078-1367346551-1321971419=:59142 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=A0Hi Joe,=0AThanks a lot for the reply,=0A=0ARegarding option 1: "se= nd an application message that indicates the association has ended"=0AIf my= understanding is correct, "All" available UDP clients should be in a posit= ion to interpret this message(session termination message) sent from my ser= ver, which might not be possible, is there any other generic way by which i= could achieve this , which would allow the user to use "any" available UDP= client??=0A=0A=0A=0A=0A________________________________=0A From: Joe Touch= =0ATo: deepak rajaram =0ACc: "archite= cture-discuss@ietf.org" =0ASent: Monday, No= vember 21, 2011 10:17 PM=0ASubject: Re: [arch-d] UDP Client-Server Behavior= =0A =0A=0AOn Nov 21, 2011, at 4:01 AM, deepak rajaram wrote:=0A=0A> Hi,=0A>= =0A> There are two questions on UDP sessions=0A> =0A> 1> I would like to k= now if there is any way to send a message to a UDP client "from" a server f= or disconnecting the session.=0A> While i do realize that a ICMP message co= uld be sent by a server during port scan, That would be only on the server = side. is there a possibility that a server could send out a message to the = client=A0 to close the session?=0A> =0A> For Eg:=0A> -- A client tries to e= stablish a session with source port x(on client) to a destination port y on= a server =0A> -- The server should reply to x with some message for inform= ing the client to disconnect the session=0A=0AUDP is connectionless and inc= ludes only demultiplexing information; it has no signaling. There are two o= ptions:=0A=0A1) send an application message that indicates the association = has ended=0A=0A2) send an ICMP error that the port is no longer reachable= =0A=0A(2) might legitimately be interpreted as terminating all application = sessions to that UDP port, though - it's not source port/destination port s= pecific.=0A=0A(1) is the only safe option=0A=0A> 2> Is there any limit on t= he number of bytes to be sent on a UDP socket, i have seen implementations = where, a single byte data will disconnect the session, can this logic be us= ed to achive the above point?=0A> =0A> Eg: =0A> A Server sends a 1 byte dat= a to client and the client closes the session?=0A> or=0A> A Client sends a = 1 byte data and the sever closes the UDP session?\=0A=0AThere should be no = limit to the number of bytes sent on a UDP socket; each SEND call is suppos= ed to emit a separate UDP message that is completely unrelated to any other= at the transport layer. =0A=0AAn *application* can decide that an applicat= ion-layer association is terminated when it receives a specific number of b= ytes or a specific response, but that's at the application layer.=0A=0AOver= all, it seems like you're expecting TCP-like semantics from UDP.=0A=0AJoe --942134078-1367346551-1321971419=:59142 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

 Hi Joe,
Thanks a lot for the reply,
<= br>
Regarding option 1: "send an application message that indicat= es the association has ended"
If my understanding is correct, "Al= l" available UDP clients should be in a position to interpret this message(= session termination message) sent from my server, which might not be possib= le, is there any other generic way by which i could achieve this , which wo= uld allow the user to use "any" available UDP client??


From: Joe Touch <touch@isi.edu&g= t;
To: deepak rajaram = <deepakpad@yahoo.com>
Cc: "architecture-discuss@ietf.org" <architecture-discuss@ietf.org= >
Sent: Monday, No= vember 21, 2011 10:17 PM
Subject:= Re: [arch-d] UDP Client-Server Behavior
=0A
= On Nov 21, 2011, at 4:01 AM, deepak rajaram wrote:

> Hi,
> =
> There are two questions on UDP sessions
>
> 1> I w= ould like to know if there is any way to send a message to a UDP client "fr= om" a server for disconnecting the session.
> While i do realize that= a ICMP message could be sent by a server during port scan, That would be o= nly on the server side. is there a possibility that a server could send out= a message to the client  to close the session?
>
> For E= g:
> -- A client tries to establish a session with source port x(on c= lient) to a destination port y on a server
> -- The server should re= ply to x with some message for informing the client to disconnect the sessi= on

UDP is connectionless and includes only demultiplexing informatio= n; it has no signaling. There are two options:

1) send an applicatio= n message that indicates the association has ended

2) send an ICMP error that the port is no longer reachable

(2) might l= egitimately be interpreted as terminating all application sessions to that = UDP port, though - it's not source port/destination port specific.

(= 1) is the only safe option

> 2> Is there any limit on the numb= er of bytes to be sent on a UDP socket, i have seen implementations where, = a single byte data will disconnect the session, can this logic be used to a= chive the above point?
>
> Eg:
> A Server sends a 1 byt= e data to client and the client closes the session?
> or
> A Cl= ient sends a 1 byte data and the sever closes the UDP session?\

Ther= e should be no limit to the number of bytes sent on a UDP socket; each SEND= call is supposed to emit a separate UDP message that is completely unrelat= ed to any other at the transport layer.

An *application* can decide= that an application-layer association is terminated when it receives a specific number of bytes or a specific response, but that's at = the application layer.

Overall, it seems like you're expecting TCP-l= ike semantics from UDP.

Joe

--942134078-1367346551-1321971419=:59142-- From randy@qualcomm.com Tue Nov 22 10:53:08 2011 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052FA21F88B7 for ; Tue, 22 Nov 2011 10:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.245 X-Spam-Level: X-Spam-Status: No, score=-105.245 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5O2+wDBbouo for ; Tue, 22 Nov 2011 10:53:07 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 5042D21F87C5 for ; Tue, 22 Nov 2011 10:53:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1321987987; x=1353523987; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20<1321971419.59142.YahooMailNeo@web160301. mail.bf1.yahoo.com>|References:=20<1321876878.89529.Yahoo MailNeo@web160305.mail.bf1.yahoo.com>=0D=0A=20<3D169D8C-E C79-4C65-9C4E-1554AE2F253D@isi.edu>=0D=0A=20<1321971419.5 9142.YahooMailNeo@web160301.mail.bf1.yahoo.com>|X-Mailer: =20Eudora=20for=20Mac=20OS=20X|Date:=20Tue,=2022=20Nov=20 2011=2010:50:29=20-0800|To:=20deepak=20rajaram=20,=20Joe=20Touch=20|From:=20Ra ndall=20Gellens=20|Subject:=20Re:=20[ arch-d]=20UDP=20Client-Server=20Behavior|CC:=20"architect ure-discuss@ietf.org"=20 |MIME-Version:=201.0|Content-Type:=20text/html=3B=20chars et=3D"us-ascii"|X-Random-Sig-Tag:=201.0b28 |X-Originating-IP:=20[172.30.39.5]; bh=ucgqo8Ft/VYFpTU7ICWo2se5hwo3itxQt1BPOCJPl5w=; b=FzOJpaQ/MUeaDSMD/vAP61yjKnwIkzUcqEzqgvlcRHBiZXhHbidDFNf6 scnzLXn6wm1E2GFooXr4zQQHlcbSG3SqfHLJKaLYp+c1Mh/y/u6U+i2BN f+bXXOWvmC3oy1cVtPn1zCzda4e7xRA4BcwmOgtf93mwqW5KYV6Y28b+Q E=; X-IronPort-AV: E=McAfee;i="5400,1158,6538"; a="140005762" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 22 Nov 2011 10:53:06 -0800 X-IronPort-AV: E=Sophos;i="4.69,553,1315206000"; d="scan'208,217";a="119321616" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 22 Nov 2011 10:53:06 -0800 Received: from [172.21.1.9] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 22 Nov 2011 10:53:06 -0800 Message-ID: In-Reply-To: <1321971419.59142.YahooMailNeo@web160301.mail.bf1.yahoo.com> References: <1321876878.89529.YahooMailNeo@web160305.mail.bf1.yahoo.com> <3D169D8C-EC79-4C65-9C4E-1554AE2F253D@isi.edu> <1321971419.59142.YahooMailNeo@web160301.mail.bf1.yahoo.com> X-Mailer: Eudora for Mac OS X Date: Tue, 22 Nov 2011 10:50:29 -0800 To: deepak rajaram , Joe Touch From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] X-Mailman-Approved-At: Tue, 22 Nov 2011 10:54:05 -0800 Cc: "architecture-discuss@ietf.org" Subject: Re: [arch-d] UDP Client-Server Behavior X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 18:53:08 -0000 Re: [arch-d] UDP Client-Server Behavior
At 6:16 AM -0800 11/22/11, deepak rajaram wrote:

 Hi Joe,
Thanks a lot for the reply,

Regarding option 1: "send an application message that indicates the association has ended"
If my understanding is correct, "All" available UDP clients should be in a position to interpret this message(session termination message) sent from my server, which might not be possible, is there any other generic way by which i could achieve this , which would allow the user to use "any" available UDP client??

What is a "session" in this case?

What is a UDP client in this case?

Where are these UDP clients coming from?

What are these UDP clients doing with the UDP?


From: Joe Touch <touch@isi.edu>
To: deepak rajaram <deepakpad@yahoo.com>
Cc: "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
Sent: Monday, November 21, 2011 10:17 PM
Subject: Re: [arch-d] UDP Client-Server Behavior


On Nov 21, 2011, at 4:01 AM, deepak rajaram wrote:

> Hi,
>
> There are two questions on UDP sessions
>
> 1> I would like to know if there is any way to send a message to a UDP client "from" a server for disconnecting the session.
> While i do realize that a ICMP message could be sent by a server during port scan, That would be only on the server side. is there a possibility that a server could send out a message to the client  to close the session?
>
> For Eg:
> -- A client tries to establish a session with source port x(on client) to a destination port y on a server
> -- The server should reply to x with some message for informing the client to disconnect the session

UDP is connectionless and includes only demultiplexing information; it has no signaling. There are two options:

1) send an application message that indicates the association has ended

2) send an ICMP error that the port is no longer reachable

(2) might legitimately be interpreted as terminating all application sessions to that UDP port, though - it's not source port/destination port specific.

(1) is the only safe option

> 2> Is there any limit on the number of bytes to be sent on a UDP socket, i have seen implementations where, a single byte data will disconnect the session, can this logic be used to achive the above point?
>
> Eg:
> A Server sends a 1 byte data to client and the client closes the session?
> or
> A Client sends a 1 byte data and the sever closes the UDP session?\

There should be no limit to the number of bytes sent on a UDP socket; each SEND call is supposed to emit a separate UDP message that is completely unrelated to any other at the transport layer.

An *application* can decide that an application-layer association is terminated when it receives a specific number of bytes or a specific response, but that's at the application layer.

Overall, it seems like you're expecting TCP-like semantics from UDP.

Joe

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss


--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Reading Proust is like bathing in someone else's dirty water.
   --Alexander Woollcott
From touch@isi.edu Tue Nov 22 11:04:43 2011 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCC311E8083 for ; Tue, 22 Nov 2011 11:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=-0.957, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hb0gX-2b9kxD for ; Tue, 22 Nov 2011 11:04:41 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id E032511E8082 for ; Tue, 22 Nov 2011 11:04:41 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id pAMJ4U4v028608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Nov 2011 11:04:33 -0800 (PST) Message-ID: <4ECBF23D.4080401@isi.edu> Date: Tue, 22 Nov 2011 11:04:29 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: deepak rajaram References: <1321876878.89529.YahooMailNeo@web160305.mail.bf1.yahoo.com> <3D169D8C-EC79-4C65-9C4E-1554AE2F253D@isi.edu> <1321971419.59142.YahooMailNeo@web160301.mail.bf1.yahoo.com> In-Reply-To: <1321971419.59142.YahooMailNeo@web160301.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "architecture-discuss@ietf.org" Subject: Re: [arch-d] UDP Client-Server Behavior X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 19:04:44 -0000 Hi, Deepak, On 11/22/2011 6:16 AM, deepak rajaram wrote: > > Hi Joe, > Thanks a lot for the reply, > > Regarding option 1: "send an application message that indicates the > association has ended" > If my understanding is correct, "All" available UDP clients should be in > a position to interpret this message(session termination message) sent > from my server, which might not be possible, is there any other generic > way by which i could achieve this , which would allow the user to use > "any" available UDP client?? TCP clients can connect to any TCP server, and TCP CLOSE indicates the end of a connection. UDP is a *message* protocol, not a connection protocol. There is no state at the UDP layer to terminate, since none is ever established. The state of a session has meaning only at the application layer, and so is application-specific. There is no such thing as a universal UDP session terminator. If the difference isn't apparent, you need to seek a textbook, not this mailing list. Joe > ------------------------------------------------------------------------ > *From:* Joe Touch > *To:* deepak rajaram > *Cc:* "architecture-discuss@ietf.org" > *Sent:* Monday, November 21, 2011 10:17 PM > *Subject:* Re: [arch-d] UDP Client-Server Behavior > > > On Nov 21, 2011, at 4:01 AM, deepak rajaram wrote: > > > Hi, > > > > There are two questions on UDP sessions > > > > 1> I would like to know if there is any way to send a message to a > UDP client "from" a server for disconnecting the session. > > While i do realize that a ICMP message could be sent by a server > during port scan, That would be only on the server side. is there a > possibility that a server could send out a message to the client to > close the session? > > > > For Eg: > > -- A client tries to establish a session with source port x(on > client) to a destination port y on a server > > -- The server should reply to x with some message for informing the > client to disconnect the session > > UDP is connectionless and includes only demultiplexing information; it > has no signaling. There are two options: > > 1) send an application message that indicates the association has ended > > 2) send an ICMP error that the port is no longer reachable > > (2) might legitimately be interpreted as terminating all application > sessions to that UDP port, though - it's not source port/destination > port specific. > > (1) is the only safe option > > > 2> Is there any limit on the number of bytes to be sent on a UDP > socket, i have seen implementations where, a single byte data will > disconnect the session, can this logic be used to achive the above point? > > > > Eg: > > A Server sends a 1 byte data to client and the client closes the session? > > or > > A Client sends a 1 byte data and the sever closes the UDP session?\ > > There should be no limit to the number of bytes sent on a UDP socket; > each SEND call is supposed to emit a separate UDP message that is > completely unrelated to any other at the transport layer. > > An *application* can decide that an application-layer association is > terminated when it receives a specific number of bytes or a specific > response, but that's at the application layer. > > Overall, it seems like you're expecting TCP-like semantics from UDP. > > Joe > From deepakpad@yahoo.com Tue Nov 22 23:32:55 2011 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE9211E80DF for ; Tue, 22 Nov 2011 23:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.175 X-Spam-Level: X-Spam-Status: No, score=0.175 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iRI7HCtN0Ci for ; Tue, 22 Nov 2011 23:32:55 -0800 (PST) Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) by ietfa.amsl.com (Postfix) with SMTP id 9FEE821F841D for ; Tue, 22 Nov 2011 23:32:54 -0800 (PST) Received: from [98.139.212.148] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 23 Nov 2011 07:32:47 -0000 Received: from [98.139.212.215] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 23 Nov 2011 07:32:46 -0000 Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 23 Nov 2011 07:32:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 978879.98302.bm@omp1024.mail.bf1.yahoo.com Received: (qmail 85362 invoked by uid 60001); 23 Nov 2011 07:32:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1322033566; bh=z5TzEflA/45bM0ETCWssO3WrYk1ycDucgvf1nBSb7Gk=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=UZiKkUWhhA4RnbsBx5/fbW/I+NCh04exerYfAbgqf2prEKBOIu3cTB/+J4yK7D0pWHXTXzfu4LD3Qu0/eVUyZxJrdbXQVwYaNZhUiAXrrWDlFaV5j42x3cNAqvDFid+s8GIuqhydVyyUzSAwjZSDQOa6L+4CJY5hpoeuy5ASPTA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=uDV/z9wRggUUJQzHEIEq41utm3EoNgxczsF2+O73WZ0GKSWUQ6rXdSsm72SE3DiyLtdxicsTEep9fBOWadTY20/3UZK55+wj79GU9V4gEn0XPtzl/R5fOQZrfcSWaUBYkTFzJESb5hjiBwr3uCCGFs2Fd5t2auMsGBqtddBDbPo=; X-YMail-OSG: 186YbQcVM1nv6Fzzse5LT6o8qk1nZcyRgRTcg6ajrJabYQa tccV5EBy69mwh4XWIlCA52010Zb0Cqud9WlnxKmhzuqW7ipkhtdjwD8GW._Q y3ZMpRi9y5pFSoo2d7vi3Psc2e2hlpY4pXd4iocLVfLGxP.MpXbVc8ktz13J 3.wn9yPbiGMmHn9Q6aa7Ujunj0bS6_Q4VyVOyfdLjuwDgZqJRqGlszm9rxn3 5Fo8EruPdz310ycmJZks8D0VT1c_2YO7u8VR.SmGEigdZ09TwqqvUQfcNCYf xx_Ui4cOUeDa_Pk9FUN6p7KrkT.cZ0hVGljUdnyQzG7G3WQnmx5uYZeVSXvO dk14kO9SuEEsNKBpMx7JDHRJt3VrE7Ej4Wa_q8ZGGHQof1je.ZB39jr5AGBg nqUMIeusCdNnfSK_REbwgxPw5EU9grKSVHSShfabA533Qff62ocA8rflo5xH wh5L7 Received: from [135.245.168.34] by web160302.mail.bf1.yahoo.com via HTTP; Tue, 22 Nov 2011 23:32:46 PST X-Mailer: YahooMailWebService/0.8.115.331698 References: <1321876878.89529.YahooMailNeo@web160305.mail.bf1.yahoo.com> <3D169D8C-EC79-4C65-9C4E-1554AE2F253D@isi.edu> <1321971419.59142.YahooMailNeo@web160301.mail.bf1.yahoo.com> <4ECBF23D.4080401@isi.edu> Message-ID: <1322033566.85092.YahooMailNeo@web160302.mail.bf1.yahoo.com> Date: Tue, 22 Nov 2011 23:32:46 -0800 (PST) From: deepak rajaram To: Joe Touch In-Reply-To: <4ECBF23D.4080401@isi.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1663062914-418405732-1322033566=:85092" Cc: "architecture-discuss@ietf.org" Subject: Re: [arch-d] UDP Client-Server Behavior X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: deepak rajaram List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 07:32:55 -0000 ---1663062914-418405732-1322033566=:85092 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Joe,=0A=0A=0AI do understand the difference, however, i have seen some i= mplementations where, if a "single byte" data is sent to a UDP port, it was= treated as a session terminator and all possible clients/connections were = terminated. I guess , like you said earlier, a TCP like semantics is tried = here for UDP.=0A=0AIn my previous mail, what i meant by=A0=0AUDP Server: A = machine in which has a particular UDP service is=A0running on a port to whi= ch UDP clients could send messages=0AUDP Client: Nothing but an application= used to send messages to the UDP port on the server=0A=0AThanks a lot for = your replies.=0A=0ARegards,=0ADeepak=0A=0A________________________________= =0A From: Joe Touch =0ATo: deepak rajaram =0ACc: "architecture-discuss@ietf.org" = =0ASent: Wednesday, November 23, 2011 12:34 AM=0ASubject: Re: [arch-d] UDP = Client-Server Behavior=0A =0AHi, Deepak,=0A=0AOn 11/22/2011 6:16 AM, deepak= rajaram wrote:=0A>=0A> Hi Joe,=0A> Thanks a lot for the reply,=0A>=0A> Reg= arding option 1: "send an application message that indicates the=0A> associ= ation has ended"=0A> If my understanding is correct, "All" available UDP cl= ients should be in=0A> a position to interpret this message(session termina= tion message) sent=0A> from my server, which might not be possible, is ther= e any other generic=0A> way by which i could achieve this , which would all= ow the user to use=0A> "any" available UDP client??=0A=0ATCP clients can co= nnect to any TCP server, and TCP CLOSE indicates the =0Aend of a connection= .=0A=0AUDP is a *message* protocol, not a connection protocol. There is no = =0Astate at the UDP layer to terminate, since none is ever established. The= =0Astate of a session has meaning only at the application layer, and so is= =0Aapplication-specific. There is no such thing as a universal UDP session= =0Aterminator.=0A=0AIf the difference isn't apparent, you need to seek a t= extbook, not this =0Amailing list.=0A=0AJoe=0A=0A> ------------------------= ------------------------------------------------=0A> *From:* Joe Touch =0A> *To:* deepak rajaram =0A> *Cc:* "archi= tecture-discuss@ietf.org" =0A> *Sent:* Monda= y, November 21, 2011 10:17 PM=0A> *Subject:* Re: [arch-d] UDP Client-Server= Behavior=0A>=0A>=0A> On Nov 21, 2011, at 4:01 AM, deepak rajaram wrote:=0A= >=0A>=A0 > Hi,=0A>=A0 >=0A>=A0 > There are two questions on UDP sessions=0A= >=A0 >=0A>=A0 > 1> I would like to know if there is any way to send a messa= ge to a=0A> UDP client "from" a server for disconnecting the session.=0A>= =A0 > While i do realize that a ICMP message could be sent by a server=0A> = during port scan, That would be only on the server side. is there a=0A> pos= sibility that a server could send out a message to the client to=0A> close = the session?=0A>=A0 >=0A>=A0 > For Eg:=0A>=A0 > -- A client tries to establ= ish a session with source port x(on=0A> client) to a destination port y on = a server=0A>=A0 > -- The server should reply to x with some message for inf= orming the=0A> client to disconnect the session=0A>=0A> UDP is connectionle= ss and includes only demultiplexing information; it=0A> has no signaling. T= here are two options:=0A>=0A> 1) send an application message that indicates= the association has ended=0A>=0A> 2) send an ICMP error that the port is n= o longer reachable=0A>=0A> (2) might legitimately be interpreted as termina= ting all application=0A> sessions to that UDP port, though - it's not sourc= e port/destination=0A> port specific.=0A>=0A> (1) is the only safe option= =0A>=0A>=A0 > 2> Is there any limit on the number of bytes to be sent on a = UDP=0A> socket, i have seen implementations where, a single byte data will= =0A> disconnect the session, can this logic be used to achive the above poi= nt?=0A>=A0 >=0A>=A0 > Eg:=0A>=A0 > A Server sends a 1 byte data to client a= nd the client closes the session?=0A>=A0 > or=0A>=A0 > A Client sends a 1 b= yte data and the sever closes the UDP session?\=0A>=0A> There should be no = limit to the number of bytes sent on a UDP socket;=0A> each SEND call is su= pposed to emit a separate UDP message that is=0A> completely unrelated to a= ny other at the transport layer.=0A>=0A> An *application* can decide that a= n application-layer association is=0A> terminated when it receives a specif= ic number of bytes or a specific=0A> response, but that's at the applicatio= n layer.=0A>=0A> Overall, it seems like you're expecting TCP-like semantics= from UDP.=0A>=0A> Joe=0A> ---1663062914-418405732-1322033566=:85092 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jo= e,

I do understand the difference, however, i have seen some imple= mentations where, if a "single byte" data is sent to a UDP port, it was tre= ated as a session terminator and all possible clients/connections were term= inated. I guess , like you said earlier, a TCP like semantics is tried here for UDP.

In my previous mail, what i meant by 
UDP Server:= A machine in which has a particular UDP service is running on = a port to which UDP clients could send messages
UDP Cl= ient: Nothing but an application used to send messages to the UDP port on t= he server

Thanks a lot for y= our replies.

Regards,
<= div style=3D"font-family: 'times new roman', 'new york', times, serif; font= -size: 12pt; ">Deepak
From: Joe Touch <touch@isi.edu>
To: deepak rajaram <deepakpad@yahoo.com>
Cc: "architecture-discuss@ietf.= org" <architecture-discuss@ietf.org>
Sent: Wednesday, November 23, 2011 12:34 AM
Subject: Re: [arch-d] UDP Clien= t-Server Behavior
=0AHi, Deepak,

On 11/22/2011 6:16 = AM, deepak rajaram wrote:
>
> Hi Joe,
> Thanks a lot for = the reply,
>
> Regarding option 1: "send an application message= that indicates the
> association has ended"
> If my understand= ing is correct, "All" available UDP clients should be in
> a position= to interpret this message(session termination message) sent
> from m= y server, which might not be possible, is there any other generic
> w= ay by which i could achieve this , which would allow the user to use
>= ; "any" available UDP client??

TCP clients can connect to any TCP se= rver, and TCP CLOSE indicates the
end of a connection.

UDP is a = *message* protocol, not a connection protocol. There is no
state at the= UDP layer to terminate, since none is ever established. The
state of a= session has meaning only at the application layer, and so is
applicati= on-specific. There is no such thing as a universal UDP session
terminator.

If the difference = isn't apparent, you need to seek a textbook, not this
mailing list.
=
Joe

> -------------------------------------------------------= -----------------
> *From:* Joe Touch <touch@isi.edu>
> *To:* = deepak rajaram <deepakpad@yahoo.com>
> *Cc:* "architecture-discuss@ietf.org" <= architecture-discuss@ietf.org>
> *Sent:* Monday, November 21, = 2011 10:17 PM
> *Subject:* Re: [arch-d] UDP Client-Server Behavior>
>
> On Nov 21, 2011, at 4:01 AM, deepak rajaram wrote:
>
>  > Hi,
>  >
>  >= ; There are two questions on UDP sessions
>  >
>  = > 1> I would like to know if there is any way to send a message to a<= br>> UDP client "from" a server for disconnecting the session.
>&n= bsp; > While i do realize that a ICMP message could be sent by a server<= br>> during port scan, That would be only on the server side. is there a=
> possibility that a server could send out a message to the client t= o
> close the session?
>  >
>  > For Eg:<= br>>  > -- A client tries to establish a session with source por= t x(on
> client) to a destination port y on a server
>  &g= t; -- The server should reply to x with some message for informing the
&= gt; client to disconnect the session
>
> UDP is connectionless = and includes only demultiplexing information; it
> has no signaling. There are two options:
>
> 1) send an application m= essage that indicates the association has ended
>
> 2) send an = ICMP error that the port is no longer reachable
>
> (2) might l= egitimately be interpreted as terminating all application
> sessions = to that UDP port, though - it's not source port/destination
> port sp= ecific.
>
> (1) is the only safe option
>
>  &= gt; 2> Is there any limit on the number of bytes to be sent on a UDP
= > socket, i have seen implementations where, a single byte data will
= > disconnect the session, can this logic be used to achive the above poi= nt?
>  >
>  > Eg:
>  > A Server s= ends a 1 byte data to client and the client closes the session?
>&nbs= p; > or
>  > A Client sends a 1 byte data and the sever cl= oses the UDP session?\
>
> There should be no limit to the number of bytes sent on a UDP socket;
> each SEND call is suppos= ed to emit a separate UDP message that is
> completely unrelated to a= ny other at the transport layer.
>
> An *application* can decid= e that an application-layer association is
> terminated when it recei= ves a specific number of bytes or a specific
> response, but that's a= t the application layer.
>
> Overall, it seems like you're expe= cting TCP-like semantics from UDP.
>
> Joe
>


=
---1663062914-418405732-1322033566=:85092-- From touch@isi.edu Wed Nov 23 10:46:46 2011 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5503B11E8099 for ; Wed, 23 Nov 2011 10:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.024 X-Spam-Level: X-Spam-Status: No, score=-103.024 tagged_above=-999 required=5 tests=[AWL=-1.025, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55fHw8NEfIqE for ; Wed, 23 Nov 2011 10:46:45 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id CB00D21F8B14 for ; Wed, 23 Nov 2011 10:46:45 -0800 (PST) Received: from [192.168.1.90] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id pANIkM2h008355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Nov 2011 10:46:31 -0800 (PST) Message-ID: <4ECD3F7E.9030301@isi.edu> Date: Wed, 23 Nov 2011 10:46:22 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: deepak rajaram References: <1321876878.89529.YahooMailNeo@web160305.mail.bf1.yahoo.com> <3D169D8C-EC79-4C65-9C4E-1554AE2F253D@isi.edu> <1321971419.59142.YahooMailNeo@web160301.mail.bf1.yahoo.com> <4ECBF23D.4080401@isi.edu> <1322033566.85092.YahooMailNeo@web160302.mail.bf1.yahoo.com> In-Reply-To: <1322033566.85092.YahooMailNeo@web160302.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "architecture-discuss@ietf.org" Subject: Re: [arch-d] UDP Client-Server Behavior X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 18:46:46 -0000 Deepak, On 11/22/2011 11:32 PM, deepak rajaram wrote: > Hi Joe, > > I do understand the difference, however, i have seen some > implementations where, if a "single byte" data is sent to a UDP port, it > was treated as a session terminator and all possible clients/connections > were terminated. I guess , like you said earlier, a TCP like semantics > is tried here for UDP. That works only for those *applications* that decide that a single byte UDP *means* "terminate". That's not defined by UDP, nor is it even a convention among UDP application designers. Note also that UDP messages, unlike TCP data, need not be delivered in order, and could be lost in the network. So even for apps that 'agree' on its meaning, it could end up dis-associating applications prematurely or not at all. Joe > ------------------------------------------------------------------------ > *From:* Joe Touch > *To:* deepak rajaram > *Cc:* "architecture-discuss@ietf.org" > *Sent:* Wednesday, November 23, 2011 12:34 AM > *Subject:* Re: [arch-d] UDP Client-Server Behavior > > Hi, Deepak, > > On 11/22/2011 6:16 AM, deepak rajaram wrote: > > > > Hi Joe, > > Thanks a lot for the reply, > > > > Regarding option 1: "send an application message that indicates the > > association has ended" > > If my understanding is correct, "All" available UDP clients should be in > > a position to interpret this message(session termination message) sent > > from my server, which might not be possible, is there any other generic > > way by which i could achieve this , which would allow the user to use > > "any" available UDP client?? > > TCP clients can connect to any TCP server, and TCP CLOSE indicates the > end of a connection. > > UDP is a *message* protocol, not a connection protocol. There is no > state at the UDP layer to terminate, since none is ever established. The > state of a session has meaning only at the application layer, and so is > application-specific. There is no such thing as a universal UDP session > terminator. > > If the difference isn't apparent, you need to seek a textbook, not this > mailing list. > > Joe > > > ------------------------------------------------------------------------ > > *From:* Joe Touch > > > *To:* deepak rajaram > > > *Cc:* "architecture-discuss@ietf.org > " > > > *Sent:* Monday, November 21, 2011 10:17 PM > > *Subject:* Re: [arch-d] UDP Client-Server Behavior > > > > > > On Nov 21, 2011, at 4:01 AM, deepak rajaram wrote: > > > > > Hi, > > > > > > There are two questions on UDP sessions > > > > > > 1> I would like to know if there is any way to send a message to a > > UDP client "from" a server for disconnecting the session. > > > While i do realize that a ICMP message could be sent by a server > > during port scan, That would be only on the server side. is there a > > possibility that a server could send out a message to the client to > > close the session? > > > > > > For Eg: > > > -- A client tries to establish a session with source port x(on > > client) to a destination port y on a server > > > -- The server should reply to x with some message for informing the > > client to disconnect the session > > > > UDP is connectionless and includes only demultiplexing information; it > > has no signaling. There are two options: > > > > 1) send an application message that indicates the association has ended > > > > 2) send an ICMP error that the port is no longer reachable > > > > (2) might legitimately be interpreted as terminating all application > > sessions to that UDP port, though - it's not source port/destination > > port specific. > > > > (1) is the only safe option > > > > > 2> Is there any limit on the number of bytes to be sent on a UDP > > socket, i have seen implementations where, a single byte data will > > disconnect the session, can this logic be used to achive the above point? > > > > > > Eg: > > > A Server sends a 1 byte data to client and the client closes the > session? > > > or > > > A Client sends a 1 byte data and the sever closes the UDP session?\ > > > > There should be no limit to the number of bytes sent on a UDP socket; > > each SEND call is supposed to emit a separate UDP message that is > > completely unrelated to any other at the transport layer. > > > > An *application* can decide that an application-layer association is > > terminated when it receives a specific number of bytes or a specific > > response, but that's at the application layer. > > > > Overall, it seems like you're expecting TCP-like semantics from UDP. > > > > Joe > > > > From randy@qualcomm.com Wed Nov 23 11:36:18 2011 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C02B1F0C3C for ; Wed, 23 Nov 2011 11:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.104 X-Spam-Level: X-Spam-Status: No, score=-105.104 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snhzYfuFbGBY for ; Wed, 23 Nov 2011 11:36:17 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 846571F0C36 for ; Wed, 23 Nov 2011 11:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1322076977; x=1353612977; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20<1322033566.85092.YahooMailNeo@web160302. mail.bf1.yahoo.com>|References:=20<1321876878.89529.Yahoo MailNeo@web160305.mail.bf1.yahoo.com>=0D=0A=20<3D169D8C-E C79-4C65-9C4E-1554AE2F253D@isi.edu>=0D=0A=20<1321971419.5 9142.YahooMailNeo@web160301.mail.bf1.yahoo.com>=0D=0A=20< 4ECBF23D.4080401@isi.edu>=0D=0A=20<1322033566.85092.Yahoo MailNeo@web160302.mail.bf1.yahoo.com>|X-Mailer:=20Eudora =20for=20Mac=20OS=20X|Date:=20Wed,=2023=20Nov=202011=2011 :33:34=20-0800|To:=20deepak=20rajaram=20,=20Joe=20Touch=20|From:=20Randall=20G ellens=20|Subject:=20Re:=20[arch-d] =20UDP=20Client-Server=20Behavior|CC:=20"architecture-dis cuss@ietf.org"=20 |MIME-Version:=201.0|Content-Type:=20text/html=3B=20chars et=3D"us-ascii"|X-Random-Sig-Tag:=201.0b28 |X-Originating-IP:=20[172.30.39.5]; bh=X2v7Mk1FspN+YyhVSafjGcJQiZh6hgf+sPWzcwpWwIM=; b=HRm7mq9Apm2OCVK+JXkf4gt0etom56Wfz9hlt1CM9aG1izMfGCfJJY96 CwmVSRSe4iOrT3Edg90H6JDsVdikoEITg4EnreClElYLesXsT1bV4ITPx Em/MigCCTK4Fay+5Zdc3OZZzT7FdxLNf35CDjayxGbfmDESlQuTwhb8vx c=; X-IronPort-AV: E=McAfee;i="5400,1158,6539"; a="140423131" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 23 Nov 2011 11:36:06 -0800 X-IronPort-AV: E=Sophos;i="4.69,559,1315206000"; d="scan'208,217";a="119713409" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 23 Nov 2011 11:36:06 -0800 Received: from loud.pensive.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 23 Nov 2011 11:36:06 -0800 Message-ID: In-Reply-To: <1322033566.85092.YahooMailNeo@web160302.mail.bf1.yahoo.com> References: <1321876878.89529.YahooMailNeo@web160305.mail.bf1.yahoo.com> <3D169D8C-EC79-4C65-9C4E-1554AE2F253D@isi.edu> <1321971419.59142.YahooMailNeo@web160301.mail.bf1.yahoo.com> <4ECBF23D.4080401@isi.edu> <1322033566.85092.YahooMailNeo@web160302.mail.bf1.yahoo.com> X-Mailer: Eudora for Mac OS X Date: Wed, 23 Nov 2011 11:33:34 -0800 To: deepak rajaram , Joe Touch From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Cc: "architecture-discuss@ietf.org" Subject: Re: [arch-d] UDP Client-Server Behavior X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 19:36:18 -0000 Re: [arch-d] UDP Client-Server Behavior

At 11:32 PM -0800 11/22/11, deepak rajaram wrote:

I do understand the difference, however, i have seen some implementations where, if a "single byte" data is sent to a UDP port, it was treated as a session terminator and all possible clients/connections were terminated. I guess , like you said earlier, a TCP like semantics is tried here for UDP.

More specifically, that is application-level semantics.  UDP just sends data, there is no connection, no session, no initiation, no termination.  An application that uses UDP can define its own semantics which could include a message to terminate (for example, a particular data pattern, such as "END" or xFFFF or x0000, or even a particular size, such as the one-byte example you gave, although that does seem a bit limiting since it prevents you from using one-byte messages for anything else, but that's all up to you).


In my previous mail, what i meant by
UDP Server: A machine in which has a particular UDP service is running on a port to which UDP clients could send messages
UDP Client: Nothing but an application used to send messages to the UDP port on the server

What I was getting at in my questions is what are these UDP clients and where do they come from?  Presumably they are something specific to the application and hence they can do any special application-level semantics you want.


Thanks a lot for your replies.

Regards,
Deepak
From: Joe Touch <touch@isi.edu>
To: deepak rajaram <deepakpad@yahoo.com>
Cc: "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
Sent: Wednesday, November 23, 2011 12:34 AM
Subject: Re: [arch-d] UDP Client-Server Behavior

Hi, Deepak,

On 11/22/2011 6:16 AM, deepak rajaram wrote:
>
> Hi Joe,
> Thanks a lot for the reply,
>
> Regarding option 1: "send an application message that indicates the
> association has ended"
> If my understanding is correct, "All" available UDP clients should be in
> a position to interpret this message(session termination message) sent
> from my server, which might not be possible, is there any other generic
> way by which i could achieve this , which would allow the user to use
> "any" available UDP client??

TCP clients can connect to any TCP server, and TCP CLOSE indicates the
end of a connection.

UDP is a *message* protocol, not a connection protocol. There is no
state at the UDP layer to terminate, since none is ever established. The
state of a session has meaning only at the application layer, and so is
application-specific. There is no such thing as a universal UDP session
terminator.

If the difference isn't apparent, you need to seek a textbook, not this
mailing list.

Joe

> ------------------------------------------------------------------------
> *From:* Joe Touch <touch@isi.edu>
> *To:* deepak rajaram <deepakpad@yahoo.com>
> *Cc:* "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
> *Sent:* Monday, November 21, 2011 10:17 PM
> *Subject:* Re: [arch-d] UDP Client-Server Behavior
>
>
> On Nov 21, 2011, at 4:01 AM, deepak rajaram wrote:
>
>  > Hi,
>  >
>  > There are two questions on UDP sessions
>  >
>  > 1> I would like to know if there is any way to send a message to a
> UDP client "from" a server for disconnecting the session.
>  > While i do realize that a ICMP message could be sent by a server
> during port scan, That would be only on the server side. is there a
> possibility that a server could send out a message to the client to
> close the session?
>  >
>  > For Eg:
>  > -- A client tries to establish a session with source port x(on
> client) to a destination port y on a server
>  > -- The server should reply to x with some message for informing the
> client to disconnect the session
>
> UDP is connectionless and includes only demultiplexing information; it
> has no signaling. There are two options:
>
> 1) send an application message that indicates the association has ended
>
> 2) send an ICMP error that the port is no longer reachable
>
> (2) might legitimately be interpreted as terminating all application
> sessions to that UDP port, though - it's not source port/destination
> port specific.
>
> (1) is the only safe option
>
>  > 2> Is there any limit on the number of bytes to be sent on a UDP
> socket, i have seen implementations where, a single byte data will
> disconnect the session, can this logic be used to achive the above point?
>  >
>  > Eg:
>  > A Server sends a 1 byte data to client and the client closes the session?
>  > or
>  > A Client sends a 1 byte data and the sever closes the UDP session?\
>
> There should be no limit to the number of bytes sent on a UDP socket;
> each SEND call is supposed to emit a separate UDP message that is
> completely unrelated to any other at the transport layer.
>
> An *application* can decide that an application-layer association is
> terminated when it receives a specific number of bytes or a specific
> response, but that's at the application layer.
>
> Overall, it seems like you're expecting TCP-like semantics from UDP.
>
> Joe
>

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss


--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If you lend someone $20, and never see that person again,
it was probably worth it.
From bernard_aboba@hotmail.com Wed Nov 23 12:41:01 2011 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C141211E8108 for ; Wed, 23 Nov 2011 12:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cTz+Y18mCfo for ; Wed, 23 Nov 2011 12:41:01 -0800 (PST) Received: from blu0-omc2-s2.blu0.hotmail.com (blu0-omc2-s2.blu0.hotmail.com [65.55.111.77]) by ietfa.amsl.com (Postfix) with ESMTP id E98D611E80A0 for ; Wed, 23 Nov 2011 12:41:00 -0800 (PST) Received: from BLU152-W33 ([65.55.111.73]) by blu0-omc2-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Nov 2011 12:40:55 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_b8f2eb4a-88a2-46f1-82ff-2c7bc53d6a16_" X-Originating-IP: [131.107.0.109] From: Bernard Aboba To: Date: Wed, 23 Nov 2011 12:40:55 -0800 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2011 20:40:55.0799 (UTC) FILETIME=[32FC9070:01CCAA20] Subject: [arch-d] IAB Document Status X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 20:41:01 -0000 --_b8f2eb4a-88a2-46f1-82ff-2c7bc53d6a16_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As noted in the IETF 82 IAB Report (see http://www.ietf.org/proceedings/82= /slides/plenaryt-1.ppt)=2C the IAB is currently working on several documen= ts.=20 A summary of the status of these documents is provided below.=20 IAB Document status =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In the RFC Editor Queue: http://tools.ietf.org/html/draft-iab-privacy-workshop In "Call for IAB Approval" (on November 30 IAB Agenda) http://tools.ietf.org/html/draft-iab-smart-object-workshop Completed "Call for Comment": Revision pending http://tools.ietf.org/html/draft-iab-extension-recs http://tools.ietf.org/html/draft-iab-rfc-editor-model-v2 In "Call for Comment"=20 http://tools.ietf.org/html/draft-iab-ise-model (expires November 26) http://tools.ietf.org/html/draft-iab-anycast-arch-implications (expires Dec= ember 9) IAB Work Items http://tools.ietf.org/html/draft-iab-privacy-considerations http://tools.ietf.org/html/draft-iab-dns-applications http://tools.ietf.org/html/draft-iab-identifier-comparison Independent Submissions http://tools.ietf.org/html/draft-hansen-privacy-terminology Submitting Issues on IAB Documents =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Issues with IAB documents are kept in TRAC. =20 Issue can be submitted via the following form: http://trac.tools.ietf.org/g= roup/iab/trac/newticket Information on the status of submitted issues is available here: =20 http://trac.tools.ietf.org/group/iab/trac/report/1 Mailing lists for Discussion of IAB Documents =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Discussion of IAB documents occurs on several mailing lists. In addition t= o the Architecture-Discuss mailing list (the default mailing list)=2C some = more specific mailing lists exist.=20 Documents relating to the IAB Privacy Program (e.g. draft-iab-privacy-works= hop=2C draft-iab-privacy-considerations=2C draft-hansen-privacy-terminology= ) are discussed on the IETF-Privacy list (ietf-privacy@ietf.org). To subscr= ibe and gain posting rights=2C see: https://www.ietf.org/mailman/listinfo/i= etf-privacy Documents relating to the RFC Editor Program (e.g. draft-iab-rfc-editor-mod= el-v2 and draft-iab-ise-model) are discussed on the RFC-Interest list (rfc-= interest@rfc-editor.org). To subscribe and gain posting rights=2C see: http= s://www.rfc-editor.org/mailman/listinfo/rfc-interest=20 Documents relating to the IAB Internationalization Program (e.g. draft-iab-= identifier-comparison) are discussed on the Internationalization-Discuss ma= iling list (i18n-discuss@ietf.org). To subscribe and gain posting rights= =2C see:=20 https://www.iab.org/mailman/listinfo/i18n-discuss = --_b8f2eb4a-88a2-46f1-82ff-2c7bc53d6a16_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As noted in the IETF 82 IAB Report (see =3B http://www.ietf.org/proceed= ings/82/slides/plenaryt-1.ppt)=2C =3B the IAB is currently working on s= everal documents.

A summary of the status of these documents is pro= vided below.

IAB Document status
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

In the RFC Editor Queue:
http://to= ols.ietf.org/html/draft-iab-privacy-workshop

In "Call for IAB Approv= al" (on November 30 IAB Agenda)
http://tools.ietf.org/html/draft-iab-sma= rt-object-workshop

Completed "Call for Comment": =3B Revision pe= nding
http://tools.ietf.org/html/draft-iab-extension-recs
http://tool= s.ietf.org/html/draft-iab-rfc-editor-model-v2

In "Call for Comment" =
http://tools.ietf.org/html/draft-iab-ise-model (expires November 26)http://tools.ietf.org/html/draft-iab-anycast-arch-implications (expires De= cember 9)

IAB Work Items
http://tools.ietf.org/html/draft-iab-pri= vacy-considerations
http://tools.ietf.org/html/draft-iab-dns-application= s
http://tools.ietf.org/html/draft-iab-identifier-comparison

Inde= pendent Submissions
http://tools.ietf.org/html/draft-hansen-privacy-term= inology

Submitting Issues on IAB Documents
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Issues with IAB = documents are kept in TRAC. =3B =3B

Issue can be submitted = via the following form: http://trac.tools.ietf.org/group/iab/trac/newticket=

Information on the status of submitted issues is =3B available = here: =3B=20 http://trac.tools.ietf.org/group/iab/trac/report/1

Mailing lists for= Discussion of IAB Documents
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Discussion of IAB docu= ments occurs on several mailing lists. =3B In addition to the Architect= ure-Discuss mailing list (the default mailing list)=2C some more specific m= ailing lists exist.

Documents relating to the IAB Privacy Program (= e.g. draft-iab-privacy-workshop=2C draft-iab-privacy-considerations=2C draf= t-hansen-privacy-terminology) are discussed on the IETF-Privacy list (ietf-= privacy@ietf.org). To subscribe and gain posting rights=2C see: https://www= .ietf.org/mailman/listinfo/ietf-privacy

Documents relating to the RF= C Editor Program (e.g. draft-iab-rfc-editor-model-v2 and draft-iab-ise-mode= l) are discussed on the RFC-Interest list (rfc-interest@rfc-editor.org). To= subscribe and gain posting rights=2C see: https://www.rfc-editor.org/mailm= an/listinfo/rfc-interest

Documents relating to the IAB Internationa= lization Program (e.g. draft-iab-identifier-comparison) are discussed on th= e Internationalization-Discuss mailing list (i18n-discuss@ietf.org). = =3B To subscribe and gain posting rights=2C see:
https://www.iab.org/mai= lman/listinfo/i18n-discuss






= --_b8f2eb4a-88a2-46f1-82ff-2c7bc53d6a16_-- From bernard_aboba@hotmail.com Thu Nov 24 11:49:25 2011 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE97C11E8080 for ; Thu, 24 Nov 2011 11:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRnUp8Fq08C0 for ; Thu, 24 Nov 2011 11:49:25 -0800 (PST) Received: from blu0-omc2-s11.blu0.hotmail.com (blu0-omc2-s11.blu0.hotmail.com [65.55.111.86]) by ietfa.amsl.com (Postfix) with ESMTP id DBAAA11E8073 for ; Thu, 24 Nov 2011 11:49:24 -0800 (PST) Received: from BLU152-W24 ([65.55.111.72]) by blu0-omc2-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Nov 2011 11:49:21 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_67508ab9-d2b2-46ff-9c90-5cff57e1b0a3_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Thu, 24 Nov 2011 11:49:20 -0800 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 24 Nov 2011 19:49:21.0002 (UTC) FILETIME=[28C1C4A0:01CCAAE2] Subject: [arch-d] Follow-on questions from the "Internet of Things" discussion on Monday (fwd) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 19:49:26 -0000 --_67508ab9-d2b2-46ff-9c90-5cff57e1b0a3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > ---------- Forwarded message ---------- > Date: Thu=2C 17 Nov 2011 00:22:20 -0800 > From: Charles E. Perkins > To: arch-discuss@iab.org > Cc: "Tschofenig=2C Hannes (NSN - DE/Germany - MiniMD)" > =2C Zach Shelby =2C > Bernard Aboba =2C Jari Arkko =2C > Fred Baker > Subject: Follow-on questions from the "Internet of Things" discussion on = Monday >=20 >=20 > Hello folks=2C >=20 > Very interesting discussion on Monday. I asked some questions > but had a dozen more. Some were resolved later in the week. > Here are a few more. >=20 > - Carsten campaigned against garrulity and fluff. For people > attempting to adhere to a modular design discipline=2C both > garrulity and fluff are difficult to avoid. For designs > that are intended to be extensible=2C garrulity is almost > guaranteed=2C and fluff will be in the eye of the beholder. >=20 > These are generalities. Has anyone thought of specifics > from the problem domain to combat them? >=20 > - Comments on 3GPP's M2M work? Does anyone on the panel > foresee any application for it in the Internet of Things? >=20 > - Mobility: The answer from one knowledgeable source was that > "good" applications don't depend on any particular IP address. > Presumably they anchor device context in some way. Must each > solution be different? Must the namespace for the endpoints > of each IoT application be separate? >=20 > No surprise: I claim that traveling down the path of > per-application mobility is simply begging for bugs as > each new domain of expertise relives the horrors of the > developers in the previous domain. Painful shock #1: > security. For "too many" devices=2C painful shocks are > likely to arrive from all directions. >=20 > - Jari Arkko praised the benefits of single-hop hub-and-spoke > architectures. Sounds great for the home or perhaps even > for the apartment house but not for IoT in the general case > for the canonical list of reasons. Would the IAB care to > produce guidance on this matter? It has come up in various > disguises all too many times. >=20 > Regards=2C > Charlie P. >=20 > PS. I don't know if this is the proper mailing list=3B if not=2C > please direct me to the proper place. >=20 >=20 >=20 >=20 >=20 >=20 = --_67508ab9-d2b2-46ff-9c90-5cff57e1b0a3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B ---------- Forwarded message ----------
>=3B Date: Thu= =2C 17 Nov 2011 00:22:20 -0800
>=3B From: Charles E. Perkins <=3Bcha= rles.perkins@earthlink.net>=3B
>=3B To: arch-discuss@iab.org
>= =3B Cc: "Tschofenig=2C Hannes (NSN - DE/Germany - MiniMD)"
>=3B &= lt=3Bhannes.tschofenig@nsn.com>=3B=2C Zach Shelby <=3Bzach@sensinode.co= m>=3B=2C
>=3B Bernard Aboba <=3Baboba@internaut.com>=3B=2C = Jari Arkko <=3Bjari.arkko@piuha.net>=3B=2C
>=3B Fred Baker &l= t=3Bfred@cisco.com>=3B
>=3B Subject: Follow-on questions from the "I= nternet of Things" discussion on Monday
>=3B
>=3B
>=3B Hel= lo folks=2C
>=3B
>=3B Very interesting discussion on Monday. I = asked some questions
>=3B but had a dozen more. Some were resolved la= ter in the week.
>=3B Here are a few more.
>=3B
>=3B - Cars= ten campaigned against garrulity and fluff. For people
>=3B attemp= ting to adhere to a modular design discipline=2C both
>=3B garrulit= y and fluff are difficult to avoid. For designs
>=3B that are inte= nded to be extensible=2C garrulity is almost
>=3B guaranteed=2C and= fluff will be in the eye of the beholder.
>=3B
>=3B These ar= e generalities. Has anyone thought of specifics
>=3B from the prob= lem domain to combat them?
>=3B
>=3B - Comments on 3GPP's M2M wo= rk? Does anyone on the panel
>=3B foresee any application for it i= n the Internet of Things?
>=3B
>=3B - Mobility: The answer from = one knowledgeable source was that
>=3B "good" applications don't de= pend on any particular IP address.
>=3B Presumably they anchor devi= ce context in some way. Must each
>=3B solution be different? Mus= t the namespace for the endpoints
>=3B of each IoT application be s= eparate?
>=3B
>=3B No surprise: I claim that traveling down t= he path of
>=3B per-application mobility is simply begging for bugs= as
>=3B each new domain of expertise relives the horrors of the>=3B developers in the previous domain. Painful shock #1:
>=3B = security. For "too many" devices=2C painful shocks are
>=3B lik= ely to arrive from all directions.
>=3B
>=3B - Jari Arkko praise= d the benefits of single-hop hub-and-spoke
>=3B architectures. Sou= nds great for the home or perhaps even
>=3B for the apartment house= but not for IoT in the general case
>=3B for the canonical list of= reasons. Would the IAB care to
>=3B produce guidance on this matt= er? It has come up in various
>=3B disguises all too many times.>=3B
>=3B Regards=2C
>=3B Charlie P.
>=3B
>=3B PS= . I don't know if this is the proper mailing list=3B if not=2C
>=3B = please direct me to the proper place.
>=3B
>=3B
>=3B >=3B
>=3B
>=3B
= --_67508ab9-d2b2-46ff-9c90-5cff57e1b0a3_--