From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Dec 2 00:47:25 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25178 for ; Mon, 2 Dec 2002 00:47:24 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB25Zp0R012129 for ; Sun, 1 Dec 2002 21:35:51 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB25Zc4V027980 for ; Sun, 1 Dec 2002 21:35:38 -0800 (PST) Received: from hindon.hss.co.in ([202.54.26.202]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gB25ZnrS008848 for ; Sun, 1 Dec 2002 21:35:50 -0800 (PST) Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gB24vUr02666 for ; Mon, 2 Dec 2002 10:27:30 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gB24vT802662; Mon, 2 Dec 2002 10:27:29 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gB24xFS08206; Mon, 2 Dec 2002 10:29:15 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C83.001AB1F3 ; Mon, 2 Dec 2002 10:21:34 +0530 X-Lotus-FromDomain: HSS From: mrajpal@hss.hns.com To: "Randall Stewart (cisco)" cc: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Message-ID: <65256C83.001AB1DF.00@sandesh.hss.hns.com> Date: Mon, 2 Dec 2002 10:26:04 +0530 Subject: Re: Multihoming with NAT Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=fMhWvoejTfS3u8ZnxO5hPSDlJFflXZnnZb3gBJMXRfCxrpMnHrnOkHkr" Content-Disposition: inline --0__=fMhWvoejTfS3u8ZnxO5hPSDlJFflXZnnZb3gBJMXRfCxrpMnHrnOkHkr Content-type: text/plain; charset=us-ascii Content-Disposition: inline hi randall, Yes I agree that effective arrangement will be the frst one, where you have two external addresses. To initiate the session and create bindings, the NAT will have to be aware of the SCTP packet format so that it can identify the INIT chunk and reserve a port , if this is the case then one just needs an ALG that will instruct ALL of the NATs to create bindings with the session parameters and establish state for that session. Not expecting much from either NAT or the ALG!!!. host A ----------------------nat1-----------------ISP1 |(IP A) (IP x1) +--------------------------nat2 -------------------- (IP x2) So when a INIT chunk orginating form host A with source address in IP header A, reaches nat1, (or nat2 for that matter), the ALG instructs both the NATs to create bindings . Now the packets recieved from peer at either x1 or x2 will be correcty routed to host A. The INIT chunk can not advertise the addresses x1 and x2 beacuse they originated from the host A. So having a hostname that resolves to x1 and x2 is the probale solution. Another thing that is possble is expecting the ALG to modify the chunk and add/modify the addresses in it, but this would require complete parsing, modifying and then recalculating the checksum for the packet. Too much to ask for from an ALG. If the NAT is not SCTP Aware, the sessions will be initiated and closed based on heuristic algorithms. the state at NAT will not be based on the port numbers. Any packet from host A can initiate the session which will be purely based on the source and destination IP address. So if the peer is multihomed that will mean multiple states for the same session at the single NAT. I still don't see any issues with having multihomed association where x1 and x2 both can be used as local addresses. Again all that is required is a hostname. regards manish www.hssworld.com "Randall Stewart (cisco)" on 11/29/2002 06:51:14 AM To: Manish Rajpal/HSS@HSS cc: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Multihoming with NAT Manish: I think you miss my point... To have an effective NAT arrangement where multi-homing is going (i.e. you want no single point of failure): host -------nat1 ------ISP1 | +----------nat2-------ISP2 Having host -----net1----NAT-------ISP | | +----------net2----+ makes two different single points of failure .. aka the NAT itself as well as your ISP Moving the two ISPs to talk to one NAT does not help since you still have a single point of failure.. and it does not work anyway.. Most nats can only handle translating to one address... I have this arrangment in my own router/nat box... It has two ISP's hooked to it and I must run two different instances of the nat software.. one for one interface and the other for the second... these two do NOT know how to communicate about the two networks...This is what is hard.. you must get the NAT's to talk to each other and reserve the SAME port on two seperate networks and setup state. There may be some nat software out there that can handle two networks but this is the rarity if it even exits... Yes it can work.. without this.. but not with multihoming in the picture.. except maybe behind the nat (my second drawing).. and in this case it does not really help you that much ... and one can just do the send the INIT with no addresses... I don't see how you could get any benefit of the two internal addresses without external addresses to go with them... Remember a SCTP association is only on ONE port and a NAT uses the ports to find the state... So my second picture gets NO benefit and the second requires intra-nat communications... And if you really wanted it done right you would need to have the nats on seperate boxes with a intra-nat communication protocol so you would have no single point of failure.. not one nat controlling two addresses... which I don't know if it even exits.... R mrajpal@hss.hns.com wrote: > >hi > >No! you don't need a SCTP aware NAT, lets suppose NAT has two addresses, then >both these addresses can be used for the association. The packets sent by the >peer to any of these addresses will be routed to the sctp host which has got a >single address. So u have a multihomed association without the host having more >than one address. >about the misbehaving routers, i'ld like say that its the multihoming that comes >to rescue when you have diffrent addresses belonging to different networks, So >while one network is not in good health the packets can take diffrent route to >reach destination. >Its just that the INIT/INIT ACK chunks that communicate the addresses to the >peer and if we can send a hostname, we can create the multi-homed association. >Only restrition I see is dynamically adding or delteting IP addresses from such >an association. > >And if NAT is sctp aware, which is least likely, you don't even need the >hostname as the NAT can itself translate the addresses in INIT/INIT-ACK. >So we don't require anything new from existing NAT box, all that is required is >to send a hostname in the INIT/ INIT ACK that will be resolved to the >address(es) of NAT. So probably a new interface that allows a user to specify a >hostname for a socket to bind to. If the NAT io > >regards >manish >www.hssworld.com > > > > > >Ivan.Arias-Rodriguez@nokia.com on 11/28/2002 06:03:35 PM > >To: Manish Rajpal/HSS@HSS, rrs@cisco.com >cc: sctp-impl@external.cisco.com > >Subject: RE: Multihoming with NAT > > > > > Hi! > > > >>hi, >> >>I don't think so, multihoming can work very well behind a NAT >>too. if NAT can >>translate one address, it can translate n addresses. I don't >> >> > > I think this is precisely the problem... NATs don't know anything about >SCTP, so at most they can translate the source address of the IP packet. All the >deployed NATs are not ready to recognize Protocol Number 132 and then look >inside every of such packets and recognize an INIT/INT ACK chunk, so it can dig >inside the packet and recognize de address parameters... > > Of course, if you re-code a NAT to do such thing, I think it would work... >:-/ But, who is the one that is going to re-code all the existing NATs...? > > Besides, I don't really think that having multihoming while being behind a >NAT is really anything useful... I'm not an expert, but I would say that you >normally have only one NAT that is "covering" a stub domain. It means that all >the packets have to go anyway through the NAT... Well, you can always have >several netwok cards, and then multihoming would prevent failure if one of the >cards itself fails, but it won't prevent about misbehaving routers in the way... > > > >>foresee any issue. >>In fact, with NAT, its possible that a host running sctp and >>having single >>address can appear as a multihomed host to the peer. Only NAT >>box has to Map >>both the external addresses to a single internal address. >> >> > > But it has to be able to do so... which is not true so far... > > BR Iv > >------------------------------------------------------------------------ > > > --0__=fMhWvoejTfS3u8ZnxO5hPSDlJFflXZnnZb3gBJMXRfCxrpMnHrnOkHkr Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =E1n Arias Rodr=EDguez > > > >>regards >>manish >>www.hssworld.com >> >> >> >> >>"Randall Stewart (cisco)" on 11/28/2002 01:09:00 AM >> >>To: Manish Rajpal/HSS@HSS >>cc: sctp-impl@external.cisco.com >> >>Subject: Re: Multihoming with NAT >> >> >> >> >>Doing this in the kernel is very very difficult.. (see my >>earlier email on >>this subject). >> >>To get by a nat one can always just send a INIT with no addresses... >>After all multi-homing behind a NAT is not going to work anyway.. >> >>R >> >>mrajpal@hss.hns.com wrote: >> >> >> >>>Hi >>> >>>The socket draft - 04 no-where specifies an option for user >>> >>> >>to provide a >> >> >>>hostname for an address. This >>>creates a problem when a multi-homed endpoint is behind a >>> >>> >>NAT. As discussed in >> >> >>>sctp applicabilty >>>statement, this requires a hostname to be sent in INIT/INIT ack. >>>My question is how to get a hostname for the address >>> >>> >>provided in sctp-socket >> >> >>>interface. >>> >>>regards >>>manish >>>www.hssworld.com >>> >>>DISCLAIMER: This message is proprietary to Hughes Software Systems >>>Limited (HSS) and is intended solely for the use of the individual >>>to whom it is addressed. It may contain privileged or confidential >>>information and should not be circulated or used for any >>> >>> >>purpose other >> >> >>>than for what it is intended. If you have received this >>> >>> >>message in error, >> >> >>>please notify the originator immediately. If you are not the intende= d >>>recipient, you are notified that you are strictly prohibited >>> >>> >>from using, >> >> >>>copying, altering, or disclosing the contents of this >>> >>> >>message. HSS accepts >> >> >>>no responsibility for loss or damage arising from the use of >>> >>> >>the information >> >> >>>transmitted by this email including damage from virus. >>> >>> >>> >>> >>> >>> >>> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >> >> >> >> >> >> >> >> > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) = --0__=fMhWvoejTfS3u8ZnxO5hPSDlJFflXZnnZb3gBJMXRfCxrpMnHrnOkHkr-- From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Dec 2 01:32:49 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25863 for ; Mon, 2 Dec 2002 01:32:47 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB26Ro0J028063 for ; Sun, 1 Dec 2002 22:27:50 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB26S7pf000391 for ; Sun, 1 Dec 2002 22:28:07 -0800 (PST) Received: from hindon.hss.co.in ([202.54.26.202]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gB26RwrS018127 for ; Sun, 1 Dec 2002 22:28:00 -0800 (PST) Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gB25ner11363 for ; Mon, 2 Dec 2002 11:19:40 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gB25nd811359; Mon, 2 Dec 2002 11:19:39 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gB25pQi12020; Mon, 2 Dec 2002 11:21:26 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C83.001F79E6 ; Mon, 2 Dec 2002 11:13:48 +0530 X-Lotus-FromDomain: HSS From: mrajpal@hss.hns.com To: Ivan.Arias-Rodriguez@nokia.com cc: sctp-impl@external.cisco.com Message-ID: <65256C83.001F7965.00@sandesh.hss.hns.com> Date: Mon, 2 Dec 2002 11:18:16 +0530 Subject: RE: Multihoming with NAT Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=yRG6AEUPwMUwcGHME7vqcUwz0ZMEQVuc11ErpkyVXP5U4ed3HY1IQrEr" Content-Disposition: inline --0__=yRG6AEUPwMUwcGHME7vqcUwz0ZMEQVuc11ErpkyVXP5U4ed3HY1IQrEr Content-type: text/plain; charset=us-ascii Content-Disposition: inline hi, see my comments [MR], regards manish www.hssworld.com Ivan.Arias-Rodriguez@nokia.com on 11/28/2002 07:40:42 PM To: Manish Rajpal/HSS@HSS cc: rrs@cisco.com, sctp-impl@external.cisco.com Subject: RE: Multihoming with NAT Hi! > hi > > No! you don't need a SCTP aware NAT, lets suppose NAT has two > addresses, then > both these addresses can be used for the association. The > packets sent by the > peer to any of these addresses will be routed to the sctp > host which has got a > single address. So u have a multihomed association without > the host having more > than one address. I must confess that I really never completely understood how NATs and DNS are compatible... NATs allocate address for the use of a host during a certain time... so, are NATs changing DNS entries every time they assign different addresses to different hosts? And they have to do this so everybody can know... I don't really know how this can work... :-/ Unless DNS entries are only given to "static" hosts that have regular access to the "outside world" and that always use the same addresses... [MR] its just that when the internal hosts do a lookup, these names will be resolved to internal addresses. But if the hostname is resolved outside the current realm, the addresses obtained must a be subset of the external addresses that NAT has. The host name resolution will be based on the address realm. > about the misbehaving routers, i'ld like say that its the > multihoming that comes > to rescue when you have diffrent addresses belonging to > different networks, So > while one network is not in good health the packets can take > diffrent route to > reach destination. But at the end, all the packets have to go to the same destination: the NAT. Well, the NAT can be connected easily to different networks... yes you are right... [MR]I haven't come across many NAT boxess, I am not sure if its that really easy. > Its just that the INIT/INIT ACK chunks that communicate the > addresses to the > peer and if we can send a hostname, we can create the > multi-homed association. Could you please quickly explain me how DNS and NATs are compatible? I just don't know and feel lazy to check RFCs... :-) [MR] only RFC 2694 would help > Only restrition I see is dynamically adding or delteting IP > addresses from such > an association. Yes, that's right... Unless you change the DNS entry and then you send in the ASCONF not the IP address but the host name... I don't think anybody would support this... and I don't think it is feasible either... [MR] The draft does not allow you to send hostname in ASCONF chunk. > And if NAT is sctp aware, which is least likely, you don't > even need the > hostname as the NAT can itself translate the addresses in > INIT/INIT-ACK. > So we don't require anything new from existing NAT box, all > that is required is > to send a hostname in the INIT/ INIT ACK that will be resolved to the > address(es) of NAT. So probably a new interface that allows a > user to specify a > hostname for a socket to bind to. If the NAT io Seems that the message was truncated... BR Iv --0__=yRG6AEUPwMUwcGHME7vqcUwz0ZMEQVuc11ErpkyVXP5U4ed3HY1IQrEr Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =E1n Arias Rodr=EDguez > regards > manish > www.hssworld.com > > > > > > Ivan.Arias-Rodriguez@nokia.com on 11/28/2002 06:03:35 PM > > To: Manish Rajpal/HSS@HSS, rrs@cisco.com > cc: sctp-impl@external.cisco.com > > Subject: RE: Multihoming with NAT > > > > > Hi! > > > hi, > > > > I don't think so, multihoming can work very well behind a NAT > > too. if NAT can > > translate one address, it can translate n addresses. I don't > > I think this is precisely the problem... NATs don't know > anything about > SCTP, so at most they can translate the source address of the > IP packet. All the > deployed NATs are not ready to recognize Protocol Number 132 > and then look > inside every of such packets and recognize an INIT/INT ACK > chunk, so it can dig > inside the packet and recognize de address parameters... > > Of course, if you re-code a NAT to do such thing, I > think it would work... > :-/ But, who is the one that is going to re-code all the > existing NATs...? > > Besides, I don't really think that having multihoming > while being behind a > NAT is really anything useful... I'm not an expert, but I > would say that you > normally have only one NAT that is "covering" a stub domain. > It means that all > the packets have to go anyway through the NAT... Well, you > can always have > several netwok cards, and then multihoming would prevent > failure if one of the > cards itself fails, but it won't prevent about misbehaving > routers in the way... > > > foresee any issue. > > In fact, with NAT, its possible that a host running sctp and > > having single > > address can appear as a multihomed host to the peer. Only NAT > > box has to Map > > both the external addresses to a single internal address. > > But it has to be able to do so... which is not true so far... > > BR Iv > = --0__=yRG6AEUPwMUwcGHME7vqcUwz0ZMEQVuc11ErpkyVXP5U4ed3HY1IQrEr-- From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Dec 2 12:17:55 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26889 for ; Mon, 2 Dec 2002 12:17:54 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB2HALcb014430 for ; Mon, 2 Dec 2002 09:10:21 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB2HAKiX028569 for ; Mon, 2 Dec 2002 09:10:20 -0800 (PST) Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gB2HAJfw003341 for ; Mon, 2 Dec 2002 09:10:20 -0800 (PST) Received: by smtp.ss8.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Dec 2002 12:06:11 -0500 Message-ID: <8BAF8B40C4D2D411ADC300508BD63D69020A6A29@smtp.ss8.com> From: Serkan Cil To: "'Randall Stewart (cisco)'" , mrajpal@hss.hns.com Cc: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: RE: Multihoming with NAT Date: Mon, 2 Dec 2002 12:06:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Hi, If we do not insist on IP multiplexing it is still possible to support MH behind a NAT. NAT boxes can do static address mapping between the global and local address spaces. This does not require any information (port etc.) from the protocol carried in IP packet. It is a simple address mapping operation. Also NAT can work with a pool of global addresses and a pool of local addresses. So following scenario seems possible if we configure the nat1 and nat2 to do just the address mapping. We are basically reserving global addresses IP1' and IP2' for IP1 and IP2 mapping. "host" needs to send the INIT with hostname param. (which is mapped to IP1' and IP2' in DNS or else) IP1 IP1' host -------nat1 ------ISP1 | +----------nat2-------ISP2 IP2 IP2' Serkan > -----Original Message----- > From: Randall Stewart (cisco) [mailto:rrs@cisco.com] > Sent: Thursday, November 28, 2002 8:21 PM > To: mrajpal@hss.hns.com > Cc: Ivan.Arias-Rodriguez@nokia.com; sctp-impl@external.cisco.com > Subject: Re: Multihoming with NAT > > > Manish: > > > I think you miss my point... > > To have an effective NAT arrangement where multi-homing is going (i.e. > you want no single point of failure): > > > host -------nat1 ------ISP1 > | > +----------nat2-------ISP2 > > Having > > host -----net1----NAT-------ISP > | | > +----------net2----+ > > makes two different single points of failure .. aka the > NAT itself as well as your ISP > > Moving the two ISPs to talk to one NAT does not > help since you still have a single point of failure.. and it does not > work anyway.. Most nats can only handle translating to one > address... I have > this arrangment in my own router/nat box... It has two ISP's > hooked to > it and > I must run two different instances of the nat software.. one for one > interface > and the other for the second... these two do NOT know how to > communicate > about the two networks...This is what is hard.. you must get > the NAT's to > talk to each other and reserve the SAME port on two seperate networks > and setup state. There may be some nat software out there that can > handle two networks but this is the rarity if it even exits... > > Yes it can work.. without this.. but not with multihoming in the > picture.. except maybe > behind the nat (my second drawing).. and in this case it does > not really > help you > that much ... and one can just do the send the INIT with no > addresses... > I don't > see how you could get any benefit of the two internal > addresses without > external > addresses to go with them... Remember a SCTP association is > only on ONE port > and a NAT uses the ports to find the state... So my second > picture gets > NO benefit > and the second requires intra-nat communications... And if > you really wanted > it done right you would need to have the nats on seperate boxes with a > intra-nat communication protocol so you would have no single point of > failure.. > not one nat controlling two addresses... which I don't know > if it even > exits.... > > R > > > mrajpal@hss.hns.com wrote: > > > > >hi > > > >No! you don't need a SCTP aware NAT, lets suppose NAT has > two addresses, then > >both these addresses can be used for the association. The > packets sent by the > >peer to any of these addresses will be routed to the sctp > host which has got a > >single address. So u have a multihomed association without > the host having more > >than one address. > >about the misbehaving routers, i'ld like say that its the > multihoming that comes > >to rescue when you have diffrent addresses belonging to > different networks, So > >while one network is not in good health the packets can take > diffrent route to > >reach destination. > >Its just that the INIT/INIT ACK chunks that communicate the > addresses to the > >peer and if we can send a hostname, we can create the > multi-homed association. > >Only restrition I see is dynamically adding or delteting IP > addresses from such > >an association. > > > >And if NAT is sctp aware, which is least likely, you don't > even need the > >hostname as the NAT can itself translate the addresses in > INIT/INIT-ACK. > >So we don't require anything new from existing NAT box, all > that is required is > >to send a hostname in the INIT/ INIT ACK that will be resolved to the > >address(es) of NAT. So probably a new interface that allows > a user to specify a > >hostname for a socket to bind to. If the NAT io > > > >regards > >manish > >www.hssworld.com > > > > > > > > > > > >Ivan.Arias-Rodriguez@nokia.com on 11/28/2002 06:03:35 PM > > > >To: Manish Rajpal/HSS@HSS, rrs@cisco.com > >cc: sctp-impl@external.cisco.com > > > >Subject: RE: Multihoming with NAT > > > > > > > > > > Hi! > > > > > > > >>hi, > >> > >>I don't think so, multihoming can work very well behind a NAT > >>too. if NAT can > >>translate one address, it can translate n addresses. I don't > >> > >> > > > > I think this is precisely the problem... NATs don't > know anything about > >SCTP, so at most they can translate the source address of > the IP packet. All the > >deployed NATs are not ready to recognize Protocol Number 132 > and then look > >inside every of such packets and recognize an INIT/INT ACK > chunk, so it can dig > >inside the packet and recognize de address parameters... > > > > Of course, if you re-code a NAT to do such thing, I > think it would work... > >:-/ But, who is the one that is going to re-code all the > existing NATs...? > > > > Besides, I don't really think that having multihoming > while being behind a > >NAT is really anything useful... I'm not an expert, but I > would say that you > >normally have only one NAT that is "covering" a stub domain. > It means that all > >the packets have to go anyway through the NAT... Well, you > can always have > >several netwok cards, and then multihoming would prevent > failure if one of the > >cards itself fails, but it won't prevent about misbehaving > routers in the way... > > > > > > > >>foresee any issue. > >>In fact, with NAT, its possible that a host running sctp and > >>having single > >>address can appear as a multihomed host to the peer. Only NAT > >>box has to Map > >>both the external addresses to a single internal address. > >> > >> > > > > But it has to be able to do so... which is not true so far... > > > > BR Iv > > > >------------------------------------------------------------- > ----------- > > > > > >án Arias Rodríguez > > > > > > > >>regards > >>manish > >>www.hssworld.com > >> > >> > >> > >> > >>"Randall Stewart (cisco)" on 11/28/2002 01:09:00 AM > >> > >>To: Manish Rajpal/HSS@HSS > >>cc: sctp-impl@external.cisco.com > >> > >>Subject: Re: Multihoming with NAT > >> > >> > >> > >> > >>Doing this in the kernel is very very difficult.. (see my > >>earlier email on > >>this subject). > >> > >>To get by a nat one can always just send a INIT with no addresses... > >>After all multi-homing behind a NAT is not going to work anyway.. > >> > >>R > >> > >>mrajpal@hss.hns.com wrote: > >> > >> > >> > >>>Hi > >>> > >>>The socket draft - 04 no-where specifies an option for user > >>> > >>> > >>to provide a > >> > >> > >>>hostname for an address. This > >>>creates a problem when a multi-homed endpoint is behind a > >>> > >>> > >>NAT. As discussed in > >> > >> > >>>sctp applicabilty > >>>statement, this requires a hostname to be sent in INIT/INIT ack. > >>>My question is how to get a hostname for the address > >>> > >>> > >>provided in sctp-socket > >> > >> > >>>interface. > >>> > >>>regards > >>>manish > >>>www.hssworld.com > >>> > >>>DISCLAIMER: This message is proprietary to Hughes Software Systems > >>>Limited (HSS) and is intended solely for the use of the individual > >>>to whom it is addressed. It may contain privileged or confidential > >>>information and should not be circulated or used for any > >>> > >>> > >>purpose other > >> > >> > >>>than for what it is intended. If you have received this > >>> > >>> > >>message in error, > >> > >> > >>>please notify the originator immediately. If you are not > the intended > >>>recipient, you are notified that you are strictly prohibited > >>> > >>> > >>from using, > >> > >> > >>>copying, altering, or disclosing the contents of this > >>> > >>> > >>message. HSS accepts > >> > >> > >>>no responsibility for loss or damage arising from the use of > >>> > >>> > >>the information > >> > >> > >>>transmitted by this email including damage from virus. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>-- > >>Randall R. Stewart > >>ITD > >>Cisco Systems Inc. > >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Dec 2 12:22:46 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27176 for ; Mon, 2 Dec 2002 12:22:45 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB2HGB0R024820; Mon, 2 Dec 2002 09:16:11 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAX55069; Mon, 2 Dec 2002 09:16:12 -0800 (PST) Message-ID: <3DEB954A.3060904@cisco.com> Date: Mon, 02 Dec 2002 11:15:54 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mrajpal@hss.hns.com CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Multihoming with NAT References: <65256C83.001AB1DF.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit mrajpal@hss.hns.com wrote: > >hi randall, >Yes I agree that effective arrangement will be the frst one, where you have two >external addresses. To initiate the session and create bindings, the NAT will >have to be aware of the SCTP packet format so that it can identify the INIT >chunk and reserve a port , if this is the case then one just needs an ALG that >will instruct ALL of the NATs to create bindings with the session parameters and >establish state for that session. Not expecting much from either NAT or the >ALG!!!. > >host A ----------------------nat1-----------------ISP1 > |(IP A) (IP x1) > +--------------------------nat2 -------------------- > (IP x2) > >So when a INIT chunk orginating form host A with source address in IP header A, >reaches nat1, (or nat2 for that matter), the ALG instructs both the NATs to >create bindings . Now the packets recieved from peer at either x1 or x2 will be >correcty routed to host A. The INIT chunk can not advertise the addresses x1 and >x2 beacuse they originated from the host A. So having a hostname that resolves >to x1 and x2 is the probale solution. Another thing that is possble is expecting >the ALG to modify the chunk and add/modify the addresses in it, but this would >require complete parsing, modifying and then recalculating the checksum for the >packet. Too much to ask for from an ALG. > And where is the ALG in your diagram? It either must be between the two nats or be inside the nats... either way the nat's are communicating state between them. This is my whole point.. NATs of today currently do NOT communicate state between them.. they are stand alone seperate entities that know how to translate a port+ip address pairs to the inside version. Yes it is doable .. but this "nat protocol" or ALG has you call it is NOT defined and must be standardized so that nat1 from company1 and nat2 from company2 can do the correct thing.. All of this is bad in general.. nats are a very big evil that I see no use to teaching how to do multi-homing.. Hostnames help you no more than listing the addresses and having the nat's change them.. after communicating with each other about state setup. My point is that you MUST change the nats in some fashion.. in such a case where you change the Nat the host name becomes a mote point.. doing it with hostsnames is no advantage over just munging the INIT/INIT-ACK after negotiation with your peer.. > >If the NAT is not SCTP Aware, the sessions will be initiated and closed based on >heuristic algorithms. the state at NAT will not be based on the port numbers. >Any packet from host A can initiate the session which will be purely based on >the source and destination IP address. So if the peer is multihomed that will >mean multiple states for the same session at the single NAT. I still don't see >any issues with having multihomed association where x1 and x2 both can be used >as local addresses. Again all that is required is a hostname. > >a > and lots of changes to the two nats or changing a single nat to understand multi-homing.. in either case software changes to current nat technology.. my argument is not it cannot be done.. but that nat's need to be changed if so then the hostname parameter adds nothing to this.. R R > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Dec 2 12:27:25 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27489 for ; Mon, 2 Dec 2002 12:27:24 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB2HKBcb020755; Mon, 2 Dec 2002 09:20:11 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAX55242; Mon, 2 Dec 2002 09:20:10 -0800 (PST) Message-ID: <3DEB9638.9080504@cisco.com> Date: Mon, 02 Dec 2002 11:19:52 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mrajpal@hss.hns.com CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Multihoming with NAT References: <65256C83.001F7965.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit mrajpal@hss.hns.com wrote: > >hi, > >see my comments [MR], > >regards >manish >www.hssworld.com > > > > > >Ivan.Arias-Rodriguez@nokia.com on 11/28/2002 07:40:42 PM > >To: Manish Rajpal/HSS@HSS >cc: rrs@cisco.com, sctp-impl@external.cisco.com > >Subject: RE: Multihoming with NAT > > > > > Hi! > > > >>hi >> >>No! you don't need a SCTP aware NAT, lets suppose NAT has two >>addresses, then >>both these addresses can be used for the association. The >>packets sent by the >>peer to any of these addresses will be routed to the sctp >>host which has got a >>single address. So u have a multihomed association without >>the host having more >>than one address. >> >> > > I must confess that I really never completely understood how NATs and DNS >are compatible... NATs allocate address for the use of a host during a certain >time... so, are NATs changing DNS entries every time they assign different >addresses to different hosts? And they have to do this so everybody can know... >I don't really know how this can work... :-/ Unless DNS entries are only given >to "static" hosts that have regular access to the "outside world" and that >always use the same addresses... > >[MR] its just that when the internal hosts do a lookup, these names will be >resolved to internal addresses. But if the hostname is resolved outside the >current realm, the addresses obtained must a be subset of the external addresses >that NAT has. The host name resolution will be based on the address realm. > > > >>about the misbehaving routers, i'ld like say that its the >>multihoming that comes >>to rescue when you have diffrent addresses belonging to >>different networks, So >>while one network is not in good health the packets can take >>diffrent route to >>reach destination. >> >> > > But at the end, all the packets have to go to the same destination: the >NAT. Well, the NAT can be connected easily to different networks... yes you are >right... > >[MR]I haven't come across many NAT boxess, I am not sure if its that really >easy. > > I can sure tell that by your statements.. I have dealt with a number of them and they need changes to work with hostnames or anything else having to do with SCTP multi-homing. > > >>Its just that the INIT/INIT ACK chunks that communicate the >>addresses to the >>peer and if we can send a hostname, we can create the >>multi-homed association. >> >> > > Could you please quickly explain me how DNS and NATs are compatible? I just >don't know and feel lazy to check RFCs... :-) >[MR] only RFC 2694 would help > > > >>Only restrition I see is dynamically adding or delteting IP >>addresses from such >>an association. >> >> > > Yes, that's right... Unless you change the DNS entry and then you send in >the ASCONF not the IP address but the host name... I don't think anybody would >support this... and I don't think it is feasible either... > >[MR] The draft does not allow you to send hostname in ASCONF chunk. > > And I see NO reason to add it.. There is no value in hostname parameters for the add-ip draft... and I do not see it being added.. R > > >>And if NAT is sctp aware, which is least likely, you don't >>even need the >>hostname as the NAT can itself translate the addresses in >>INIT/INIT-ACK. >>So we don't require anything new from existing NAT box, all >>that is required is >>to send a hostname in the INIT/ INIT ACK that will be resolved to the >>address(es) of NAT. So probably a new interface that allows a >>user to specify a >>hostname for a socket to bind to. If the NAT io >> >> > > Seems that the message was truncated... > > BR Iv > >------------------------------------------------------------------------ > > >án Arias Rodríguez > > > >>regards >>manish >>www.hssworld.com >> >> >> >> >> >>Ivan.Arias-Rodriguez@nokia.com on 11/28/2002 06:03:35 PM >> >>To: Manish Rajpal/HSS@HSS, rrs@cisco.com >>cc: sctp-impl@external.cisco.com >> >>Subject: RE: Multihoming with NAT >> >> >> >> >> Hi! >> >> >> >>>hi, >>> >>>I don't think so, multihoming can work very well behind a NAT >>>too. if NAT can >>>translate one address, it can translate n addresses. I don't >>> >>> >> I think this is precisely the problem... NATs don't know >>anything about >>SCTP, so at most they can translate the source address of the >>IP packet. All the >>deployed NATs are not ready to recognize Protocol Number 132 >>and then look >>inside every of such packets and recognize an INIT/INT ACK >>chunk, so it can dig >>inside the packet and recognize de address parameters... >> >> Of course, if you re-code a NAT to do such thing, I >>think it would work... >>:-/ But, who is the one that is going to re-code all the >>existing NATs...? >> >> Besides, I don't really think that having multihoming >>while being behind a >>NAT is really anything useful... I'm not an expert, but I >>would say that you >>normally have only one NAT that is "covering" a stub domain. >>It means that all >>the packets have to go anyway through the NAT... Well, you >>can always have >>several netwok cards, and then multihoming would prevent >>failure if one of the >>cards itself fails, but it won't prevent about misbehaving >>routers in the way... >> >> >> >>>foresee any issue. >>>In fact, with NAT, its possible that a host running sctp and >>>having single >>>address can appear as a multihomed host to the peer. Only NAT >>>box has to Map >>>both the external addresses to a single internal address. >>> >>> >> But it has to be able to do so... which is not true so far... >> >> BR Iv >> >> >> > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Dec 2 17:41:53 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16020 for ; Mon, 2 Dec 2002 17:41:52 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB2Me40R009330; Mon, 2 Dec 2002 14:40:04 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAX68920; Mon, 2 Dec 2002 14:40:05 -0800 (PST) Message-ID: <3DEBE132.5040704@cisco.com> Date: Mon, 02 Dec 2002 16:39:46 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Serkan Cil CC: mrajpal@hss.hns.com, Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Multihoming with NAT References: <8BAF8B40C4D2D411ADC300508BD63D69020A6A29@smtp.ss8.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Serkan: And so why would one what to do this? It seems to me that you are saying any IP packet headed for IP1' is translated and goes to IP1 (and of course the same for IP2')... Why not just assign IP1' to the host? And even at that.. hostname addresses don't give you any advantage in this scenario.. R Serkan Cil wrote: >Hi, > >If we do not insist on IP multiplexing it is still possible to support MH >behind a NAT. >NAT boxes can do static address mapping between the global >and local address spaces. This does not require any information (port etc.) >from the protocol carried in IP packet. It is a simple address mapping >operation. >Also NAT can work with a pool of global addresses and a pool of local >addresses. >So following scenario seems possible if we configure the nat1 and nat2 to do >just the address mapping. We are basically reserving global addresses IP1' >and IP2' for >IP1 and IP2 mapping. "host" needs to send the INIT with hostname param. >(which is mapped to IP1' and IP2' in DNS or else) > > > IP1 IP1' > host -------nat1 ------ISP1 > | > +----------nat2-------ISP2 > IP2 IP2' > >Serkan > > > > > >>-----Original Message----- >>From: Randall Stewart (cisco) [mailto:rrs@cisco.com] >>Sent: Thursday, November 28, 2002 8:21 PM >>To: mrajpal@hss.hns.com >>Cc: Ivan.Arias-Rodriguez@nokia.com; sctp-impl@external.cisco.com >>Subject: Re: Multihoming with NAT >> >> >>Manish: >> >> >>I think you miss my point... >> >>To have an effective NAT arrangement where multi-homing is going (i.e. >>you want no single point of failure): >> >> >>host -------nat1 ------ISP1 >> | >> +----------nat2-------ISP2 >> >>Having >> >>host -----net1----NAT-------ISP >> | | >>+----------net2----+ >> >>makes two different single points of failure .. aka the >>NAT itself as well as your ISP >> >>Moving the two ISPs to talk to one NAT does not >>help since you still have a single point of failure.. and it does not >>work anyway.. Most nats can only handle translating to one >>address... I have >>this arrangment in my own router/nat box... It has two ISP's >>hooked to >>it and >>I must run two different instances of the nat software.. one for one >>interface >>and the other for the second... these two do NOT know how to >>communicate >>about the two networks...This is what is hard.. you must get >>the NAT's to >>talk to each other and reserve the SAME port on two seperate networks >>and setup state. There may be some nat software out there that can >>handle two networks but this is the rarity if it even exits... >> >>Yes it can work.. without this.. but not with multihoming in the >>picture.. except maybe >>behind the nat (my second drawing).. and in this case it does >>not really >>help you >>that much ... and one can just do the send the INIT with no >>addresses... >>I don't >>see how you could get any benefit of the two internal >>addresses without >>external >>addresses to go with them... Remember a SCTP association is >>only on ONE port >>and a NAT uses the ports to find the state... So my second >>picture gets >>NO benefit >>and the second requires intra-nat communications... And if >>you really wanted >>it done right you would need to have the nats on seperate boxes with a >>intra-nat communication protocol so you would have no single point of >>failure.. >>not one nat controlling two addresses... which I don't know >>if it even >>exits.... >> >>R >> >> >>mrajpal@hss.hns.com wrote: >> >> >> >>>hi >>> >>>No! you don't need a SCTP aware NAT, lets suppose NAT has >>> >>> >>two addresses, then >> >> >>>both these addresses can be used for the association. The >>> >>> >>packets sent by the >> >> >>>peer to any of these addresses will be routed to the sctp >>> >>> >>host which has got a >> >> >>>single address. So u have a multihomed association without >>> >>> >>the host having more >> >> >>>than one address. >>>about the misbehaving routers, i'ld like say that its the >>> >>> >>multihoming that comes >> >> >>>to rescue when you have diffrent addresses belonging to >>> >>> >>different networks, So >> >> >>>while one network is not in good health the packets can take >>> >>> >>diffrent route to >> >> >>>reach destination. >>>Its just that the INIT/INIT ACK chunks that communicate the >>> >>> >>addresses to the >> >> >>>peer and if we can send a hostname, we can create the >>> >>> >>multi-homed association. >> >> >>>Only restrition I see is dynamically adding or delteting IP >>> >>> >>addresses from such >> >> >>>an association. >>> >>>And if NAT is sctp aware, which is least likely, you don't >>> >>> >>even need the >> >> >>>hostname as the NAT can itself translate the addresses in >>> >>> >>INIT/INIT-ACK. >> >> >>>So we don't require anything new from existing NAT box, all >>> >>> >>that is required is >> >> >>>to send a hostname in the INIT/ INIT ACK that will be resolved to the >>>address(es) of NAT. So probably a new interface that allows >>> >>> >>a user to specify a >> >> >>>hostname for a socket to bind to. If the NAT io >>> >>>regards >>>manish >>>www.hssworld.com >>> >>> >>> >>> >>> >>>Ivan.Arias-Rodriguez@nokia.com on 11/28/2002 06:03:35 PM >>> >>>To: Manish Rajpal/HSS@HSS, rrs@cisco.com >>>cc: sctp-impl@external.cisco.com >>> >>>Subject: RE: Multihoming with NAT >>> >>> >>> >>> >>> Hi! >>> >>> >>> >>> >>> >>>>hi, >>>> >>>>I don't think so, multihoming can work very well behind a NAT >>>>too. if NAT can >>>>translate one address, it can translate n addresses. I don't >>>> >>>> >>>> >>>> >>> I think this is precisely the problem... NATs don't >>> >>> >>know anything about >> >> >>>SCTP, so at most they can translate the source address of >>> >>> >>the IP packet. All the >> >> >>>deployed NATs are not ready to recognize Protocol Number 132 >>> >>> >>and then look >> >> >>>inside every of such packets and recognize an INIT/INT ACK >>> >>> >>chunk, so it can dig >> >> >>>inside the packet and recognize de address parameters... >>> >>> Of course, if you re-code a NAT to do such thing, I >>> >>> >>think it would work... >> >> >>>:-/ But, who is the one that is going to re-code all the >>> >>> >>existing NATs...? >> >> >>> Besides, I don't really think that having multihoming >>> >>> >>while being behind a >> >> >>>NAT is really anything useful... I'm not an expert, but I >>> >>> >>would say that you >> >> >>>normally have only one NAT that is "covering" a stub domain. >>> >>> >>It means that all >> >> >>>the packets have to go anyway through the NAT... Well, you >>> >>> >>can always have >> >> >>>several netwok cards, and then multihoming would prevent >>> >>> >>failure if one of the >> >> >>>cards itself fails, but it won't prevent about misbehaving >>> >>> >>routers in the way... >> >> >>> >>> >>> >>> >>>>foresee any issue. >>>>In fact, with NAT, its possible that a host running sctp and >>>>having single >>>>address can appear as a multihomed host to the peer. Only NAT >>>>box has to Map >>>>both the external addresses to a single internal address. >>>> >>>> >>>> >>>> >>> But it has to be able to do so... which is not true so far... >>> >>> BR Iv >>> >>>------------------------------------------------------------- >>> >>> >>----------- >> >> >>>án Arias Rodríguez >>> >>> >>> >>> >>> >>>>regards >>>>manish >>>>www.hssworld.com >>>> >>>> >>>> >>>> >>>>"Randall Stewart (cisco)" on 11/28/2002 01:09:00 AM >>>> >>>>To: Manish Rajpal/HSS@HSS >>>>cc: sctp-impl@external.cisco.com >>>> >>>>Subject: Re: Multihoming with NAT >>>> >>>> >>>> >>>> >>>>Doing this in the kernel is very very difficult.. (see my >>>>earlier email on >>>>this subject). >>>> >>>>To get by a nat one can always just send a INIT with no addresses... >>>>After all multi-homing behind a NAT is not going to work anyway.. >>>> >>>>R >>>> >>>>mrajpal@hss.hns.com wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi >>>>> >>>>>The socket draft - 04 no-where specifies an option for user >>>>> >>>>> >>>>> >>>>> >>>>to provide a >>>> >>>> >>>> >>>> >>>>>hostname for an address. This >>>>>creates a problem when a multi-homed endpoint is behind a >>>>> >>>>> >>>>> >>>>> >>>>NAT. As discussed in >>>> >>>> >>>> >>>> >>>>>sctp applicabilty >>>>>statement, this requires a hostname to be sent in INIT/INIT ack. >>>>>My question is how to get a hostname for the address >>>>> >>>>> >>>>> >>>>> >>>>provided in sctp-socket >>>> >>>> >>>> >>>> >>>>>interface. >>>>> >>>>>regards >>>>>manish >>>>>www.hssworld.com >>>>> >>>>>DISCLAIMER: This message is proprietary to Hughes Software Systems >>>>>Limited (HSS) and is intended solely for the use of the individual >>>>>to whom it is addressed. It may contain privileged or confidential >>>>>information and should not be circulated or used for any >>>>> >>>>> >>>>> >>>>> >>>>purpose other >>>> >>>> >>>> >>>> >>>>>than for what it is intended. If you have received this >>>>> >>>>> >>>>> >>>>> >>>>message in error, >>>> >>>> >>>> >>>> >>>>>please notify the originator immediately. If you are not >>>>> >>>>> >>the intended >> >> >>>>>recipient, you are notified that you are strictly prohibited >>>>> >>>>> >>>>> >>>>> >>>>from using, >>> >>> >>>> >>>> >>>> >>>> >>>>>copying, altering, or disclosing the contents of this >>>>> >>>>> >>>>> >>>>> >>>>message. HSS accepts >>>> >>>> >>>> >>>> >>>>>no responsibility for loss or damage arising from the use of >>>>> >>>>> >>>>> >>>>> >>>>the information >>>> >>>> >>>> >>>> >>>>>transmitted by this email including damage from virus. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-- >>>>Randall R. Stewart >>>>ITD >>>>Cisco Systems Inc. >>>>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >> >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Dec 2 19:06:38 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18733 for ; Mon, 2 Dec 2002 19:06:36 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB3058cb006922 for ; Mon, 2 Dec 2002 16:05:08 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB304qk0006497 for ; Mon, 2 Dec 2002 16:04:52 -0800 (PST) Received: from out013.verizon.net (out013pub.verizon.net [206.46.170.44]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gB3055Lj004146 for ; Mon, 2 Dec 2002 16:05:05 -0800 (PST) Received: from duck ([67.212.82.35]) by out013.verizon.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with ESMTP id <20021202234614.KWTY1248.out013.verizon.net@duck> for ; Mon, 2 Dec 2002 17:46:14 -0600 Message-ID: <915513-22002121223499770@duck> X-Priority: 3 Reply-To: market.access@verizon.net X-MSMail-Priority: Normal Errors-to: market.access@verizon.net Organization: Market*Access Int'l From: "David Dickson" To: "SCTP-IMPL@EXTERNAL.CISCO.COM" Subject: Colorado Homeland Def. Trng Conference - Jan 14-16, 2003 - New Speakers Added Date: Mon, 2 Dec 2002 18:49:09 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA18733 TO: SCTP-IMPL@EXTERNAL.CISCO.COM Homeland Defense and Homeland Security in the 21st Century Regional, State and Local Strategies Homeland Defense Training Conference *** Includes special Grants Workshop and briefings by the new DoD Northern Command -- See below for details *** ATTENTION INDUSTRY: If you have a product or service you wish to sell to the state and local homeland security market, this is the preferred conference for you. The President's FY03 budget calls for $3.6 billion to be passed to state and local authorities via grants for communications, training and infrastructure protection. Be sure your company is prepared. Leading western states federal, DoD, state and local government buyers and decision-makers will be in attendance. There are a limited number of sponsorships and exhibit tables available. See below for instructions. Colorado Springs, Colorado Three-day Training Conference and Grants Workshop Tuesday – Wednesday – Thursday * January 14, 15, 16, 2003 The Broadmoor Conference Center Colorado Springs, Colorado 80906 Hotel reservations and Information (800) 634-7711 (Special room rates have been established for conference attendees. When you call to make your reservation, register using the following code: HDJ03.) *** Call our Events Hotline at 703-807-2027 to learn how to register on-line and see updated speaker list *** About this conference This administration will direct billions of dollars through federal and state agencies with the goal of improving America’s ability to detect, respond, recover and reconstitute from terrorist attacks. Many of these improvements will directly assist state and local leaders as they also respond to national disasters and major industrial accidents. Funding will include pending funds from the First Responder Initiative now before congress. This $3.5 billion dollar initiative will be focused at state and local needs for communications, emergency medical and first responders. America’s 3,000 counties and 18,000 cities all have varying needs and requirements based on infrastructure and threat. An important element of planning is the development of regional agreements thus saving valuable resources by developing joint support agreements and response plans. This conference will examine the development of strategies, requirements, solutions and plans at the regional, state and local levels. Federal agency support programs will also be examined. Other topics include: * Report on federal and state grants to support homeland defense initiatives * Grants workshop with tips, tools, lessons-learned * Briefings by Northern Command on roles, mission and requirements * Report from Capital Hill on pending legislation, funding and new programs * Federal agency reports on roles at regional, state and local levels Who Should Attend * Regional, state and local emergency management executives and senior staff * Federal and DoD managers with an assigned mission in homeland defense * Industry executives with products and services that support homeland defense * Trainers and instructors in emergency response * State and local grants staff interested in updating their understanding of available grants and grants application techniques Speakers Include * Northern Command (Speakers to be announced.) * Michael Paddock, President, Grants Office LLC. (Mr. Paddock will chair the Grants Workshop) * Dr. Ron Sega, Director, DoD Defense Research & Engineering (DDR&E) (invited) * Mr. Stephen M. Sorett, Attorney at Law, Reed Smith, Washington, D.C. (Nationally recognized Grants law expert) * Mr. Christopher L. Rissetto, Partner, Reed Smith, Washington, D.C. (Nationally recognized Grants law expert) * Jeff Goldberg, EMT-P, Emergency Management Advisor to the Director of Integrated Support Services, Library of Congress, Washington, D.C. * Eric Mason, Supervisory Special Agent, CALEA Implementation Section, FBI * Mr. Robert E. Roberts, Regional Administrator, EPA * Ms. C. Suzanne Mencer, Executive Director, Colorado Department of Public Safety * Mr. David Maurstad, Regional Director, FEMA (Invited) * Colorado Emergency Management Executives * DoD Office of Secretary of Defense * National Guard * White House / Office of Homeland Security Special Exhibit and Sponsor Opportunities Available. Call Cara Lombardi at 703-807-2743 for more information *** Call our Events Hotline at 703-807-2027 to learn how to register on-line and see updated speaker list *** Homeland Defense Training Conference Agenda Day One * 14 January 2003 Afternoon: Registration and check in Evening: Networking reception at the Broadmoor Hotel Day Two All day: Briefings by federal, state and local emergency management executives on plans, requirements, challenges and needs. Day Three Morning: Briefings by federal, state and local emergency management executives on plans, requirements, challenges and needs. Grants Workshop. Afternoon: Networking, check-out Special Grants Workshop During the three-day conference a workshop will be presented by the Colorado Springs Economic Development Corporation, the Homeland Defense Journal, Grants Office and the law firm of ReedSmith. This three-hour workshop will guide attendees through the maze of federal grants, provide tips and tools for preparing your grants and a proprietary database of over 160 federal, state and private grants for homeland defense and homeland security. Two distinguished legal experts in Grants law will walk the attendees through post award requirements for audit and compliance. No state, city or county grants manager should miss this important session. If your company has a product or service that will likely be purchased with grants funds, you should attend this very important workshop. Sponsor Exhibit Area A limited number of sponsor exhibits will be available for networking and information exchange. These exhibits will focus on industry and government agency solutions for homeland defense related products and services. Major corporations and Colorado small business will be featured. Exhibits, case studies and demonstrations will provide the attendee with a wide range of product and solutions information. Sponsors * Colorado Springs Economic Development Corporation * Colorado Springs Chamber of Commerce * Homeland Defense Journal * University of Colorado * XAWare, Inc. * Disaster Recovery Institute International * Contingency Planning and Management Online * Grants Office, LLC * ReedSmith, LLC * INPUT * Colorado Space Enterprise (Formerly Colorado Space Council) Registration Information Corporate/Industry $795 Government $345 Small business (less than 100 employees) $495 University of Colorado Staff $295 Includes meals, reception, conference, proceedings binder, Grants training, Grants database researched and compiled by Market*Access. This database retails for $295.00 and is provided to each attendee at the training course for Grants. *** Call our Events Hotline at 703-807-2027 to learn how to register on-line and see updated speaker list *** __________________________________________________________________________ Homeland Defense and Homeland Security in the 21st Century January 14-16, 2003 Registration Form (Use additional pages as needed for multiple employees) Attendee Name: Title: Company/Agency: Company/Agency Web site: Address: City: State: Zip Code: Email: Telephone: Fax: Note: Payment requested in advance. Please check one of the following as your form of payment: [ ] Check Make checks payable to: Market*Access International Send to: Market*Access, 4301 Wilson Boulevard, Suite 1003, Arlington VA 22203 [ ] VISA [ ] MasterCard [ ] American Express Account Number: ___________________________Exp. Date___________________ Cardholder Name: ______________________________________________________ Signature (required) or telephone order _______________________________________ Pre-Registration Fee: Industry: $795 Government: $345 Small Business (100 employees or fewer): $495 University of Colorado Staff: $295 Additional Information can be obtained by calling our EVENTS HOTLINE at 703-807-2027. Registration and Information: Call Parrish S. Knight (703) 807-2748 Fax this form to 703-807-2728. Thank you. This business communication was sent to you to inform you of a training conference for homeland security. If you wish to be REMOVED from this communication, please place REMOVE in the SUBJECT line and REPLY to this message. We do NOT wish to send you emails that you are not interested in receiving. If you wish to be REMOVED from this list, please REPLY and place REMOVE in the SUBJECT line. From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Dec 3 07:52:47 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16622 for ; Tue, 3 Dec 2002 07:52:45 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB361lK0025435 for ; Mon, 2 Dec 2002 22:01:47 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB361kSl010666 for ; Mon, 2 Dec 2002 22:01:47 -0800 (PST) Received: from hindon.hss.co.in ([202.54.26.202]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gB361dLj010638 for ; Mon, 2 Dec 2002 22:01:41 -0800 (PST) Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gB35NJr12820 for ; Tue, 3 Dec 2002 10:53:19 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gB35NG812810; Tue, 3 Dec 2002 10:53:16 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gB35P0518982; Tue, 3 Dec 2002 10:55:01 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C84.001D0EB4 ; Tue, 3 Dec 2002 10:47:23 +0530 X-Lotus-FromDomain: HSS From: mrajpal@hss.hns.com To: "Randall Stewart (cisco)" cc: Serkan Cil , Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Message-ID: <65256C84.001D0D93.00@sandesh.hss.hns.com> Date: Tue, 3 Dec 2002 10:51:52 +0530 Subject: Re: Multihoming with NAT Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=DSwXKO7ZhFxp2i4D3YI7BV5hmbhNRwCTvhAuuQZY4nLqupyZR4kssBgW" Content-Disposition: inline --0__=DSwXKO7ZhFxp2i4D3YI7BV5hmbhNRwCTvhAuuQZY4nLqupyZR4kssBgW Content-type: text/plain; charset=us-ascii Content-Disposition: inline hi, So, are we trying to say that multihoming will not be supported unless NAT protocols change? Well, the existing protocols allow ALGs to establish state at NAT box. So an ALG that knows SCTP, can easily establish state at NAT boxes from any company (if it supports this very basic primitive of establishing state). And as I previously said, multihoming is possible even without a hostname as the ALG will be capable of changing the INIT/INIT ACK chunks. It will just increase the complexity of the ALG as it will have to create a NEW packet (It needs to insert addresses in between), recalculate the checksum and send packet to destination. Having a hostname just simplifies the ALG. regards Manish www.hssworld.com "Randall Stewart (cisco)" on 12/03/2002 04:09:46 AM To: Serkan Cil cc: Manish Rajpal/HSS@HSS, Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Multihoming with NAT Serkan: And so why would one what to do this? It seems to me that you are saying any IP packet headed for IP1' is translated and goes to IP1 (and of course the same for IP2')... Why not just assign IP1' to the host? And even at that.. hostname addresses don't give you any advantage in this scenario.. R Serkan Cil wrote: >Hi, > >If we do not insist on IP multiplexing it is still possible to support MH >behind a NAT. >NAT boxes can do static address mapping between the global >and local address spaces. This does not require any information (port etc.) >from the protocol carried in IP packet. It is a simple address mapping >operation. >Also NAT can work with a pool of global addresses and a pool of local >addresses. >So following scenario seems possible if we configure the nat1 and nat2 to do >just the address mapping. We are basically reserving global addresses IP1' >and IP2' for >IP1 and IP2 mapping. "host" needs to send the INIT with hostname param. >(which is mapped to IP1' and IP2' in DNS or else) > > > IP1 IP1' > host -------nat1 ------ISP1 > | > +----------nat2-------ISP2 > IP2 IP2' > >Serkan > > > > > >>-----Original Message----- >>From: Randall Stewart (cisco) [mailto:rrs@cisco.com] >>Sent: Thursday, November 28, 2002 8:21 PM >>To: mrajpal@hss.hns.com >>Cc: Ivan.Arias-Rodriguez@nokia.com; sctp-impl@external.cisco.com >>Subject: Re: Multihoming with NAT >> >> >>Manish: >> >> >>I think you miss my point... >> >>To have an effective NAT arrangement where multi-homing is going (i.e. >>you want no single point of failure): >> >> >>host -------nat1 ------ISP1 >> | >> +----------nat2-------ISP2 >> >>Having >> >>host -----net1----NAT-------ISP >> | | >>+----------net2----+ >> >>makes two different single points of failure .. aka the >>NAT itself as well as your ISP >> >>Moving the two ISPs to talk to one NAT does not >>help since you still have a single point of failure.. and it does not >>work anyway.. Most nats can only handle translating to one >>address... I have >>this arrangment in my own router/nat box... It has two ISP's >>hooked to >>it and >>I must run two different instances of the nat software.. one for one >>interface >>and the other for the second... these two do NOT know how to >>communicate >>about the two networks...This is what is hard.. you must get >>the NAT's to >>talk to each other and reserve the SAME port on two seperate networks >>and setup state. There may be some nat software out there that can >>handle two networks but this is the rarity if it even exits... >> >>Yes it can work.. without this.. but not with multihoming in the >>picture.. except maybe >>behind the nat (my second drawing).. and in this case it does >>not really >>help you >>that much ... and one can just do the send the INIT with no >>addresses... >>I don't >>see how you could get any benefit of the two internal >>addresses without >>external >>addresses to go with them... Remember a SCTP association is >>only on ONE port >>and a NAT uses the ports to find the state... So my second >>picture gets >>NO benefit >>and the second requires intra-nat communications... And if >>you really wanted >>it done right you would need to have the nats on seperate boxes with a >>intra-nat communication protocol so you would have no single point of >>failure.. >>not one nat controlling two addresses... which I don't know >>if it even >>exits.... >> >>R >> >> >>mrajpal@hss.hns.com wrote: >> >> >> >>>hi >>> >>>No! you don't need a SCTP aware NAT, lets suppose NAT has >>> >>> >>two addresses, then >> >> >>>both these addresses can be used for the association. The >>> >>> >>packets sent by the >> >> >>>peer to any of these addresses will be routed to the sctp >>> >>> >>host which has got a >> >> >>>single address. So u have a multihomed association without >>> >>> >>the host having more >> >> >>>than one address. >>>about the misbehaving routers, i'ld like say that its the >>> >>> >>multihoming that comes >> >> >>>to rescue when you have diffrent addresses belonging to >>> >>> >>different networks, So >> >> >>>while one network is not in good health the packets can take >>> >>> >>diffrent route to >> >> >>>reach destination. >>>Its just that the INIT/INIT ACK chunks that communicate the >>> >>> >>addresses to the >> >> >>>peer and if we can send a hostname, we can create the >>> >>> >>multi-homed association. >> >> >>>Only restrition I see is dynamically adding or delteting IP >>> >>> >>addresses from such >> >> >>>an association. >>> >>>And if NAT is sctp aware, which is least likely, you don't >>> >>> >>even need the >> >> >>>hostname as the NAT can itself translate the addresses in >>> >>> >>INIT/INIT-ACK. >> >> >>>So we don't require anything new from existing NAT box, all >>> >>> >>that is required is >> >> >>>to send a hostname in the INIT/ INIT ACK that will be resolved to the >>>address(es) of NAT. So probably a new interface that allows >>> >>> >>a user to specify a >> >> >>>hostname for a socket to bind to. If the NAT io >>> >>>regards >>>manish >>>www.hssworld.com >>> >>> >>> >>> >>> >>>Ivan.Arias-Rodriguez@nokia.com on 11/28/2002 06:03:35 PM >>> >>>To: Manish Rajpal/HSS@HSS, rrs@cisco.com >>>cc: sctp-impl@external.cisco.com >>> >>>Subject: RE: Multihoming with NAT >>> >>> >>> >>> >>> Hi! >>> >>> >>> >>> >>> >>>>hi, >>>> >>>>I don't think so, multihoming can work very well behind a NAT >>>>too. if NAT can >>>>translate one address, it can translate n addresses. I don't >>>> >>>> >>>> >>>> >>> I think this is precisely the problem... NATs don't >>> >>> >>know anything about >> >> >>>SCTP, so at most they can translate the source address of >>> >>> >>the IP packet. All the >> >> >>>deployed NATs are not ready to recognize Protocol Number 132 >>> >>> >>and then look >> >> >>>inside every of such packets and recognize an INIT/INT ACK >>> >>> >>chunk, so it can dig >> >> >>>inside the packet and recognize de address parameters... >>> >>> Of course, if you re-code a NAT to do such thing, I >>> >>> >>think it would work... >> >> >>>:-/ But, who is the one that is going to re-code all the >>> >>> >>existing NATs...? >> >> >>> Besides, I don't really think that having multihoming >>> >>> >>while being behind a >> >> >>>NAT is really anything useful... I'm not an expert, but I >>> >>> >>would say that you >> >> >>>normally have only one NAT that is "covering" a stub domain. >>> >>> >>It means that all >> >> >>>the packets have to go anyway through the NAT... Well, you >>> >>> >>can always have >> >> >>>several netwok cards, and then multihoming would prevent >>> >>> >>failure if one of the >> >> >>>cards itself fails, but it won't prevent about misbehaving >>> >>> >>routers in the way... >> >> >>> >>> >>> >>> >>>>foresee any issue. >>>>In fact, with NAT, its possible that a host running sctp and >>>>having single >>>>address can appear as a multihomed host to the peer. Only NAT >>>>box has to Map >>>>both the external addresses to a single internal address. >>>> >>>> >>>> >>>> >>> But it has to be able to do so... which is not true so far... >>> >>> BR Iv >>> >>>------------------------------------------------------------- >>> >>> >>----------- >> >> >>> --0__=DSwXKO7ZhFxp2i4D3YI7BV5hmbhNRwCTvhAuuQZY4nLqupyZR4kssBgW Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =E1n Arias Rodr=EDguez >>> >>> >>> >>> >>> >>>>regards >>>>manish >>>>www.hssworld.com >>>> >>>> >>>> >>>> >>>>"Randall Stewart (cisco)" on 11/28/2002 01:09:00 AM= >>>> >>>>To: Manish Rajpal/HSS@HSS >>>>cc: sctp-impl@external.cisco.com >>>> >>>>Subject: Re: Multihoming with NAT >>>> >>>> >>>> >>>> >>>>Doing this in the kernel is very very difficult.. (see my >>>>earlier email on >>>>this subject). >>>> >>>>To get by a nat one can always just send a INIT with no addresses..= . >>>>After all multi-homing behind a NAT is not going to work anyway.. >>>> >>>>R >>>> >>>>mrajpal@hss.hns.com wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi >>>>> >>>>>The socket draft - 04 no-where specifies an option for user >>>>> >>>>> >>>>> >>>>> >>>>to provide a >>>> >>>> >>>> >>>> >>>>>hostname for an address. This >>>>>creates a problem when a multi-homed endpoint is behind a >>>>> >>>>> >>>>> >>>>> >>>>NAT. As discussed in >>>> >>>> >>>> >>>> >>>>>sctp applicabilty >>>>>statement, this requires a hostname to be sent in INIT/INIT ack. >>>>>My question is how to get a hostname for the address >>>>> >>>>> >>>>> >>>>> >>>>provided in sctp-socket >>>> >>>> >>>> >>>> >>>>>interface. >>>>> >>>>>regards >>>>>manish >>>>>www.hssworld.com >>>>> >>>>>DISCLAIMER: This message is proprietary to Hughes Software Systems= >>>>>Limited (HSS) and is intended solely for the use of the individual= >>>>>to whom it is addressed. It may contain privileged or confidentia= l >>>>>information and should not be circulated or used for any >>>>> >>>>> >>>>> >>>>> >>>>purpose other >>>> >>>> >>>> >>>> >>>>>than for what it is intended. If you have received this >>>>> >>>>> >>>>> >>>>> >>>>message in error, >>>> >>>> >>>> >>>> >>>>>please notify the originator immediately. If you are not >>>>> >>>>> >>the intended >> >> >>>>>recipient, you are notified that you are strictly prohibited >>>>> >>>>> >>>>> >>>>> >>>>from using, >>> >>> >>>> >>>> >>>> >>>> >>>>>copying, altering, or disclosing the contents of this >>>>> >>>>> >>>>> >>>>> >>>>message. HSS accepts >>>> >>>> >>>> >>>> >>>>>no responsibility for loss or damage arising from the use of >>>>> >>>>> >>>>> >>>>> >>>>the information >>>> >>>> >>>> >>>> >>>>>transmitted by this email including damage from virus. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-- >>>>Randall R. Stewart >>>>ITD >>>>Cisco Systems Inc. >>>>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >> >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) = --0__=DSwXKO7ZhFxp2i4D3YI7BV5hmbhNRwCTvhAuuQZY4nLqupyZR4kssBgW-- From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Dec 3 09:03:57 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20618 for ; Tue, 3 Dec 2002 09:03:54 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB3DvcLW007979 for ; Tue, 3 Dec 2002 05:57:38 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB3DvbTs001375 for ; Tue, 3 Dec 2002 05:57:38 -0800 (PST) Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gB3Dvbfw002775 for ; Tue, 3 Dec 2002 05:57:38 -0800 (PST) Received: by smtp.ss8.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Dec 2002 08:53:30 -0500 Message-ID: <8BAF8B40C4D2D411ADC300508BD63D69020A6A2A@smtp.ss8.com> From: Serkan Cil To: "'Randall Stewart (cisco)'" , Serkan Cil Cc: mrajpal@hss.hns.com, Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: RE: Multihoming with NAT Date: Tue, 3 Dec 2002 08:53:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Hi Randall, please see my comments below. Serkan > -----Original Message----- > From: Randall Stewart (cisco) [mailto:rrs@cisco.com] > Sent: Monday, December 02, 2002 5:40 PM > To: Serkan Cil > Cc: mrajpal@hss.hns.com; Ivan.Arias-Rodriguez@nokia.com; > sctp-impl@external.cisco.com > Subject: Re: Multihoming with NAT > > > Serkan: > > And so why would one what to do this? It seems to me that you > are saying any IP packet headed for IP1' is translated and goes > to IP1 (and of course the same for IP2')... > > Why not just assign IP1' to the host? > [Serkan] Say your host is in a corporate network and your NAT(s) is located on the corporate router(s) which connect to ISP(s). IMO the most suitable place for "the host" would be behind the router rather than the front (i.e. outside). And there will be cases where you will have to do that just because of the IT policies etc. So in such cases static mapping would be needed. > And even at that.. hostname addresses don't give you any > advantage in this scenario.. [Serkan] I am not clear why hostname address wouldn't be a solution. It seems to me that hostname address should work as long as it maps to IP1' and IP2'. > > R > > Serkan Cil wrote: > > >Hi, > > > >If we do not insist on IP multiplexing it is still possible > to support MH > >behind a NAT. > >NAT boxes can do static address mapping between the global > >and local address spaces. This does not require any > information (port etc.) > >from the protocol carried in IP packet. It is a simple > address mapping > >operation. > >Also NAT can work with a pool of global addresses and a pool of local > >addresses. > >So following scenario seems possible if we configure the > nat1 and nat2 to do > >just the address mapping. We are basically reserving global > addresses IP1' > >and IP2' for > >IP1 and IP2 mapping. "host" needs to send the INIT with > hostname param. > >(which is mapped to IP1' and IP2' in DNS or else) > > > > > > IP1 IP1' > > host -------nat1 ------ISP1 > > | > > +----------nat2-------ISP2 > > IP2 IP2' > > > >Serkan > > > > > > > > > > > >>-----Original Message----- > >>From: Randall Stewart (cisco) [mailto:rrs@cisco.com] > >>Sent: Thursday, November 28, 2002 8:21 PM > >>To: mrajpal@hss.hns.com > >>Cc: Ivan.Arias-Rodriguez@nokia.com; sctp-impl@external.cisco.com > >>Subject: Re: Multihoming with NAT > >> > >> > >>Manish: > >> > >> > >>I think you miss my point... > >> > >>To have an effective NAT arrangement where multi-homing is > going (i.e. > >>you want no single point of failure): > >> > >> > >>host -------nat1 ------ISP1 > >> | > >> +----------nat2-------ISP2 > >> > >>Having > >> > >>host -----net1----NAT-------ISP > >> | | > >>+----------net2----+ > >> > >>makes two different single points of failure .. aka the > >>NAT itself as well as your ISP > >> > >>Moving the two ISPs to talk to one NAT does not > >>help since you still have a single point of failure.. and > it does not > >>work anyway.. Most nats can only handle translating to one > >>address... I have > >>this arrangment in my own router/nat box... It has two ISP's > >>hooked to > >>it and > >>I must run two different instances of the nat software.. > one for one > >>interface > >>and the other for the second... these two do NOT know how to > >>communicate > >>about the two networks...This is what is hard.. you must get > >>the NAT's to > >>talk to each other and reserve the SAME port on two > seperate networks > >>and setup state. There may be some nat software out there that can > >>handle two networks but this is the rarity if it even exits... > >> > >>Yes it can work.. without this.. but not with multihoming in the > >>picture.. except maybe > >>behind the nat (my second drawing).. and in this case it does > >>not really > >>help you > >>that much ... and one can just do the send the INIT with no > >>addresses... > >>I don't > >>see how you could get any benefit of the two internal > >>addresses without > >>external > >>addresses to go with them... Remember a SCTP association is > >>only on ONE port > >>and a NAT uses the ports to find the state... So my second > >>picture gets > >>NO benefit > >>and the second requires intra-nat communications... And if > >>you really wanted > >>it done right you would need to have the nats on seperate > boxes with a > >>intra-nat communication protocol so you would have no > single point of > >>failure.. > >>not one nat controlling two addresses... which I don't know > >>if it even > >>exits.... > >> > >>R > >> > >> > >>mrajpal@hss.hns.com wrote: > >> > >> > >> > >>>hi > >>> > >>>No! you don't need a SCTP aware NAT, lets suppose NAT has > >>> > >>> > >>two addresses, then > >> > >> > >>>both these addresses can be used for the association. The > >>> > >>> > >>packets sent by the > >> > >> > >>>peer to any of these addresses will be routed to the sctp > >>> > >>> > >>host which has got a > >> > >> > >>>single address. So u have a multihomed association without > >>> > >>> > >>the host having more > >> > >> > >>>than one address. > >>>about the misbehaving routers, i'ld like say that its the > >>> > >>> > >>multihoming that comes > >> > >> > >>>to rescue when you have diffrent addresses belonging to > >>> > >>> > >>different networks, So > >> > >> > >>>while one network is not in good health the packets can take > >>> > >>> > >>diffrent route to > >> > >> > >>>reach destination. > >>>Its just that the INIT/INIT ACK chunks that communicate the > >>> > >>> > >>addresses to the > >> > >> > >>>peer and if we can send a hostname, we can create the > >>> > >>> > >>multi-homed association. > >> > >> > >>>Only restrition I see is dynamically adding or delteting IP > >>> > >>> > >>addresses from such > >> > >> > >>>an association. > >>> > >>>And if NAT is sctp aware, which is least likely, you don't > >>> > >>> > >>even need the > >> > >> > >>>hostname as the NAT can itself translate the addresses in > >>> > >>> > >>INIT/INIT-ACK. > >> > >> > >>>So we don't require anything new from existing NAT box, all > >>> > >>> > >>that is required is > >> > >> > >>>to send a hostname in the INIT/ INIT ACK that will be > resolved to the > >>>address(es) of NAT. So probably a new interface that allows > >>> > >>> > >>a user to specify a > >> > >> > >>>hostname for a socket to bind to. If the NAT io > >>> > >>>regards > >>>manish > >>>www.hssworld.com > >>> > >>> > >>> > >>> > >>> > >>>Ivan.Arias-Rodriguez@nokia.com on 11/28/2002 06:03:35 PM > >>> > >>>To: Manish Rajpal/HSS@HSS, rrs@cisco.com > >>>cc: sctp-impl@external.cisco.com > >>> > >>>Subject: RE: Multihoming with NAT > >>> > >>> > >>> > >>> > >>> Hi! > >>> > >>> > >>> > >>> > >>> > >>>>hi, > >>>> > >>>>I don't think so, multihoming can work very well behind a NAT > >>>>too. if NAT can > >>>>translate one address, it can translate n addresses. I don't > >>>> > >>>> > >>>> > >>>> > >>> I think this is precisely the problem... NATs don't > >>> > >>> > >>know anything about > >> > >> > >>>SCTP, so at most they can translate the source address of > >>> > >>> > >>the IP packet. All the > >> > >> > >>>deployed NATs are not ready to recognize Protocol Number 132 > >>> > >>> > >>and then look > >> > >> > >>>inside every of such packets and recognize an INIT/INT ACK > >>> > >>> > >>chunk, so it can dig > >> > >> > >>>inside the packet and recognize de address parameters... > >>> > >>> Of course, if you re-code a NAT to do such thing, I > >>> > >>> > >>think it would work... > >> > >> > >>>:-/ But, who is the one that is going to re-code all the > >>> > >>> > >>existing NATs...? > >> > >> > >>> Besides, I don't really think that having multihoming > >>> > >>> > >>while being behind a > >> > >> > >>>NAT is really anything useful... I'm not an expert, but I > >>> > >>> > >>would say that you > >> > >> > >>>normally have only one NAT that is "covering" a stub domain. > >>> > >>> > >>It means that all > >> > >> > >>>the packets have to go anyway through the NAT... Well, you > >>> > >>> > >>can always have > >> > >> > >>>several netwok cards, and then multihoming would prevent > >>> > >>> > >>failure if one of the > >> > >> > >>>cards itself fails, but it won't prevent about misbehaving > >>> > >>> > >>routers in the way... > >> > >> > >>> > >>> > >>> > >>> > >>>>foresee any issue. > >>>>In fact, with NAT, its possible that a host running sctp and > >>>>having single > >>>>address can appear as a multihomed host to the peer. Only NAT > >>>>box has to Map > >>>>both the external addresses to a single internal address. > >>>> > >>>> > >>>> > >>>> > >>> But it has to be able to do so... which is not true so far... > >>> > >>> BR Iv > >>> > >>>------------------------------------------------------------- > >>> > >>> > >>----------- > >> > >> > >>>án Arias Rodríguez > >>> > >>> > >>> > >>> > >>> > >>>>regards > >>>>manish > >>>>www.hssworld.com > >>>> > >>>> > >>>> > >>>> > >>>>"Randall Stewart (cisco)" on 11/28/2002 > 01:09:00 AM > >>>> > >>>>To: Manish Rajpal/HSS@HSS > >>>>cc: sctp-impl@external.cisco.com > >>>> > >>>>Subject: Re: Multihoming with NAT > >>>> > >>>> > >>>> > >>>> > >>>>Doing this in the kernel is very very difficult.. (see my > >>>>earlier email on > >>>>this subject). > >>>> > >>>>To get by a nat one can always just send a INIT with no > addresses... > >>>>After all multi-homing behind a NAT is not going to work anyway.. > >>>> > >>>>R > >>>> > >>>>mrajpal@hss.hns.com wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Hi > >>>>> > >>>>>The socket draft - 04 no-where specifies an option for user > >>>>> > >>>>> > >>>>> > >>>>> > >>>>to provide a > >>>> > >>>> > >>>> > >>>> > >>>>>hostname for an address. This > >>>>>creates a problem when a multi-homed endpoint is behind a > >>>>> > >>>>> > >>>>> > >>>>> > >>>>NAT. As discussed in > >>>> > >>>> > >>>> > >>>> > >>>>>sctp applicabilty > >>>>>statement, this requires a hostname to be sent in INIT/INIT ack. > >>>>>My question is how to get a hostname for the address > >>>>> > >>>>> > >>>>> > >>>>> > >>>>provided in sctp-socket > >>>> > >>>> > >>>> > >>>> > >>>>>interface. > >>>>> > >>>>>regards > >>>>>manish > >>>>>www.hssworld.com > >>>>> > >>>>>DISCLAIMER: This message is proprietary to Hughes > Software Systems > >>>>>Limited (HSS) and is intended solely for the use of the > individual > >>>>>to whom it is addressed. It may contain privileged or > confidential > >>>>>information and should not be circulated or used for any > >>>>> > >>>>> > >>>>> > >>>>> > >>>>purpose other > >>>> > >>>> > >>>> > >>>> > >>>>>than for what it is intended. If you have received this > >>>>> > >>>>> > >>>>> > >>>>> > >>>>message in error, > >>>> > >>>> > >>>> > >>>> > >>>>>please notify the originator immediately. If you are not > >>>>> > >>>>> > >>the intended > >> > >> > >>>>>recipient, you are notified that you are strictly prohibited > >>>>> > >>>>> > >>>>> > >>>>> > >>>>from using, > >>> > >>> > >>>> > >>>> > >>>> > >>>> > >>>>>copying, altering, or disclosing the contents of this > >>>>> > >>>>> > >>>>> > >>>>> > >>>>message. HSS accepts > >>>> > >>>> > >>>> > >>>> > >>>>>no responsibility for loss or damage arising from the use of > >>>>> > >>>>> > >>>>> > >>>>> > >>>>the information > >>>> > >>>> > >>>> > >>>> > >>>>>transmitted by this email including damage from virus. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>-- > >>>>Randall R. Stewart > >>>>ITD > >>>>Cisco Systems Inc. > >>>>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>-- > >>Randall R. Stewart > >>ITD > >>Cisco Systems Inc. > >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > >> > >> > >> > >> > >> > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Dec 3 12:50:30 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05997 for ; Tue, 3 Dec 2002 12:50:27 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB3BoLcb016970; Tue, 3 Dec 2002 03:50:21 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAX87199; Tue, 3 Dec 2002 03:50:19 -0800 (PST) Message-ID: <3DEC9A67.7040906@cisco.com> Date: Tue, 03 Dec 2002 05:49:59 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mrajpal@hss.hns.com CC: Serkan Cil , Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Multihoming with NAT References: <65256C84.001D0D93.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Manish: You need to compare implementing a Application level change versus implementing a hostname lookup within the kernel. These are orders of magnitude apart in the complexity and difficulty to implement. It is NO easy thing to do... Also you seem to imply that all NAT's can be controlled by ALGs.. this is simply NOT true. The 2 NAT's in my house are in NO way capable of being controlled by a ALG.. On top of that I have looked into running two DNS's to provide a "inside" and a "outside" set of names ... and getting it "right" is a difficult problem.. I am no expert in DNS but I quckly decided it was not worth the pain... I just don't see Hostname addresses ever being useful since they are: 1) so difficult to implement in the kernel, 2) provide no advantage for most applications (if you are worried about conserving addresses you are far less likely to be multi-homed) 3) Are very difficult to get the DNS setup for the common person 4) Can be done with a small number of changes in a NAT if it were really needed. R mrajpal@hss.hns.com wrote: > >hi, > >So, are we trying to say that multihoming will not be supported unless NAT >protocols change? Well, the existing protocols allow ALGs to establish state at >NAT box. So an ALG that knows SCTP, can easily establish state at NAT boxes from >any company (if it supports this very basic primitive of establishing state). >And as I previously said, multihoming is possible even without a hostname as the >ALG will be capable of changing the INIT/INIT ACK chunks. It will just increase >the complexity of the ALG as it will have to create a NEW packet (It needs to >insert addresses in between), recalculate the checksum and send packet to >destination. Having a hostname just simplifies the ALG. > >regards >Manish >www.hssworld.com > > > > >"Randall Stewart (cisco)" on 12/03/2002 04:09:46 AM > >To: Serkan Cil >cc: Manish Rajpal/HSS@HSS, Ivan.Arias-Rodriguez@nokia.com, > sctp-impl@external.cisco.com > >Subject: Re: Multihoming with NAT > > > > >Serkan: > >And so why would one what to do this? It seems to me that you >are saying any IP packet headed for IP1' is translated and goes >to IP1 (and of course the same for IP2')... > >Why not just assign IP1' to the host? > >And even at that.. hostname addresses don't give you any >advantage in this scenario.. > >R > >Serkan Cil wrote: > > > >>Hi, >> >>If we do not insist on IP multiplexing it is still possible to support MH >>behind a NAT. >>NAT boxes can do static address mapping between the global >>and local address spaces. This does not require any information (port etc.) >> >> >>from the protocol carried in IP packet. It is a simple address mapping > > >>operation. >>Also NAT can work with a pool of global addresses and a pool of local >>addresses. >>So following scenario seems possible if we configure the nat1 and nat2 to do >>just the address mapping. We are basically reserving global addresses IP1' >>and IP2' for >>IP1 and IP2 mapping. "host" needs to send the INIT with hostname param. >>(which is mapped to IP1' and IP2' in DNS or else) >> >> >> IP1 IP1' >>host -------nat1 ------ISP1 >> | >> +----------nat2-------ISP2 >> IP2 IP2' >> >>Serkan >> >> >> >> >> >> >> >>>-----Original Message----- >>>From: Randall Stewart (cisco) [mailto:rrs@cisco.com] >>>Sent: Thursday, November 28, 2002 8:21 PM >>>To: mrajpal@hss.hns.com >>>Cc: Ivan.Arias-Rodriguez@nokia.com; sctp-impl@external.cisco.com >>>Subject: Re: Multihoming with NAT >>> >>> >>>Manish: >>> >>> >>>I think you miss my point... >>> >>>To have an effective NAT arrangement where multi-homing is going (i.e. >>>you want no single point of failure): >>> >>> >>>host -------nat1 ------ISP1 >>> | >>>+----------nat2-------ISP2 >>> >>>Having >>> >>>host -----net1----NAT-------ISP >>>| | >>>+----------net2----+ >>> >>>makes two different single points of failure .. aka the >>>NAT itself as well as your ISP >>> >>>Moving the two ISPs to talk to one NAT does not >>>help since you still have a single point of failure.. and it does not >>>work anyway.. Most nats can only handle translating to one >>>address... I have >>>this arrangment in my own router/nat box... It has two ISP's >>>hooked to >>>it and >>>I must run two different instances of the nat software.. one for one >>>interface >>>and the other for the second... these two do NOT know how to >>>communicate >>>about the two networks...This is what is hard.. you must get >>>the NAT's to >>>talk to each other and reserve the SAME port on two seperate networks >>>and setup state. There may be some nat software out there that can >>>handle two networks but this is the rarity if it even exits... >>> >>>Yes it can work.. without this.. but not with multihoming in the >>>picture.. except maybe >>>behind the nat (my second drawing).. and in this case it does >>>not really >>>help you >>>that much ... and one can just do the send the INIT with no >>>addresses... >>>I don't >>>see how you could get any benefit of the two internal >>>addresses without >>>external >>>addresses to go with them... Remember a SCTP association is >>>only on ONE port >>>and a NAT uses the ports to find the state... So my second >>>picture gets >>>NO benefit >>>and the second requires intra-nat communications... And if >>>you really wanted >>>it done right you would need to have the nats on seperate boxes with a >>>intra-nat communication protocol so you would have no single point of >>>failure.. >>>not one nat controlling two addresses... which I don't know >>>if it even >>>exits.... >>> >>>R >>> >>> >>>mrajpal@hss.hns.com wrote: >>> >>> >>> >>> >>> >>>>hi >>>> >>>>No! you don't need a SCTP aware NAT, lets suppose NAT has >>>> >>>> >>>> >>>> >>>two addresses, then >>> >>> >>> >>> >>>>both these addresses can be used for the association. The >>>> >>>> >>>> >>>> >>>packets sent by the >>> >>> >>> >>> >>>>peer to any of these addresses will be routed to the sctp >>>> >>>> >>>> >>>> >>>host which has got a >>> >>> >>> >>> >>>>single address. So u have a multihomed association without >>>> >>>> >>>> >>>> >>>the host having more >>> >>> >>> >>> >>>>than one address. >>>>about the misbehaving routers, i'ld like say that its the >>>> >>>> >>>> >>>> >>>multihoming that comes >>> >>> >>> >>> >>>>to rescue when you have diffrent addresses belonging to >>>> >>>> >>>> >>>> >>>different networks, So >>> >>> >>> >>> >>>>while one network is not in good health the packets can take >>>> >>>> >>>> >>>> >>>diffrent route to >>> >>> >>> >>> >>>>reach destination. >>>>Its just that the INIT/INIT ACK chunks that communicate the >>>> >>>> >>>> >>>> >>>addresses to the >>> >>> >>> >>> >>>>peer and if we can send a hostname, we can create the >>>> >>>> >>>> >>>> >>>multi-homed association. >>> >>> >>> >>> >>>>Only restrition I see is dynamically adding or delteting IP >>>> >>>> >>>> >>>> >>>addresses from such >>> >>> >>> >>> >>>>an association. >>>> >>>>And if NAT is sctp aware, which is least likely, you don't >>>> >>>> >>>> >>>> >>>even need the >>> >>> >>> >>> >>>>hostname as the NAT can itself translate the addresses in >>>> >>>> >>>> >>>> >>>INIT/INIT-ACK. >>> >>> >>> >>> >>>>So we don't require anything new from existing NAT box, all >>>> >>>> >>>> >>>> >>>that is required is >>> >>> >>> >>> >>>>to send a hostname in the INIT/ INIT ACK that will be resolved to the >>>>address(es) of NAT. So probably a new interface that allows >>>> >>>> >>>> >>>> >>>a user to specify a >>> >>> >>> >>> >>>>hostname for a socket to bind to. If the NAT io >>>> >>>>regards >>>>manish >>>>www.hssworld.com >>>> >>>> >>>> >>>> >>>> >>>>Ivan.Arias-Rodriguez@nokia.com on 11/28/2002 06:03:35 PM >>>> >>>>To: Manish Rajpal/HSS@HSS, rrs@cisco.com >>>>cc: sctp-impl@external.cisco.com >>>> >>>>Subject: RE: Multihoming with NAT >>>> >>>> >>>> >>>> >>>> Hi! >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>hi, >>>>> >>>>>I don't think so, multihoming can work very well behind a NAT >>>>>too. if NAT can >>>>>translate one address, it can translate n addresses. I don't >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> I think this is precisely the problem... NATs don't >>>> >>>> >>>> >>>> >>>know anything about >>> >>> >>> >>> >>>>SCTP, so at most they can translate the source address of >>>> >>>> >>>> >>>> >>>the IP packet. All the >>> >>> >>> >>> >>>>deployed NATs are not ready to recognize Protocol Number 132 >>>> >>>> >>>> >>>> >>>and then look >>> >>> >>> >>> >>>>inside every of such packets and recognize an INIT/INT ACK >>>> >>>> >>>> >>>> >>>chunk, so it can dig >>> >>> >>> >>> >>>>inside the packet and recognize de address parameters... >>>> >>>> Of course, if you re-code a NAT to do such thing, I >>>> >>>> >>>> >>>> >>>think it would work... >>> >>> >>> >>> >>>>:-/ But, who is the one that is going to re-code all the >>>> >>>> >>>> >>>> >>>existing NATs...? >>> >>> >>> >>> >>>> Besides, I don't really think that having multihoming >>>> >>>> >>>> >>>> >>>while being behind a >>> >>> >>> >>> >>>>NAT is really anything useful... I'm not an expert, but I >>>> >>>> >>>> >>>> >>>would say that you >>> >>> >>> >>> >>>>normally have only one NAT that is "covering" a stub domain. >>>> >>>> >>>> >>>> >>>It means that all >>> >>> >>> >>> >>>>the packets have to go anyway through the NAT... Well, you >>>> >>>> >>>> >>>> >>>can always have >>> >>> >>> >>> >>>>several netwok cards, and then multihoming would prevent >>>> >>>> >>>> >>>> >>>failure if one of the >>> >>> >>> >>> >>>>cards itself fails, but it won't prevent about misbehaving >>>> >>>> >>>> >>>> >>>routers in the way... >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>>>foresee any issue. >>>>>In fact, with NAT, its possible that a host running sctp and >>>>>having single >>>>>address can appear as a multihomed host to the peer. Only NAT >>>>>box has to Map >>>>>both the external addresses to a single internal address. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> But it has to be able to do so... which is not true so far... >>>> >>>> BR Iv >>>> >>>>------------------------------------------------------------- >>>> >>>> >>>> >>>> >>>----------- >>> >>> >>>> >>> >>>------------------------------------------------------------------------ >>> >>> >>>án Arias Rodríguez >>> >>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>regards >>>>>>>manish >>>>>>>www.hssworld.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>"Randall Stewart (cisco)" on 11/28/2002 01:09:00 AM >>>>>>> >>>>>>>To: Manish Rajpal/HSS@HSS >>>>>>>cc: sctp-impl@external.cisco.com >>>>>>> >>>>>>>Subject: Re: Multihoming with NAT >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>Doing this in the kernel is very very difficult.. (see my >>>>>>>earlier email on >>>>>>>this subject). >>>>>>> >>>>>>>To get by a nat one can always just send a INIT with no addresses... >>>>>>>After all multi-homing behind a NAT is not going to work anyway.. >>>>>>> >>>>>>>R >>>>>>> >>>>>>>mrajpal@hss.hns.com wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Hi >>>>>>>> >>>>>>>>The socket draft - 04 no-where specifies an option for user >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>to provide a >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>hostname for an address. This >>>>>>>>creates a problem when a multi-homed endpoint is behind a >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>NAT. As discussed in >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>sctp applicabilty >>>>>>>>statement, this requires a hostname to be sent in INIT/INIT ack. >>>>>>>>My question is how to get a hostname for the address >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>provided in sctp-socket >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>interface. >>>>>>>> >>>>>>>>regards >>>>>>>>manish >>>>>>>>www.hssworld.com >>>>>>>> >>>>>>>>DISCLAIMER: This message is proprietary to Hughes Software Systems >>>>>>>>Limited (HSS) and is intended solely for the use of the individual >>>>>>>>to whom it is addressed. It may contain privileged or confidential >>>>>>>>information and should not be circulated or used for any >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>purpose other >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>than for what it is intended. If you have received this >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>message in error, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>please notify the originator immediately. If you are not >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>the intended >>>>> >>>>> >>>>> >>>>> >>>>>>>>recipient, you are notified that you are strictly prohibited >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>from using, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>copying, altering, or disclosing the contents of this >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>message. HSS accepts >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>no responsibility for loss or damage arising from the use of >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>the information >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>transmitted by this email including damage from virus. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>-- >>>>>>>Randall R. Stewart >>>>>>>ITD >>>>>>>Cisco Systems Inc. >>>>>>>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>-- >>>>>Randall R. Stewart >>>>>ITD >>>>>Cisco Systems Inc. >>>>>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>>-- >>>Randall R. Stewart >>>ITD >>>Cisco Systems Inc. >>>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >>> >>> >>> >>> >>> >>> >>> -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Dec 3 18:04:03 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23917 for ; Tue, 3 Dec 2002 18:04:02 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB3N150J029240 for ; Tue, 3 Dec 2002 15:01:05 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB3N1NQE017168 for ; Tue, 3 Dec 2002 15:01:23 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gB3N0s8b005711 for ; Tue, 3 Dec 2002 15:00:55 -0800 (PST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id gB3Mu2g2004167 for ; Tue, 3 Dec 2002 15:56:02 -0700 (MST) Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id PAA26867 for ; Tue, 3 Dec 2002 15:56:19 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id gB3MuIf24055; Tue, 3 Dec 2002 16:56:18 -0600 (CST) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id QAA20151; Tue, 3 Dec 2002 16:57:39 -0600 (CST) Message-ID: <3DED3235.6C340EE0@Motorola.com> Date: Tue, 03 Dec 2002 16:37:41 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sctp-impl@external.cisco.com Subject: Re: Multihoming with NAT References: <8BAF8B40C4D2D411ADC300508BD63D69020A6A2A@smtp.ss8.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Some general comments on this issue... >From a technical standpoint, almost everyone agrees that NAT is evil, messy, and painful to accept since it breaks many app protocols. But in reality, without NAT as an effective and practical way for boundary protection, the whole IP technology would probably lose a big chunk of its commercial appeals - many companies would become very reluctant to even consider putting anything of value onto the Internet (less of a concern if you are a university). If this were to happen, every company betting on the growth of IP (especially the network gear makers) would suffer the most... In short, NAT has a strong commercial interest behind it and it is going to stay and we have to learn to live with it. Therefore, I'd encourage more discussions and ideas on how to make SCTP work with NAT (I know there are a lot of tech and impl details and challenges). But to simply say SCTP is not going to support NAT probably is not good, since it would cut out a huge piece of commercial value of SCTP as a real world technology. In fact, one of the biggest incentives for a commercial application to move from TCP to SCTP is to gain path robustness via multi-homing. If we tell them "to use SCTP you cannot have both multi-homing and the ability of using NAT to protect your networked assets", many would-be SCTP users would be disappointed. -Qiaobing From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Dec 3 19:45:38 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27614 for ; Tue, 3 Dec 2002 19:45:37 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB40hf0J003721 for ; Tue, 3 Dec 2002 16:43:41 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB40hxv7024295 for ; Tue, 3 Dec 2002 16:43:59 -0800 (PST) Received: from baqaqi.chi.il.us (12-249-3-4.client.attbi.com [12.249.3.4]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gB40hV8b016497 for ; Tue, 3 Dec 2002 16:43:32 -0800 (PST) Received: from baqaqi.chi.il.us (piggy@localhost) by baqaqi.chi.il.us (8.11.0/8.11.0) with ESMTP id gB40cmO26059; Tue, 3 Dec 2002 18:38:52 -0600 Message-Id: <200212040038.gB40cmO26059@baqaqi.chi.il.us> To: Qiaobing Xie cc: sctp-impl@external.cisco.com From: "La Monte Henry Piggy Yarroll" Subject: Re: Multihoming with NAT In-reply-to: Your message of Tue, 03 Dec 2002 16:37:41 -0600. <3DED3235.6C340EE0@Motorola.com> Date: Tue, 03 Dec 2002 18:38:48 -0600 Sender: piggy@baqaqi.chi.il.us On Tue, 03 Dec 2002 16:37:41 -0600, Qiaobing Xie wrote: > Some general comments on this issue... > > From a technical standpoint, almost everyone agrees that NAT is > evil, messy, and painful to accept since it breaks many app > protocols. But in reality, without NAT as an effective and practical > way for boundary protection, the whole IP technology would probably > lose a big chunk of its commercial appeals - many companies would > become very reluctant to even consider putting anything of value > onto the Internet (less of a concern if you are a university). If > this were to happen, every company betting on the growth of IP > (especially the network gear makers) would suffer the most... In > short, NAT has a strong commercial interest behind it and it is > going to stay and we have to learn to live with it. Qiaobing, I believe that you are conflating firewalls with NAT. The fact is that thousands of companies HAVE put large amounts of valuable commercial material on the Internet without the use of NAT. Having said that, I do need to agree that NAT has strong commercial value and that it isn't going to go away anytime soon. Ideally, we should see NAT wane as IPv6 waxes, but that is a slow process at best. > Therefore, I'd encourage more discussions and ideas on how to make > SCTP work with NAT (I know there are a lot of tech and impl details > and challenges). But to simply say SCTP is not going to support NAT > probably is not good, since it would cut out a huge piece of > commercial value of SCTP as a real world technology. In fact, one of > the biggest incentives for a commercial application to move from TCP > to SCTP is to gain path robustness via multi-homing. If we tell them > "to use SCTP you cannot have both multi-homing and the ability of > using NAT to protect your networked assets", many would-be SCTP > users would be disappointed. NAT IS NOT A SECURITY TECHNOLOGY. There are people who try to use it that way, but that is not why it exists, nor why it has commercial significance. NAT exists because of hysteria surrounding IP address depletion. Keep in mind that the path robustness in SCTP can be asymmetric. You can replicate network connectivity for high risk centralized components (like servers), and still have your low risk distributed components (like clients) singly-homed. It is critical that we make it practical for a host behind a NAT box to make a single-homed SCTP connection to a multi-homed peer. I'm not convinced that we have an immediate and burning need for work on multi-homed SCTP support behind multiple NAT boxen. I'll not go so far as to say that work on "Inter-NAT SCTP Coordination Protocol" would be a BAD idea. I just think that the SCTP community has more important work right now. > -Qiaobing From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Dec 4 08:24:18 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09534 for ; Wed, 4 Dec 2002 08:24:17 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB4DN20R029786; Wed, 4 Dec 2002 05:23:02 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAY26584; Wed, 4 Dec 2002 05:23:02 -0800 (PST) Message-ID: <3DEE01A0.9040502@cisco.com> Date: Wed, 04 Dec 2002 07:22:40 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Qiaobing Xie CC: sctp-impl@external.cisco.com Subject: Re: Multihoming with NAT References: <8BAF8B40C4D2D411ADC300508BD63D69020A6A2A@smtp.ss8.com> <3DED3235.6C340EE0@Motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Qiaobing Xie wrote: >Some general comments on this issue... > >>From a technical standpoint, almost everyone agrees that NAT is evil, messy, and painful >to accept since it breaks many app protocols. But in reality, without NAT as an effective >and practical way for boundary protection, the whole IP technology would probably lose a >big chunk of its commercial appeals - many companies would become very reluctant to even >consider putting anything of value onto the Internet (less of a concern if you are a >university). If this were to happen, every company betting on the growth of IP (especially >the network gear makers) would suffer the most... In short, NAT has a strong commercial >interest behind it and it is going to stay and we have to learn to live with it. > > Q: I am surprised by your statements above... in particular you are echoing a myth that I think many companies hold that is just not true... i.e. a NAT provides some kind of security. This is far from the truth but an unfortunate illusion that many people have. NAT's provide NO security.... firewalls do but not NAT's... >Therefore, I'd encourage more discussions and ideas on how to make SCTP work with NAT (I >know there are a lot of tech and impl details and challenges). But to simply say SCTP is >not going to support NAT probably is not good, since it would cut out a huge piece of >commercial value of SCTP as a real world technology. In fact, one of the biggest >incentives for a commercial application to move from TCP to SCTP is to gain path >robustness via multi-homing. If we tell them "to use SCTP you cannot have both >multi-homing and the ability of using NAT to protect your networked assets", many would-be >SCTP users would be disappointed. > > I have never stated the above... Yes we can use multi-homing with SCTP and NAT's but no matter how it is done, NAT's will need to be changed to have intra-nat communication or some other mechanism to setup state between two nats. If you truely want multi-homing you must take out of your picture the single NAT that serves as a single point of failure... So once you have two NAT's you must have some changes to them that would therefore allow one NAT to setup state in the peer NAT. This could be a Application Gateway of some sort but in order to preserve the "no single point of failure" that you want to get with multi-homing you can't have a single ALG... thus no matter how you look at it code must be put in somewhere to accomplish this setup.. You can veiw the ALG as part of the NAT (as I do) or as a seperate process running .. but it makes no matter how .. it must be one ALG for every NAT in order to gain the benefits of multi-homing... Now once you go in to modifying NATs (adding ALGs or whatever you want to call it) you thus have changes you are putting in to support the state setup in two NATs to allow each of them to "know" about a set of traffic going though the "multi-homed" endpoint. This work must be done plain and simple.. The host-name address does not add anything to this venue. The NAT changes must go on to make things work... When you get in to changing the NAT's you then look at what is easier to do? Support a dual-DNS arrangment and host-names plus all the respective code that is VERY hard to implement in kernel land for SCTP to do lookups... or just to have the NAT munge the INIT packet and translate all addresses in INIT/INIT-ACK... The sheer volume of code and complexity needed tells me the far simpler course is to hack the NAT's only... doing anything else is unrealistic... and actually the nat coding to doe these types of changes is a small amount of work in relative comparison to what the host-name would require both within NAT and within SCTP implementations. There is no gain to doing host-names that I can see... NAT's will need to change no matter if host-names were used or not in order to support SCTP multi-homing.. this is just a sad fact of life (and yes you can call it a ALG change or anything else you want.. but changes will be necessary).. R >-Qiaobing > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Wed Dec 4 08:26:27 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09641 for ; Wed, 4 Dec 2002 08:26:26 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB4DPSLW023312; Wed, 4 Dec 2002 05:25:28 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAY26614; Wed, 4 Dec 2002 05:25:27 -0800 (PST) Message-ID: <3DEE0232.7080306@cisco.com> Date: Wed, 04 Dec 2002 07:25:06 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: La Monte Henry Piggy Yarroll CC: Qiaobing Xie , sctp-impl@external.cisco.com Subject: Re: Multihoming with NAT References: <200212040038.gB40cmO26059@baqaqi.chi.il.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit La Monte Henry Piggy Yarroll wrote: >On Tue, 03 Dec 2002 16:37:41 -0600, Qiaobing Xie wrote: > > >>Some general comments on this issue... >> >>From a technical standpoint, almost everyone agrees that NAT is >>evil, messy, and painful to accept since it breaks many app >>protocols. But in reality, without NAT as an effective and practical >>way for boundary protection, the whole IP technology would probably >>lose a big chunk of its commercial appeals - many companies would >>become very reluctant to even consider putting anything of value >>onto the Internet (less of a concern if you are a university). If >>this were to happen, every company betting on the growth of IP >>(especially the network gear makers) would suffer the most... In >>short, NAT has a strong commercial interest behind it and it is >>going to stay and we have to learn to live with it. >> >> > >Qiaobing, I believe that you are conflating firewalls with NAT. The >fact is that thousands of companies HAVE put large amounts of valuable >commercial material on the Internet without the use of NAT. > >Having said that, I do need to agree that NAT has strong commercial >value and that it isn't going to go away anytime soon. Ideally, we >should see NAT wane as IPv6 waxes, but that is a slow process at >best. > > I agree 100% :> > > >>Therefore, I'd encourage more discussions and ideas on how to make >>SCTP work with NAT (I know there are a lot of tech and impl details >>and challenges). But to simply say SCTP is not going to support NAT >>probably is not good, since it would cut out a huge piece of >>commercial value of SCTP as a real world technology. In fact, one of >>the biggest incentives for a commercial application to move from TCP >>to SCTP is to gain path robustness via multi-homing. If we tell them >>"to use SCTP you cannot have both multi-homing and the ability of >>using NAT to protect your networked assets", many would-be SCTP >>users would be disappointed. >> >> > >NAT IS NOT A SECURITY TECHNOLOGY. There are people who try to use it >that way, but that is not why it exists, nor why it has commercial >significance. NAT exists because of hysteria surrounding IP address >depletion. > >Keep in mind that the path robustness in SCTP can be asymmetric. You >can replicate network connectivity for high risk centralized >components (like servers), and still have your low risk distributed >components (like clients) singly-homed. > > Here also I agree with you.. and the good news is that we already have a workable arrangement for NAT's and SCTP. If you do NOT send any addresses in your INIT/INIT-ACK you will work with NO problem when you go through a NAT... R >It is critical that we make it practical for a host behind a NAT box >to make a single-homed SCTP connection to a multi-homed peer. > >I'm not convinced that we have an immediate and burning need for work >on multi-homed SCTP support behind multiple NAT boxen. I'll not go so >far as to say that work on "Inter-NAT SCTP Coordination Protocol" >would be a BAD idea. I just think that the SCTP community has more >important work right now. > > > >>-Qiaobing >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Dec 4 14:13:22 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29004 for ; Wed, 4 Dec 2002 14:13:21 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB4J6t0R029248 for ; Wed, 4 Dec 2002 11:06:55 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB4J6ttq022062 for ; Wed, 4 Dec 2002 11:06:55 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gB4J6QmW009880 for ; Wed, 4 Dec 2002 11:06:26 -0800 (PST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gB4ImUA5012857; Wed, 4 Dec 2002 11:48:30 -0700 (MST) Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA20570; Wed, 4 Dec 2002 11:43:55 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id gB4Iinf04037; Wed, 4 Dec 2002 12:44:49 -0600 (CST) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id MAA21206; Wed, 4 Dec 2002 12:46:11 -0600 (CST) Message-ID: <3DEE4E05.EF5B910C@Motorola.com> Date: Wed, 04 Dec 2002 12:48:37 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: sctp-impl@external.cisco.com Subject: Re: Multihoming with NAT References: <8BAF8B40C4D2D411ADC300508BD63D69020A6A2A@smtp.ss8.com> <3DED3235.6C340EE0@Motorola.com> <3DEE01A0.9040502@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Randy, By "NAT" I did not mean the specific "address translation" function. Instead, I used the term to refer to a group of related gateway functions (e.g., addr translation, firewall, visitor gateway, web proxy, content caching server, etc.), i.e., all those middle boxes that involve in address/port manipulations. SCTP multi-homing poses a general and common challenge to all those boxes. And the "include no addr in INIT/INIT-ACK" approach may be a good short term solution and acceptable in some situations, but it does remove SCTP's multi-homing advantage. I don't want to tell people there should not be a long term solution that can support full multi-homing SCTP associations across those middle boxes. I agree that having a multi-homed SCTP association going through a single NAT/middle-box is not the best thing, but it is still far better than not to have multi-homing. True, the box would become a single point of failure in the path of the multi-homed association, but if you fall back to single-homed association, every point along your path would become a single-point-of-failure. -Q "Randall Stewart (cisco)" wrote: > > Qiaobing Xie wrote: > > >Some general comments on this issue... > > > >>From a technical standpoint, almost everyone agrees that NAT is evil, messy, and painful > >to accept since it breaks many app protocols. But in reality, without NAT as an effective > >and practical way for boundary protection, the whole IP technology would probably lose a > >big chunk of its commercial appeals - many companies would become very reluctant to even > >consider putting anything of value onto the Internet (less of a concern if you are a > >university). If this were to happen, every company betting on the growth of IP (especially > >the network gear makers) would suffer the most... In short, NAT has a strong commercial > >interest behind it and it is going to stay and we have to learn to live with it. > > > Q: > > I am surprised by your statements above... in particular you are echoing > a myth that I think > many companies hold that is just not true... i.e. a NAT provides some > kind of security. This > is far from the truth but an unfortunate illusion that many people have. > NAT's provide NO > security.... firewalls do but not NAT's... > > >Therefore, I'd encourage more discussions and ideas on how to make SCTP work with NAT (I > >know there are a lot of tech and impl details and challenges). But to simply say SCTP is > >not going to support NAT probably is not good, since it would cut out a huge piece of > >commercial value of SCTP as a real world technology. In fact, one of the biggest > >incentives for a commercial application to move from TCP to SCTP is to gain path > >robustness via multi-homing. If we tell them "to use SCTP you cannot have both > >multi-homing and the ability of using NAT to protect your networked assets", many would-be > >SCTP users would be disappointed. > > > > > I have never stated the above... Yes we can use multi-homing with SCTP > and NAT's but > no matter how it is done, NAT's will need to be changed to have > intra-nat communication > or some other mechanism to setup state between two nats. If you truely > want multi-homing > you must take out of your picture the single NAT that serves as a single > point of failure... > > So once you have two NAT's you must have some changes to them that would > therefore allow > one NAT to setup state in the peer NAT. This could be a Application > Gateway of some sort but > in order to preserve the "no single point of failure" that you want to > get with multi-homing you > can't have a single ALG... thus no matter how you look at it code must > be put in somewhere > to accomplish this setup.. You can veiw the ALG as part of the NAT (as I > do) or as a seperate > process running .. but it makes no matter how .. it must be one ALG for > every NAT in order > to gain the benefits of multi-homing... > > Now once you go in to modifying NATs (adding ALGs or whatever you want > to call it) you thus > have changes you are putting in to support the state setup in two NATs > to allow each of > them to "know" about a set of traffic going though the "multi-homed" > endpoint. This work > must be done plain and simple.. > > The host-name address does not add anything to this venue. The NAT > changes must go > on to make things work... > > When you get in to changing the NAT's you then look at what is easier to > do? Support > a dual-DNS arrangment and host-names plus all the respective code that > is VERY hard > to implement in kernel land for SCTP to do lookups... or just to have > the NAT munge > the INIT packet and translate all addresses in INIT/INIT-ACK... > > The sheer volume of code and complexity needed tells me the far simpler > course is to > hack the NAT's only... doing anything else is unrealistic... and > actually the nat > coding to doe these types of changes is a small amount of work in > relative comparison to > what the host-name would require both within NAT and within SCTP > implementations. > > There is no gain to doing host-names that I can see... NAT's will need > to change > no matter if host-names were used or not in order to support SCTP > multi-homing.. this is > just a sad fact of life (and yes you can call it a ALG change or > anything else you > want.. but changes will be necessary).. > > R > > >-Qiaobing > > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Dec 4 15:49:52 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03138 for ; Wed, 4 Dec 2002 15:49:51 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB4KllK0013246 for ; Wed, 4 Dec 2002 12:47:47 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB4KljSi003412 for ; Wed, 4 Dec 2002 12:47:46 -0800 (PST) Received: from mail-gw.radisys.com (mail-gw.radisys.com [206.102.10.35]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gB4Klffw021802 for ; Wed, 4 Dec 2002 12:47:42 -0800 (PST) Received: by mail-gw.radisys.com (Postfix, from userid 5) id 2F9DE4E7DB; Wed, 4 Dec 2002 12:45:04 -0800 (PST) Received: from notes.radisys.com(206.103.52.220) via SMTP by mail-gw.radisys.com, id smtpdAAA8ZaaNx; Wed Dec 4 12:44:01 2002 Subject: Same transport addresses for two SCTP associations within a host To: sctp-impl@external.cisco.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Simon.Zhuang@radisys.com Date: Wed, 4 Dec 2002 15:22:50 -0500 X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 5.0.9a |January 7, 2002) at 12/04/2002 12:39:45 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi List, o SCTP endpoint: The logical ............... A transport address used by an SCTP endpoint must not be used by another SCTP endpoint. In other words, a transport address is unique to an SCTP endpoint. Does this prevent us to use same transport address ( IP address + port number, in case of SCTP running over IP) for two associations within a host? I think that it is OK to have same transport addresses when their peer's transport addresses are different. Simon Radisys Corp. From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Dec 4 17:07:12 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06499 for ; Wed, 4 Dec 2002 17:07:11 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB4Lxm0R023030 for ; Wed, 4 Dec 2002 13:59:48 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB4Lxng0012414 for ; Wed, 4 Dec 2002 13:59:49 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gB4LxJmW024914 for ; Wed, 4 Dec 2002 13:59:20 -0800 (PST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gB4LfSPP029403 for ; Wed, 4 Dec 2002 14:41:28 -0700 (MST) Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA04758 for ; Wed, 4 Dec 2002 14:41:28 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id gB4Lbjf17160; Wed, 4 Dec 2002 15:37:45 -0600 (CST) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id PAA21378; Wed, 4 Dec 2002 15:39:06 -0600 (CST) Message-ID: <3DEE67BC.B9BCBA58@Motorola.com> Date: Wed, 04 Dec 2002 14:38:20 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: La Monte Henry Piggy Yarroll CC: sctp-impl@external.cisco.com, TSV WG list Subject: Re: Multihoming with NAT References: <200212040038.gB40cmO26059@baqaqi.chi.il.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, La Monte, (cc'ing this to tvswg list... this is more than implementation I think) ... > I'm not convinced that we have an immediate and burning need for work > on multi-homed SCTP support behind multiple NAT boxen. I'll not go so > far as to say that work on "Inter-NAT SCTP Coordination Protocol" > would be a BAD idea. I just think that the SCTP community has more > important work right now. I don't think I can speak for the SCTP users, though :-) For those companies who are currently looking at deploying SCTP for their services (I hope there are) and their infrastructure already contains multiple NAT/middle boxes, this becomes an "immediate and burning" need. Personally, I feel the same as you do, that I don't have any bandwidth to work on the problem now. But I wouldn't discourage others from work on it. There are plentiful of works going on, across multiple WGs, to address UDP and TCP middle box transverse issues, such as stun, but very little is happening for SCTP, which is not good for SCTP's future. I wish someone could have cycles to follow those works and ensure SCTP is adequately considered in their solutions. Technically, SCTP's multi-homing nature does make it more a challenge than UDP and TCP for middle box transverse, but I don't think it is un-solvable. The hostname parameter in SCTP just gives SCTP one more weapon/tool/flexibility than TCP or UDP to deal with the problem. And in my mind I don't automatically map the SCTP hostname parameter to a DNS-qualified hostname - since it is defined as a TLV, I'd prefer to view the parameter as a versatile, generic alternative addressing id. It's a hook, not a solution by itself, that could be mapped to things such as a DNS hostname, some host ID, enum number, pool handle, some user-defined ID... or whatever deemed necessary and useful by a specific solution. I'd love to see someone starting work on this, with or without using the hostname param, and I will try to help anyway I can. This is basically the intention of my first comments. -Qiaobing From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Dec 4 19:56:44 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13295 for ; Wed, 4 Dec 2002 19:56:38 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB50peK0028288 for ; Wed, 4 Dec 2002 16:51:40 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB50pdTm010095 for ; Wed, 4 Dec 2002 16:51:40 -0800 (PST) Received: from gw.openss7.com (IDENT:g7ujNgx4NKwdX8a09GccPI1VXFHnaP8C@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gB50pcfw029775 for ; Wed, 4 Dec 2002 16:51:39 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:tN9J7aHSr+oog2jZTQPZ5/zjWnG8GfDf@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id gB50jrY01081; Wed, 4 Dec 2002 17:45:53 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id gB50jrG14486; Wed, 4 Dec 2002 17:45:53 -0700 Date: Wed, 4 Dec 2002 17:45:52 -0700 From: "Brian F. G. Bidulock" To: Qiaobing Xie Cc: La Monte Henry Piggy Yarroll , sctp-impl@external.cisco.com, TSV WG list Subject: Re: [Tsvwg] Re: Multihoming with NAT Message-ID: <20021204174552.A13909@openss7.org> Reply-To: bidulock@openss7.org References: <200212040038.gB40cmO26059@baqaqi.chi.il.us> <3DEE67BC.B9BCBA58@Motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DEE67BC.B9BCBA58@Motorola.com>; from Qiaobing.Xie@Motorola.com on Wed, Dec 04, 2002 at 02:38:20PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Qiaobing, Unfortunately the Host Name parameter has already been defined to have strict RFC1123 Section 2.1 "host name syntax." This is not a URL (which would have even worse security implications than host name already has). IMO any approach which doesn't relay upon strict coordination between multiple-NATs will open up multi-homed SCTP associations to all manner of attacks. --brian On Wed, 04 Dec 2002, Qiaobing Xie wrote: > Hi, La Monte, > > (cc'ing this to tvswg list... this is more than implementation I think) > > ... > > I'm not convinced that we have an immediate and burning need for work > > on multi-homed SCTP support behind multiple NAT boxen. I'll not go so > > far as to say that work on "Inter-NAT SCTP Coordination Protocol" > > would be a BAD idea. I just think that the SCTP community has more > > important work right now. > > I don't think I can speak for the SCTP users, though :-) For those companies who > are currently looking at deploying SCTP for their services (I hope there are) and > their infrastructure already contains multiple NAT/middle boxes, this becomes an > "immediate and burning" need. > > Personally, I feel the same as you do, that I don't have any bandwidth to work on > the problem now. But I wouldn't discourage others from work on it. There are > plentiful of works going on, across multiple WGs, to address UDP and TCP middle > box transverse issues, such as stun, but very little is happening for SCTP, which > is not good for SCTP's future. I wish someone could have cycles to follow those > works and ensure SCTP is adequately considered in their solutions. > > Technically, SCTP's multi-homing nature does make it more a challenge than UDP and > TCP for middle box transverse, but I don't think it is un-solvable. The hostname > parameter in SCTP just gives SCTP one more weapon/tool/flexibility than TCP or UDP > to deal with the problem. And in my mind I don't automatically map the SCTP > hostname parameter to a DNS-qualified hostname - since it is defined as a TLV, I'd > prefer to view the parameter as a versatile, generic alternative addressing id. > It's a hook, not a solution by itself, that could be mapped to things such as a > DNS hostname, some host ID, enum number, pool handle, some user-defined ID... or > whatever deemed necessary and useful by a specific solution. > > I'd love to see someone starting work on this, with or without using the hostname > param, and I will try to help anyway I can. This is basically the intention of my > first comments. > > -Qiaobing > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Dec 4 22:17:02 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17204 for ; Wed, 4 Dec 2002 22:17:01 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB53F30R010766 for ; Wed, 4 Dec 2002 19:15:03 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB53F0fY023439 for ; Wed, 4 Dec 2002 19:15:00 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gB53EvEj018985 for ; Wed, 4 Dec 2002 19:14:58 -0800 (PST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gB52u8GR001598; Wed, 4 Dec 2002 19:56:08 -0700 (MST) Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id TAA24282; Wed, 4 Dec 2002 19:56:02 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id gB52txf07699; Wed, 4 Dec 2002 20:55:59 -0600 (CST) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id UAA21658; Wed, 4 Dec 2002 20:57:20 -0600 (CST) Message-ID: <3DEEC105.FECD7506@Motorola.com> Date: Wed, 04 Dec 2002 20:59:17 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: bidulock@openss7.org CC: La Monte Henry Piggy Yarroll , sctp-impl@external.cisco.com, TSV WG list Subject: Re: [Tsvwg] Re: Multihoming with NAT References: <200212040038.gB40cmO26059@baqaqi.chi.il.us> <3DEE67BC.B9BCBA58@Motorola.com> <20021204174552.A13909@openss7.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Brian, "Brian F. G. Bidulock" wrote: ...... > Unfortunately the Host Name parameter has already been defined to > have strict RFC1123 Section 2.1 "host name syntax." This is not > a URL (which would have even worse security implications than host > name already has). I don't think we should hang ourselves under that definition if in the future someone comes up with a legitimate use of that TLV but requires a different "name" syntax. Also, a solution may be found without relying on that TLV at all. > > IMO any approach which doesn't relay upon strict coordination between > multiple-NATs will open up multi-homed SCTP associations to all manner > of attacks. Agreed. Any solution must address security issues, just as we are reminded constantly by IESG :-) -Qiaobing From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Dec 5 07:33:49 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09233 for ; Thu, 5 Dec 2002 07:33:48 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB5CSHK0018518 for ; Thu, 5 Dec 2002 04:28:17 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB5CS11d005046 for ; Thu, 5 Dec 2002 04:28:01 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gB5CSFfw008370 for ; Thu, 5 Dec 2002 04:28:16 -0800 (PST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB5CLrW28402 for ; Thu, 5 Dec 2002 14:21:53 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 5 Dec 2002 14:20:42 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Dec 2002 14:20:42 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Dec 2002 14:20:41 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Dec 2002 14:20:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Same transport addresses for two SCTP associations within a host Date: Thu, 5 Dec 2002 14:20:40 +0200 Message-ID: Thread-Topic: Same transport addresses for two SCTP associations within a host Thread-Index: AcKb2CkPdQ6KNtDYQEm0fG+Lb8S5pAAfw9fQ From: To: , X-OriginalArrivalTime: 05 Dec 2002 12:20:41.0890 (UTC) FILETIME=[BA724020:01C29C58] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA09233 Hi! This is a classical mistake. The point is that you establish an association between two endpoints. You can see an endpoint as a kind of "multi-IP socket". Imagine you are just listening. Imagine that you have two endpoints that share an IP address (and of course they use the same port). In this situation, you receive an INIT, and, which endpoint gets it? In TCP you cannot have two sockets listening in the same address and port at the same time. This is kind of similar... Of course, from a single endpoint you can have several associations with some other different endpoints... I hope it helps! BR Iván Arias Rodríguez > -----Original Message----- > From: ext Simon.Zhuang@radisys.com [mailto:Simon.Zhuang@radisys.com] > Sent: 04 December, 2002 22:23 > To: sctp-impl@external.cisco.com > Subject: Same transport addresses for two SCTP associations within a > host > > > Hi List, > > o SCTP endpoint: The logical ............... A transport > address used by an SCTP endpoint must not be used by > another SCTP > endpoint. In other words, a transport address is unique to an > SCTP endpoint. > > Does this prevent us to use same transport address ( IP address + port > number, in case of SCTP running over IP) for two associations within a > host? I think that it is OK to have same transport addresses > when their > peer's transport addresses are different. > > > Simon > Radisys Corp. > > From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Fri Dec 6 08:38:14 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05537 for ; Fri, 6 Dec 2002 08:38:12 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB6DYV0R017134; Fri, 6 Dec 2002 05:34:31 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAY98526; Fri, 6 Dec 2002 05:34:31 -0800 (PST) Message-ID: <3DF0A766.90407@cisco.com> Date: Fri, 06 Dec 2002 07:34:31 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Qiaobing Xie CC: sctp-impl@external.cisco.com Subject: Re: Multihoming with NAT References: <8BAF8B40C4D2D411ADC300508BD63D69020A6A2A@smtp.ss8.com> <3DED3235.6C340EE0@Motorola.com> <3DEE01A0.9040502@cisco.com> <3DEE4E05.EF5B910C@Motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Qiaobing Xie wrote: >Hi, Randy, > >By "NAT" I did not mean the specific "address translation" function. Instead, I >used the term to refer to a group of related gateway functions (e.g., addr >translation, firewall, visitor gateway, web proxy, content caching server, etc.), >i.e., all those middle boxes that involve in address/port manipulations. SCTP >multi-homing poses a general and common challenge to all those boxes. > > Ok, so if we are talking on a broader sense lets talk about each on you mention: 1) firewall - A firewall that is NOT a NAT poses a similar problem to NAT in that a pair of firewalls must make sure a hole is open for outbound connections. Unless of course it is a single point of failure type firewall and then it would need to either (A) open a hole for the ports on all addresses... a simple approach but effective since the inside box would dump silently packets without the right vtag (B) inspect the INIT and use the addresses in the INIT to open the firewall .. the safest way of course .. or (C) if you had a hostname address you could lookup the name... two points about this.. the peer must have bound all the names in the name/address translation list.. otherwise this is no different tha (A) in leaving address/ports open that will be mapped... in fact this will actually add to the nightmare of implementing this thing (now that I think on it).. when you bind you need to somehow bind to that name or all the IP's of the name... which means binding must also do this translation.. (back to the firewall talk)... but one thing to also note about approach (C) is it does NOT save the firewall any work over approach (A).. the firewall must still look through the INIT/INIT-ACK and find the address type "hostname".. aka it must be aware of SCTP chunk formats TLVs and all that... This is also true for NAT's by the way, since you must find the hostname parameter... slice it any way and it means changes to NAT's and firewalls.. 2) visitor gateway - well I am not sure what this is so I will skip this.. maybe you can enumerate what this does.. 3) web-proxy - This on the other hand I know :> and in this case it is proxy'ing for you. It poses no issue with m-homing.. if it is multi-homed.. fine .. if it is not well thats ok too. Now if it is a transparent proxy .. aka a content caching server or one that grabs all packets and then pretends to be the remote end .. this is still not a problem.. since it can respond back as the web server as a singly homed entity... the client can be multi-homed no problem. What you lose here of course is the multi-homed CNN server... but of course you are accessing the data on the proxy and NOT the server anyway.. if the proxy needs to go get content it can still be multi-homed in its download and it can talk to the multi-homed CNN server ok... So really the big issue is <1> which leads us back to NATs etc.. and a couple of important nuggets this email as made me think of: A) binding and hostnames poses issues. B) No matter if hostnames are used or not.. the guy dealing with them (firewall NAT etc) MUST understand SCTP INIT/INIT-ACK formats.. it needs to parse TLV's to look for an address type... this means software changes... B above especially convices me that that hostnames are of minimal value... R >And the "include no addr in INIT/INIT-ACK" approach may be a good short term >solution and acceptable in some situations, but it does remove SCTP's multi-homing >advantage. I don't want to tell people there should not be a long term solution >that can support full multi-homing SCTP associations across those middle boxes. > >I agree that having a multi-homed SCTP association going through a single >NAT/middle-box is not the best thing, but it is still far better than not to have >multi-homing. True, the box would become a single point of failure in the path of >the multi-homed association, but if you fall back to single-homed association, >every point along your path would become a single-point-of-failure. > >-Q > >"Randall Stewart (cisco)" wrote: > > >>Qiaobing Xie wrote: >> >> >> >>>Some general comments on this issue... >>> >>>>From a technical standpoint, almost everyone agrees that NAT is evil, messy, and painful >>>to accept since it breaks many app protocols. But in reality, without NAT as an effective >>>and practical way for boundary protection, the whole IP technology would probably lose a >>>big chunk of its commercial appeals - many companies would become very reluctant to even >>>consider putting anything of value onto the Internet (less of a concern if you are a >>>university). If this were to happen, every company betting on the growth of IP (especially >>>the network gear makers) would suffer the most... In short, NAT has a strong commercial >>>interest behind it and it is going to stay and we have to learn to live with it. >>> >>> >>> >>Q: >> >>I am surprised by your statements above... in particular you are echoing >>a myth that I think >>many companies hold that is just not true... i.e. a NAT provides some >>kind of security. This >>is far from the truth but an unfortunate illusion that many people have. >>NAT's provide NO >>security.... firewalls do but not NAT's... >> >> >> >>>Therefore, I'd encourage more discussions and ideas on how to make SCTP work with NAT (I >>>know there are a lot of tech and impl details and challenges). But to simply say SCTP is >>>not going to support NAT probably is not good, since it would cut out a huge piece of >>>commercial value of SCTP as a real world technology. In fact, one of the biggest >>>incentives for a commercial application to move from TCP to SCTP is to gain path >>>robustness via multi-homing. If we tell them "to use SCTP you cannot have both >>>multi-homing and the ability of using NAT to protect your networked assets", many would-be >>>SCTP users would be disappointed. >>> >>> >>> >>> >>I have never stated the above... Yes we can use multi-homing with SCTP >>and NAT's but >>no matter how it is done, NAT's will need to be changed to have >>intra-nat communication >>or some other mechanism to setup state between two nats. If you truely >>want multi-homing >>you must take out of your picture the single NAT that serves as a single >>point of failure... >> >>So once you have two NAT's you must have some changes to them that would >>therefore allow >>one NAT to setup state in the peer NAT. This could be a Application >>Gateway of some sort but >>in order to preserve the "no single point of failure" that you want to >>get with multi-homing you >>can't have a single ALG... thus no matter how you look at it code must >>be put in somewhere >>to accomplish this setup.. You can veiw the ALG as part of the NAT (as I >> do) or as a seperate >>process running .. but it makes no matter how .. it must be one ALG for >>every NAT in order >>to gain the benefits of multi-homing... >> >>Now once you go in to modifying NATs (adding ALGs or whatever you want >>to call it) you thus >>have changes you are putting in to support the state setup in two NATs >>to allow each of >>them to "know" about a set of traffic going though the "multi-homed" >>endpoint. This work >>must be done plain and simple.. >> >>The host-name address does not add anything to this venue. The NAT >>changes must go >>on to make things work... >> >>When you get in to changing the NAT's you then look at what is easier to >>do? Support >>a dual-DNS arrangment and host-names plus all the respective code that >>is VERY hard >>to implement in kernel land for SCTP to do lookups... or just to have >>the NAT munge >>the INIT packet and translate all addresses in INIT/INIT-ACK... >> >>The sheer volume of code and complexity needed tells me the far simpler >>course is to >>hack the NAT's only... doing anything else is unrealistic... and >>actually the nat >>coding to doe these types of changes is a small amount of work in >>relative comparison to >>what the host-name would require both within NAT and within SCTP >>implementations. >> >>There is no gain to doing host-names that I can see... NAT's will need >>to change >>no matter if host-names were used or not in order to support SCTP >>multi-homing.. this is >>just a sad fact of life (and yes you can call it a ALG change or >>anything else you >>want.. but changes will be necessary).. >> >>R >> >> >> >>>-Qiaobing >>> >>> >>> >>> >>> >>> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Dec 9 19:57:23 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11477 for ; Mon, 9 Dec 2002 19:57:22 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gBA0u5Kv004704 for ; Mon, 9 Dec 2002 16:56:05 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBA0u4TU009078 for ; Mon, 9 Dec 2002 16:56:05 -0800 (PST) Received: from 13.54.25.10 ([80.255.43.170]) by proxy3.cisco.com (8.12.2/8.11.2) with SMTP id gBA0tgZW019123 for ; Mon, 9 Dec 2002 16:56:00 -0800 (PST) Message-Id: <200212100056.gBA0tgZW019123@proxy3.cisco.com> From: MRS EKI OMORODION To: sctp-impl@external.cisco.com Reply-To: omorodioneki@netscape.net Subject: CONFIDENTIAL Date: Tue, 10 Dec 2002 01:54:30 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="96581e0b-af75-47f9-8b48-51fbf93ef08c" This is a multi-part message in MIME format --96581e0b-af75-47f9-8b48-51fbf93ef08c Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MRS. EKI OMORODION #8 Queens Drive Ikoyi Lagos. Email:omorodioneki@netscape.net INTRODUCTION: l am Mrs. Eki Omorodion l know this proposal will come to you as a surprise because we have not met before either physically or through correspondence. I have no doubt in your ability to handle this proposal involving huge sum of money. THE SUBJECT: MY HUSBAND CHIEF JOSEPH OMORODION (Now Late) was the Royal Head of my Community, JESSE (an oil rich town)in Nigeria. My late husband=92S community produces 3.5% of the total crude oil production in Nigeria and 0.5% of the Dollar value of each barrel is paid to my husband as royalty by the Federal Government. My husband was also the Chairman of OMPADEC,Jesse branch. In his position as the Royal head and Chairman of the OMPADEC, Jesse branch, he made some money which he left for me and our children as the only thing to inherit. The money is Twelve Million US Dollars($12M). Though this said fund accumulated between the period 1976-1998. Due to poor banking system in Nigeria and political instability as a result of past Military rules (1985-1999), he deposited this Money in a Strong Room/safe with an open beneficiary in Apex Bank of Nigeria pending when he would finish arrangement to transfer it abroad as a CONTRACT PAYMENT. He was planning this when he died late last year of Heart Attack. THE PROPOSAL: Just before my husband died he called my attention to the money and charged me to look for a foreigner who would assist me in the transfer / investment of the funds abroad. So l would be very grateful if you could accept to help me archieve this great objective. I promise to give you 20% of the total funds transferred to your vital bank account as compensation for your assistance. Five percent (5%)would be set aside to take care of all expenses we may incure during the transaction. To indicate your interest, contact me urgently and confidentially for more information and the roles you will play in this business. All the legal information concerning this Money will be sent to you as soon as we agree together. Send your reply through this mail box, or see the note below Yours faithfully, MRS. Eki Omorodion. N.B I will like you to provide me immediately with your full names, telephone and fax numbers to enable my eldest son samson Omorodion to contact you. He shall handle this transaction from A-Z on behalf of the family. Alternatively you can call him on his telephone numbers 234-1-7761459, 873-762-533-730, fax 873-762-533-731 Ask him for the code and he shall respond GOODLUCK before discussion. Just to be sure that you are speaking to him. --96581e0b-af75-47f9-8b48-51fbf93ef08c-- From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Dec 10 07:21:20 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04710 for ; Tue, 10 Dec 2002 07:21:19 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gBACKiKv017373; Tue, 10 Dec 2002 04:20:44 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ABB44951; Tue, 10 Dec 2002 04:20:43 -0800 (PST) Message-ID: <3DDC2E6C.2010403@cisco.com> Date: Wed, 20 Nov 2002 18:53:00 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Grimm CC: "sctp-impl@external.cisco.com" Subject: Re: v4-mapped-v6 addresses with SCTP Sockets API. References: <3DC84D31.7BD62BBB@us.ibm.com> <3DDA57CE.6030809@cisco.com> <3DDA6AC4.830BA901@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jon Grimm wrote: >Hi Randy, > >Spec'ing a mechanism to set/get behavior seems reasonable, though the >choice of default is arguable given RFC 2553 expectations. > > arguably one could make the default be that you get a mapped address... but as you point out reality does byte :> We call the option: SCTP_I_WANT_MAPPED_V4_ADDR Somewhat appropriate I think :>.. I can add it to the draft if folks think it is worthwhile and then we can debate if it should be on by default or off :> Reality does tend to show that users don't want to take and write there app to convert the v4 addresses into v6 mapped.. and then handle them.. I think your assessment that there are a few v4 only apps or ones that at times do v4 only is probably the right assesment.. It might be a wonderful world where v6 was deployed but it is just not reality yet... R >OTOH, from your porting experiences it doesn't sound like application >are really taking advantage of v4-mapped-v6 addresses in a way to >consolidate their code. Is this likely due to the application still >needing to support PF_INET only systems? That darn reality just keeps >creeping in, don't it? > >I'll watch for a mechanism (I'm assuming sockopt here.) forthcoming. A >recvmsg flag seems overkill as an application would surely just want one >addressing format. > >Best Regards, >Jon > > > >"Randall Stewart (cisco)" wrote: > > >>Jon: >> >>Some comments from a boring bof :-> >> >>Jon Grimm wrote: >> >> >> > > > > > >>I don't think that it is NOT supported... but implied as to the way you >>want to do it.. >> >>In our implementation: >> >>- A IPv4 address can be sent to a IPv6 address (assuming you have not >> set the V6_ONLY flag on the socket). Or if you prefer you can send to >> a mapped V4 address and the stack will convert it to V4... >> >>- In reading an address... if someone sends to you from an IPv4 address >> you will read from your IPv6 socket one of two things... either a true >> IPv4 address OR a IPv4 mapped address. This is dependant on a flag >> that we put in the API. The default is you get IPv4 addresses as IPv4 >>addresses...even >> >> > > > >>Right now the document leaves it open.. but we may want to put >>some minor text in that specifies that a applicaiton should >>always have the ability to assure all v4 addresses are mapped if >>we have a v6 socket... >> >>That way an app COULD be written to deal with v6 only address styles ** >>a poor >>design in my mind ** but we can allow bad designs too :-) >> >>R >> >> >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Dec 10 08:53:33 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06271 for ; Tue, 10 Dec 2002 08:53:32 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBADpLFp027003 for ; Tue, 10 Dec 2002 05:51:21 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBADpK97020687 for ; Tue, 10 Dec 2002 05:51:20 -0800 (PST) Received: from out013.verizon.net (out013pub.verizon.net [206.46.170.44]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gBADpI27002462 for ; Tue, 10 Dec 2002 05:51:19 -0800 (PST) Received: from duck ([67.212.86.225]) by out013.verizon.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with ESMTP id <20021210133228.FBGH1248.out013.verizon.net@duck> for ; Tue, 10 Dec 2002 07:32:28 -0600 Message-ID: <235470-2200212210133531620@duck> X-Priority: 3 Reply-To: market.access@verizon.net X-MSMail-Priority: Normal Errors-to: market.access@verizon.net Organization: Market*Access Int'l From: "David Dickson" To: "SCTP-IMPL@EXTERNAL.CISCO.COM" Subject: Homeland Def. Trng & Grants - Jan 14-16, 2003 - New Speakers Added-Colo Sprngs Date: Tue, 10 Dec 2002 08:35:31 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA06271 TO: SCTP-IMPL@EXTERNAL.CISCO.COM Homeland Defense and Homeland Security in the 21st Century Regional, State and Local Strategies Homeland Defense Training Conference *** Includes special Grants Workshop and briefings by the new DoD Northern Command -- See below for details *** Colorado Springs, Colorado Three-day Training Conference and Grants Workshop Tuesday – Wednesday – Thursday * January 14, 15, 16, 2003 The Broadmoor Conference Center Colorado Springs, Colorado 80906 Hotel reservations and Information (800) 634-7711 (Special room rates have been established for conference attendees. When you call to make your reservation, register using the following code: HDJ03.) *** Call our Events Hotline at 703-807-2027 to learn how to register on-line and see updated speaker list *** ****** If your company has a product or service directed at the Homeland Defense Community, then this is the conference you should attend and exhibit at. Early registrations indicate strong attendance by state and local emergency management leaders from the Western states. The new Northern Command will be in strong attendance. If your company sells products or services that will be purchased using grant funds, then you will not want to miss the Grants Workshop ******* About this conference This administration will direct billions of dollars through federal and state agencies with the goal of improving America’s ability to detect, respond, recover and reconstitute from terrorist attacks. Many of these improvements will directly assist state and local leaders as they also respond to national disasters and major industrial accidents. Funding will include pending funds from the First Responder Initiative now before congress. This $3.5 billion dollar initiative will be focused at state and local needs for communications, emergency medical and first responders. America’s 3,000 counties and 18,000 cities all have varying needs and requirements based on infrastructure and threat. An important element of planning is the development of regional agreements thus saving valuable resources by developing joint support agreements and response plans. This conference will examine the development of strategies, requirements, solutions and plans at the regional, state and local levels. Federal agency support programs will also be examined. Other topics include: * Report on federal and state grants to support homeland defense initiatives * Grants workshop with tips, tools, lessons-learned * Briefings by Northern Command on roles, mission and requirements * Report from Capital Hill on pending legislation, funding and new programs * Federal agency reports on roles at regional, state and local levels Who Should Attend * Regional, state and local emergency management executives and senior staff * Federal and DoD managers with an assigned mission in homeland defense * Industry executives with products and services that support homeland defense * Trainers and instructors in emergency response * State and local grants staff interested in updating their understanding of available grants and grants application techniques Speakers Include: * Rear Admiral Daniel H. Stone, United States Navy, Director of J4 Logistics and Engineering for North American Aerospace Defense Command (NORAD) and United States Northern Command (NORTHCOM) * Dennisses Valdes, Deputy Director, Environmental Response Team (ERT) West, EPA * Dr. Ron Sega - Director, Defense Research & Engineering (DDR&E) (invited) * Dr. Charles Benight, Associate Professor of Psychology, Department of Psychology, University of Colorado at Colorado Springs * Jeff Goldberg EMT-P, Emergency Management Advisor to the Director of Integrated Support Services, Library of Congress * Eric Mason - Supervisory Special Agent, CALEA Implementation Section, FBI * William E. Ayen Ph.D., Director, Network, Information, and Space Security Center (NISSC), University of Colorado * Robert E. Roberts, Regional Administrator, EPA * Valerie McNevin, Chief Information Security Officer and Privacy for the State of Colorado, State of Colorado Office of CIO for Info Security * LTC Frederick Hoon, Commander, 8th Weapons of Mass Destruction - Civil Support Team (WMD/CST) * Lyn McCall, COO, Will Interactive Inc * Speaker TBD, Colorado Department of Public Safety * Speaker TBD, Joint Interoperability Test Command (JITC) DOD (Invited) * Montana - Office of Emergency Management (Invited) Grants Workshop Speakers * Michael Paddock , President, Grants Office LLC. (Mr. Paddock will chair the Grants Workshop) * Stephen M. Sorett, Attorney at Law, Reed Smith, Washington, D.C. (Nationally recognized Grants law expert) * Christopher L. Rissetto, Partner, Reed Smith, Washington, D.C. (Nationally recognized Grants law expert) * Mary Beth Enggren, NASASP (National Association of State Agencies for Surplus Properties) * FEMA - First Responder Grants -$3.6 Billion (Name to be provided) Special Exhibit and Sponsor Opportunities Available. Call Cara Lombardi at 703-807-2743 for more information *** Call our Events Hotline at 703-807-2027 to learn how to register on-line and see updated speaker list *** Homeland Defense Training Conference Agenda Day One * 14 January 2003 Afternoon: Registration and check in Evening: Networking reception at the Broadmoor Hotel Day Two All day: Briefings by federal, state and local emergency management executives on plans, requirements, challenges and needs. Day Three Morning: Briefings by federal, state and local emergency management executives on plans, requirements, challenges and needs. Grants Workshop. Afternoon: Networking, check-out Special Grants Workshop During the three-day conference a workshop will be presented by the Colorado Springs Economic Development Corporation, the Homeland Defense Journal, Grants Office and the law firm of ReedSmith. This three-hour workshop will guide attendees through the maze of federal grants, provide tips and tools for preparing your grants and a proprietary database of over 160 federal, state and private grants for homeland defense and homeland security. Two distinguished legal experts in Grants law will walk the attendees through post award requirements for audit and compliance. No state, city or county grants manager should miss this important session. If your company has a product or service that will likely be purchased with grants funds, you should attend this very important workshop. Sponsor Exhibit Area A limited number of sponsor exhibits will be available for networking and information exchange. These exhibits will focus on industry and government agency solutions for homeland defense related products and services. Major corporations and Colorado small business will be featured. Exhibits, case studies and demonstrations will provide the attendee with a wide range of product and solutions information. Sponsors * Colorado Springs Economic Development Corporation * Colorado Springs Chamber of Commerce * Homeland Defense Journal * University of Colorado * XAWare, Inc. * Disaster Recovery Institute International * Contingency Planning and Management Online * Grants Office, LLC * ReedSmith, LLC * INPUT * Colorado Space Enterprise (Formerly Colorado Space Council) Registration Information Corporate/Industry $795 Government $345 Small business (less than 100 employees) $495 University of Colorado Staff $295 Includes meals, reception, conference, proceedings binder, Grants training, Grants database researched and compiled by Market*Access. This database retails for $295.00 and is provided to each attendee at the training course for Grants. *** Call our Events Hotline at 703-807-2027 to learn how to register on-line and see updated speaker list *** __________________________________________________________________________ Homeland Defense and Homeland Security in the 21st Century January 14-16, 2003 Registration Form (Use additional pages as needed for multiple employees) Attendee Name: Title: Company/Agency: Company/Agency Web site: Address: City: State: Zip Code: Email: Telephone: Fax: Note: Payment requested in advance. Please check one of the following as your form of payment: [ ] Check Make checks payable to: Market*Access International Send to: Market*Access, 4301 Wilson Boulevard, Suite 1003, Arlington VA 22203 [ ] VISA [ ] MasterCard [ ] American Express Account Number: ___________________________Exp. Date___________________ Cardholder Name: ______________________________________________________ Signature (required) or telephone order _______________________________________ Pre-Registration Fee: Industry: $795 Government: $345 Small Business (100 employees or fewer): $495 University of Colorado Staff: $295 Additional Information can be obtained by calling our EVENTS HOTLINE at 703-807-2027. Registration and Information: Call Parrish S. Knight (703) 807-2748 Fax this form to 703-807-2728. Thank you. This business communication was sent to you to inform you of a training conference for homeland security. If you wish to be REMOVED from this communication, please place REMOVE in the SUBJECT line and REPLY to this message. We do NOT wish to send you emails that you are not interested in receiving. The email address used to send this message was: SCTP-IMPL@EXTERNAL.CISCO.COM *** Call our Events Hotline at 703-807-2027 to learn how to register on-line and see updated speaker list *** If you wish to be REMOVED from this list, please REPLY and place REMOVE in the SUBJECT line. From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Dec 11 16:52:11 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22418 for ; Wed, 11 Dec 2002 16:52:10 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gBBLlifm014007 for ; Wed, 11 Dec 2002 13:47:44 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id gBBLlPiA001034 for ; Wed, 11 Dec 2002 13:47:25 -0800 (PST) Received: from mail-gw.radisys.com (mail-gw.radisys.com [206.102.10.35]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gBBLlb27009130 for ; Wed, 11 Dec 2002 13:47:39 -0800 (PST) Received: by mail-gw.radisys.com (Postfix, from userid 5) id EA8B84E910; Wed, 11 Dec 2002 13:44:34 -0800 (PST) Received: from notes.radisys.com(206.103.52.220) via SMTP by mail-gw.radisys.com, id smtpdBAAiXaiVn; Wed Dec 11 13:44:21 2002 Subject: question about INIT received in COOKIE-WAIT or COOKIE-ECHOED State To: sctp-impl@external.cisco.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Simon.Zhuang@radisys.com Date: Wed, 11 Dec 2002 16:23:21 -0500 X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 5.0.9a |January 7, 2002) at 12/11/2002 01:40:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi List, On Page 61 in RFC 2960, paragraph 2 After that, the endpoint MUST NOT change its state, ........ I think that, basically it means "the corresponding TCB MUST NOT be changed.". However, I am not sure. Simon From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Wed Dec 11 17:36:20 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23792 for ; Wed, 11 Dec 2002 17:36:19 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBBMW0jS001942 for ; Wed, 11 Dec 2002 14:32:00 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id gBBMW4ne001195 for ; Wed, 11 Dec 2002 14:32:04 -0800 (PST) Received: from mail-gw.radisys.com (mail-gw.radisys.com [206.102.10.35]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gBBMWKsu010853 for ; Wed, 11 Dec 2002 14:32:21 -0800 (PST) Received: by mail-gw.radisys.com (Postfix, from userid 5) id 937E64EA05; Wed, 11 Dec 2002 14:28:58 -0800 (PST) Received: from notes.radisys.com(206.103.52.220) via SMTP by mail-gw.radisys.com, id smtpdAAArCai.0; Wed Dec 11 14:28:17 2002 Subject: Inconsistent handling of INIT ACK in case of invalid parameter values To: sctp-impl@external.cisco.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Simon.Zhuang@radisys.com Date: Wed, 11 Dec 2002 17:07:11 -0500 X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 5.0.9a |January 7, 2002) at 12/11/2002 02:24:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi List, On Page 53 in RFC 2960, the last paragraph is: If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it MUST respond with an ABORT chunk. However, in section 2.22.2 in draft-ietf-tsvwg-sctpimpguide-07.txt, If the value of the Initiate Tag in a received INIT ACK chunk is found to be 0, the receiver MUST destroy the association discarding its TCB. The receiver MAY send an ABORT for debugging purpose. I think that, to be consistent, change is necessary to handle INIT ACK on page 53 in case of invalid parameter values, etc. MAY instead of MUST should be used for INIT ACK. Simon From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Thu Dec 12 07:35:27 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20869 for ; Thu, 12 Dec 2002 07:35:26 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBCCQYjS018878 for ; Thu, 12 Dec 2002 04:26:34 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBCCQtIP017762 for ; Thu, 12 Dec 2002 04:26:56 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gBCCQg27028524 for ; Thu, 12 Dec 2002 04:26:44 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBCC9JW16382 for ; Thu, 12 Dec 2002 14:09:19 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Dec 2002 14:07:57 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Dec 2002 14:07:57 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Dec 2002 14:07:57 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Dec 2002 14:07:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: question about INIT received in COOKIE-WAIT or COOKIE-ECHOED State Date: Thu, 12 Dec 2002 14:07:56 +0200 Message-ID: Thread-Topic: question about INIT received in COOKIE-WAIT or COOKIE-ECHOED State Thread-Index: AcKhYPh+DMzkGbd2R2+YGmoebBW5HwAdXJLw From: To: , X-OriginalArrivalTime: 12 Dec 2002 12:07:57.0002 (UTC) FILETIME=[1B6DDAA0:01C2A1D7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA20869 Hi Simon! It means that you don't have the state in which the endpoint is. If you are either in the COOKIE WAIT or COOKIE ECHO state, after sending back the INIT ACK chunk, you don't change your state (in fact, the normal state after sending an INIT ACK would be no state, i.e., CLOSED). But you are right, basically this means that you don't have to make any change to your TCB. I hope it helps. BR Iván Arias Rodríguez > -----Original Message----- > From: ext Simon.Zhuang@radisys.com [mailto:Simon.Zhuang@radisys.com] > Sent: 11 December, 2002 23:23 > To: sctp-impl@external.cisco.com > Subject: question about INIT received in COOKIE-WAIT or COOKIE-ECHOED > State > > > Hi List, > > On Page 61 in RFC 2960, paragraph 2 > > After that, the endpoint MUST NOT change its state, ........ > > > I think that, basically it means "the corresponding TCB MUST NOT be > changed.". However, I am not sure. > > Simon > > From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Thu Dec 12 09:01:29 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23758 for ; Thu, 12 Dec 2002 09:01:28 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gBCDvpfm005638; Thu, 12 Dec 2002 05:57:51 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ABC21299; Thu, 12 Dec 2002 05:57:50 -0800 (PST) Message-ID: <3DF895DD.5020306@cisco.com> Date: Thu, 12 Dec 2002 07:57:49 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon.Zhuang@radisys.com CC: sctp-impl@external.cisco.com Subject: Re: question about INIT received in COOKIE-WAIT or COOKIE-ECHOED State References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Simon: The context for page 61 is that you have an association and are happy with it as far as you are concerned... then all of a sudden you receive an INIT from your peer... (aka it may have restarted with you un-aware of this or it is a impostor). Now you send back the INIT-ACK as said but you don't want to do anything to your TCB since you do not really know if the guy is really your peer or some evil doer trying to mess you up... R Simon.Zhuang@radisys.com wrote: >Hi List, > >On Page 61 in RFC 2960, paragraph 2 > > After that, the endpoint MUST NOT change its state, ........ > > >I think that, basically it means "the corresponding TCB MUST NOT be >changed.". However, I am not sure. > >Simon > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Thu Dec 12 09:10:04 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24188 for ; Thu, 12 Dec 2002 09:10:03 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gBCE4jKv018227; Thu, 12 Dec 2002 06:04:45 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ABC21409; Thu, 12 Dec 2002 06:04:44 -0800 (PST) Message-ID: <3DF8977B.7060906@cisco.com> Date: Thu, 12 Dec 2002 08:04:43 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon.Zhuang@radisys.com CC: sctp-impl@external.cisco.com Subject: Re: Inconsistent handling of INIT ACK in case of invalid parameter values References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Simon.Zhuang@radisys.com wrote: >Hi List, > >On Page 53 in RFC 2960, the last paragraph is: > > If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but > decides not to establish the new association due to missing mandatory > parameters in the received INIT or INIT ACK, invalid parameter > values, or lack of local resources, it MUST respond with an ABORT > chunk. > > Hmm.. ok the above wording is in the "normal" establishment context.. this basically says you (the receiver of an association) have the right to recognize you are out of resources and send an abort.... this make sense :> >However, in section 2.22.2 in draft-ietf-tsvwg-sctpimpguide-07.txt, > > If the value of the Initiate Tag in a received INIT ACK chunk is > found to be 0, the receiver MUST destroy the association >discarding > its TCB. The receiver MAY send an ABORT for debugging purpose. > >I think that, to be consistent, change is necessary to handle INIT ACK on >page 53 in case of invalid parameter values, etc. MAY instead of MUST >should be used for INIT ACK. > No, I don't think so... in the case above you are talking about normal association procedures, no one as done anything wrong and you decide .. hey I have no resources for this association. In the 2.22.x case we are dealing with a INIT-ACK has arrived in response to my INIT.. however my "tenative peer" that I want to bring up an association with does something illegal... aka sets the TAG value in the INIT-ACK to 0. Now if you send back an abort what good does it do? There is no TCB in the sender of the INIT-ACK... has pointed out in previous list discussion the ABORT may help in debugging purposes but it does NOTHING as far as getting rid of state .. This is why the change makes it a MAY and I don't see that a normal association establishment is equivilant to where someone discovers it is out of resources... R > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Fri Dec 13 18:42:25 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10162 for ; Fri, 13 Dec 2002 18:42:23 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBDNd2jS021885; Fri, 13 Dec 2002 15:39:02 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBDNdO4t009612; Fri, 13 Dec 2002 15:39:24 -0800 (PST) Received: from Localhost (80-235-101-162-dsl.plus.estpak.ee [80.235.101.162]) by proxy1.cisco.com (8.12.2/8.11.2) with SMTP id gBDNdI28003733; Fri, 13 Dec 2002 15:39:20 -0800 (PST) Message-Id: <200212132339.gBDNdI28003733@proxy1.cisco.com> From: GS Union Subject: Őî÷ó ďîäĺëčňüń˙ ń âŕěč číôî î çŕđŕáîňęĺ â číňĺđíĺňĺ. Organization: Home Reply-To: alexunion121@hotmail.com X-Mailer: The Bat! (v1.52f) Business Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="= Multipart Boundary 1214020139" Date: Sat, 14 Dec 2002 01:39:09 +0200 This is a multipart MIME message. --= Multipart Boundary 1214020139 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit Çäđŕâńňâóéňĺ. Ĺńëč Âű đŕáîňŕĺňĺ čëč ňîëüęî íŕ÷číŕĺňĺ çŕđŕáŕňűâŕňü â číňĺđíĺňĺ, ĺńëč Âŕě ĺů¸ íĺ ďîâĺçëî čëč äŕćĺ ďîâĺçëî â ôčíŕíńîâîě ďëŕíĺ, ňî őî÷ó Âŕě ďđĺäëîćčňü âĺńüěŕ őîđîřčé çŕđŕáîňîę, ďđč ďîěîůč číňĺđíĺňŕ, ďđî÷čňŕéňĺ âëîćĺíčĺ č Âŕě âń¸ ńňŕíĺň ďîí˙ňíî, îáĺůŕţ áóäĺň číňĺđĺńíî. Ýňî íĺ ďčđŕěčäŕ č íč÷ĺăî ďîäîáíîăî, íčęîăî íĺ ďđčä¸ňń˙ ďîäęëţ÷ŕňü ę ýňîěó, çŕőëŕěë˙ňü ˙ůčęč ńďŕěîě č ňĺđđîđčçčđîâŕňü ćčňĺëĺé číňĺđíĺňŕ, őîň˙ ĺńëč Âŕě íđŕâčňüń˙ ýňî áîëüřĺ, ňî č ňŕęŕ˙ âîçěîćíîńňü â ýňîě ďđîĺęňĺ íĺ čńęëţ÷ŕĺňń˙... Ĺńëč äóěŕĺňĺ ÷ňî ýňî îáěŕí, ňî Âű âńĺăäŕ ěîćĺňĺ ďĺđĺďđîäŕňü ýňîň ďđĺęň. _ _ Ń óâŕćĺíčĺě Rusmon mail to: ňîň ęîňîđűé â ŕđőčâĺ. --= Multipart Boundary 1214020139 Content-Type: application/octet-stream; name="Ĺůĺ â XIX âĺęĺ çíŕěĺíčňűé ŕíăëčéńęčé ôčëîńîô č ěűńëčňĺëü Ăĺđáĺđň Ńďĺíńĺđ ńęŕçŕë ďî ďîâîäó ďđĺäëŕăŕĺěîăî ěíîé ďđîĺęňŕ.ra" Content-Disposition: attachment; filename="Ĺůĺ â XIX âĺęĺ çíŕěĺíčňűé ŕíăëčéńęčé ôčëîńîô č ěűńëčňĺëü Ăĺđáĺđň Ńďĺíńĺđ ńęŕçŕë ďî ďîâîäó ďđĺäëŕăŕĺěîăî ěíîé ďđîĺęň" Content-Transfer-Encoding: base64 UmFyIRoHAM+QcwAADQAAAAAAAACtjnQggvoA31UAAACOAQACMuh5C4ydhy0d M9oAIAAAAIXppSCiIFhJWCCipaqlIKetoKylraji66kgoK2jq6ip4aqoqSDk qKuu4a7kIKggrOvhq6jipavsIIOl4KGl4OIgka+lreGl4CDhqqCnoKsgr64g r66irqTjIK/gpaSroKOgpayuo64grK2uqSCv4K6lquKgLmRvYwAEVBVJNSB8 MgOCkCD0hZCAYDkg3ISQQYGQIHVEgZBBPkREIDggfTyAYICQQtOAkEwggJB8 QICQgGAg1YKQQTVAHCBBg5AgzYCQIIOQQxcgP0CJkDEggpAgP3VAgZBCMMAC HCGVEQzI0VgYAi0lYxjZ8GMbBjH8EkMY3I0jFiWJYksXwzMaabaQkBCQnZCE AgEckGBCEkA2bNIdnZp6bN3pN02aGwk1ybPgbCSdJ8Oz4a52SE02abNhId2E PTSGzps+BDSA+nwekYDGve3V4m2Nsrlc5VVyqu8xJufDs/emN4sWZl3V1XK5 XOcrlc5yuWv8hnmeZ5nmczzPM8/f39yqq6uruqpVlq8X7Fl9197ifA+H83Q/ 7QPeL+Cwg3GRwkGYN8denz9lfsziDt6jXVHeH3Jkx9jJe2iyKnn0f6PE+N20 E7B42GCDbZ367L3o1N/82vDV0HDwc77Hcv3psUFTnvK8XBa6feD+X6mBXnoO ngyc+9t4jKv3qbdZHLuK6BnrHZHiz2Tv78vn03F1MnuEOyiuDcbpOPQeMn9/ AyXpIuU4xE8n1vr2Y4MdtGwI1dMh5vkEHLJ5+fO5GMvI382S4UEnx3Fc700f LKau/NZr46XCZ+lr9/pEgcATzxelqTf9cmOasJNDyeVSD+MnaP1n6NUjOR79 On10kX91kg0EpafAvj9GSn67u0gfXCxuc/m6XD0HwvsspqxbfM0KDaJAv8Ke XmYMnd6VNd9fFgpCuYQvo4/IXD8TkUT7JNj1zxe/OG66pssb3f5YwTfsPPFS z+F8PIT9+qlBPHvsf1ynxlIxqmx7G02agUF/VJL8aURhv23BwqzVa79Uvh6P vESPAbKCxgzcj88Mr1X78/DroZ0O7c1Pn1MGuijjzxvFfLdQ30MyGhUd1z4a UOJDd1HJIy3hvY3d2jDeZMsk1cb5538NFPnVp98+N3mcSo3quZOT64qfj4pP 64MNsr80k++yhwFU6ir4agFI3sO95mRu7uBko/manzcQ08mWCniXCfv3g7eo 7t0Mlt1cduzfZLdlwqgFjqSeDu/eQB5tINSr/VCzTbm9rpQ4pcSenntYn85J qk/bRVyt7njpA6eyjTk9FumYyo5xVOAGaKeJeF1gUTVw36ftoVEKVOT89qml 58qzHqBsnHUAYW1eJ9d379gALBoKlms5e66SuZu75940Nsy3JkbuzTK6wV9q oBuHfp9+6b5V6QBS5T+tJnw7v2yrDw1AJhq6kA2D4ZxusvlBGPz3ygsGgB8N ybjgtO0hs4dIh0u54dBDo4dOn86Uvfn4eMjlo0/HyUVQ1MbuvPK5FQ8/ePh5 Fn32cAcreq8nDST+d97TVZT4gcZQnwVhhxyGtwDaoGCO+VYfnndJoWGoZWKQ ETnBViCAc2crpQou8jckMcNRrvC3oQogUDWs5gAO9BOka82KoSYA3PUJXfd3 Cq0viqDzxukIVnZJ5likB3HRWcOhhziqnAElmAKw6NXz2kHnzvYdFDolfHp1 AwHD1kGPByyUlnqYNPYjjuD/cGhroOGL21DOq6YRECBgYqCQLoFChqQFWUiI GmKH9bKsTEhmuW3MIMcSpK4UAW79uGFMFrBaqI8rlVC6SNsmVNbK4T/XhHDv cwu3UijDavcvSquOtlEbroxGo2TNILwEjpygtnKxSw1U2bk0DofUkT9awVnA OaQJ6xVpgIACBg+8KimG69gqv3NIpzChEisPlDEZo1b8xEuEogkCBl11Shq/ QhYeolCNgx4H7wJ0D4QqIQOHgTyJGnFWe9b1irUpMIyDyFXUiqWiwnYOmnEC 2uYYxMhXd12pMdQyKrWMxWA1JVvgrgAFt1coQ3BwNaRqIdbQhx2VgOEUwq6t kgheKGSe/g/mizC7eXxJYnK8YVHvR8RQc48NqWCI9LRK71+q8wkELKefs6k4 G5dQDTg42uYKgS0h+8Lyr4VywewYTsdwdIiJHl77cDAsMgjE5dRYPMCgacOM ajYpGN3DDSdEq/tEjsZzAtDjCagcfk5VeXareEaggLNZy9aoLwlPgutTYY5R I0ymwp09Aob8VGKE8F/hsHNmIF4yrEpD1NSYE9a5XtvIsBPAxiI7CtOKsQqg BGgdOWgvW6q5DqLIrzAGYjwOXNJJhFBRkwJAwmBntnfU0FUPUQUlWiIkMVXx 3BX6pprO+VxwCjt1AcNXhDMKhDHJpLFNy+2pgCijx295uYbhg+gDIbp0SBDH Tzd5nHhnMrU5eUwsUHTIBrismLjmFhUl8WNmIQhMepW4VZS7iUY24YQUBAVv CN3wWJgqta9IXV0rlBgemKDUOspqBS7YianmSNaUkTE9SJ0SY9GV12GnoqZY aCWjNI3C/V9IDlmqJQC4FFlYWyuoWiTDpMFhixxHrQhfUFfGJCwdLfqrELyT mEPOhqAMS6Fq7I5neTwCTkWyrFPcu/JCW6kIDowCUCbFojrciygFIKGi4Vf4 K71UDSg8MjDrpVVTFUIb3XBEuCaoKDGgq7GOo6KaQy+TUBlNR8MxVrhrjJik oJBp64IvlaMyazFqbWBkiRHekapJQtiUmJCIGA3pYeWyrepKHxRhxS6KyVUA 3Ul8bFmdUCHxrSv878IpZb8riTyr5fMHA2i4UnfMSMUlXG0qj0xF9gb5dKKH ZPFEaNP2jdIQ8Gty8cAqQBS5WM2iq0k4zMIXUlAZiqEIAl16olDENc9RKwKZ jeQDdriHeONHEqg0DhsNvl3KnEEA28ODVBVZYBW2OI64L7w6UE6Cx2UVV22w xKLpEXZgqx+ErYbnsQjR0xXwigOAd2LKWiOFCcDDF5zHCxROQuXD1b+QNcIK YVWNefM0mPGGJveeHWNfrRVtBnvgxkpGLFCnXCuuuUK84CiVGEjHGVkoWZZr U2FtwbkxLFpBSVwJ5F/gIjXkCnGhxyiyQwwdT7t5+eSH4Tj0/LRUGOwSUk2G 6VRqJEEUWInl5bNAiRJ6qMN4RSALJjXgtdmRVH+MKgClCQewlEhrCCTyKCN4 WE/n1BdGaWBN4pDbnE5e7SQ8XDnizkc/ktpBaKzFvPeyhs2e8c7Pji+XVZNe Ph0qaFno3QkbpMYhQuCSsdoWI4K9uCA3Hh2cDUZTpJQYGP4tioeUiNcsSvJd kQbfKK/AAoe+lk0tFYKYKlUAcn9blRz98pjmTNjoloFdBPI0teOo4VLSmheP WkR7yajNj25jMLIAmTDVh8FnXDDEwsAKFOey8J5FQP5cmObKgHNAEn5KaKQH XFWMm4Y5HgfHs4LU2briMLlERo8HGcVJaKq2uWDMEIRx3X7Mv9SNnZhwL5SG 8FgXxgs45RLccxIQXg5PUiAnkfQFBEFr4yU8AIhb53G6Yw2YVO58CNVA2xMB VpTSWMzpip5KgNKFt+sJgwBv2vNtmEOcKRMc8F9QYCzREBfKsxpX7k2KftGG aytsNiJ0LNDoEjdcKxEiW+KnUiN/YZB7eq6IKjvCtk4IjckKHgsUIgE4PNk2 cH5dOZfK1EUCS5mZ8uOoZDt4D1CKOdLkJYKgcXcds4BJZSYEy2xue1qgPUYR u2FNarDHu0KbS/VyXUF1EiwJjEdFBlyWn5iWxhkixDhO++iSZS+JZUz1aqUV p2eSZMFq6TVesVTBEKtaIC5IY/lkLCfAFPCmAEoIAwWtfUnllcITDXwfXeki 9HJOsyOrwnEFAkQLvVGb5nEJOzRJKcvLfSUJeApR7mGOUmmxwaBoCvNL3U1V avN/P5wcufIIpGmO0WfGFzZikNl3VFdrKylgSgB77xhTGgcw95MySNZPwquu AxEqdS5XcGiwsMUFOMQhwAAtFqnq2ZE4CyqCjKB6SmoCcOFa35NUCuEWcY1H mICiOm6IYArhOqgd+e4VlY2+VLrwda0iG/lFaXElKgw1ca0LqD4flp7V6FGg q+4TU20JqPga7AazS5X0+YBgPKoKEyKO7Ee6QORhuZLDcKFo+sAryX5IE04v PLBOIony8lCj3aQaORddPYh6nmPoElLEYYnjuHfgG8sH1BmgSpqBc22hFXTN SmoxVgJOIZ0moF5ceIRmm+7s1XzpqUWZhVJcKAWaqwXRpTCOCvjXub+pyA58 jIek5KI8QcNZX6RN6oMPpaOMAcvWHUTzW1MqhnUqlPWLFC81Es+g0GrWqnMx mh7vzXfUGIVcuqay0t6krrR004TL0wy7jUMJQATHBAzGGsCWyNQgA4+oJvcm Q4LsFi6cNzwURam03Cc/XVAtMuuldEsj0TPA+UcjJYSBUgBldp+G0UHtOK7c xknmqyiWkSmkhR5ODFT53m8BPKwSzlrgkNggUNWjxbxV3Bt8dG1hsXmu0LQf assgkS7NkzV1O4xyuMQikPg8kFnNOss2wCIRqYOMdQ0WMdgsPoblnT2J6R1r QWg1HjilkXhuVgFrL2E8YZPJW2G5NwWIwdatUevlcpucLReXhgFg3GEUU4c3 IEArSzbxRDGeI9nkzEYzlCkmEgYdGpem0UwVmdX3XrNZUOp1uDEW0lBSFvhM dpqEmP3gGdNzVB27iA9ZKUFtmq+Ijs10NN4n7f9UjHPNGgDkLnfe7k4NV/Lx 9gWUJbM1msX1l5RokVu5mlVTQLJklUMvDODyWl7xVDkl0G6gpTU0r1kXauRL 2VW0dV/DfVpHD6Et1Des1jU95MtaPJnV5YN8woQ+d6dbcEwo63Se9Fk+xdzS BpqgfaQyqkHQ3csW0fl2RJfGnCisa0mY4Prmr4v0roexrs5pgo07dhnN01gy YrDUQqBI/zyxhcKzibkxMVI2jqvWGDSqpQfqg+OhJY1woa+0Vy8FVBbo5Rt0 M+vCULPZkGYYg4bM3UcldOksVHEksYQAyeYu6mwqOe5kg3RrLwSWzymSIJQy 9NeArN00dMLTx6MisZirKu2sHdHFAWRcu/6YYn0ekELlqOuIwv64Zr5wWEJ2 Qm3AAlaZMT6khNJUmFdqUw2sVQQ0DHgCEdAsmpYHXrF2FS0NB0STlehg9gn1 59NE0JkBB1FaaxLXOIu9bvaf8BWd6w2zLaJOVVXZ9USK3haToc01jEvWUAY5 5yFqgi4xPLtweF+Wl8wS4kvhCFIvZCCHRGxpEeeCQKrygbpQCDmCukHpUBWh uquGKQ1cr3EMdABlwFE25tB3gszCr5mN5Yy8AhetVw50suzhxLHin01glt8d va4eJSuKck9nE4rxYQhnriyRyckNihhJxEnI54ijij1ou8WGWCt0Q/hx9OVr gkowUCzDp5iTVpnmkLhT1nry9UI8OFy1CiaqqBVkbwhIjXQ6v6/lCzZps7tu kYaX1MZk+HNtxyOVJpZRmoSGujSvrDUU8WhwNaSburUNA+Fa3ujnRUS7QLVs 2JWI6rJB1bUAzqnhSYuLsNhBOIwaN0w9Wc4toiVHfMKpbk+vlegI9TQ3jM9E PvpmF4+g4EmkDNw4U6exbpPj62ECLF4oP6ULVQHzdy8wMUIIlLp7CzRMlmvF mPnOzHAWGjjqAT+a47oGMcy9xHFIxs2TZaPJOV3Fakyj2D439NpspYm7kjay 5YxrsruBSAsbHUKa9yomgRYtQ8rSMCgZEZAWphKxpca8V+1gaTWJpskS1vRU DhTnHV4aLFeNueqFbZfND0a2BBfM/VapBLNS4asPnhNI3DkdiZTOMVscEbKp LEVe9OimKxHXJg5Uz8WMJG/YiXPpwRGQPDTk8VpbVdy7biEUC7HZpWRDC3jl bQrwKE/7EIol3Qc1sQr+dubU7LOgd1EE4W40u4r+UEvMHLQ/lpdmkqiBFEyb 5eUSOi0HVdyjBsPjE3R6q0hDM/EfvY2AdaVgYrLiBxhxfBZTqYF0xzErByTV nkUy6eYzNjBgdypQ4w2octx9aSmKzSB0C6aZLHRhkirUyc8AwqrUiHazglfC znL8sDRSw62OrVTykWCuWaUfOqWQw6UuPrLBEVNc00C9SNOZedOK1wcaqNnw UXEnpx9Oeu5QlJ3TpigyuSQohT0qoCyuu6GyndSwOJbUaywRkphm6b9fyW6I TZmuCyH2Eoldwzxi6s3KE0y3I+4AudAxjVMU0516VfOobZrxSwj2zsPpYdBD xW7KfXdvOAwYxAW2VgoBPAigWVW1G+mSxZ5aMw+HLGPNn2EeSSaF3fYzyjsv CYzbwD1xyV1yyvWMtNeFk8xEl8wg25cLgHoV029I7ISL2BBZMyqRpknVJCTF LgxdEhTWBbzQZE8SVCtaLICLCanDaFNI1BeOxmqROSjfVdTXW8Fq9leBTTMu 9TWz3A68A/FEnSXATOFsMgjiFWOkpZsIlDIPtlU3NNbPWXgoA6L1CphJLQSH 0EoAi0skmCuafaIVaYXDtomJXJzXGBiS1S3yrEEk9jquOC29IQV0lLdU14gG /OyV08xDYVFQN1rcycTB2EQa9ZdfEe2BjNNmtmvSyq7uG8lXHM3Cg6ilTIh5 JobrDsmMIPJLJeSszXqQuhUWtpaWYdZMX6YRjkwWWgckomEFdyCTEr9EjK+5 U2apRVgeHS4TpCxFnYcSWU+BvxQhWaCOlfGdJd8wdy11CkQJjzAFCshCk4iA qTwCSY0iG3vs714nI4sb0spDWEDTjGwHD8x2VDyqb2eNRJSSpvaCXXEEknrc AWDYTqdvFsQHElLYavonUjLkgFmwCO39TAgeItAtdsy2j1s3mtLwmsR+DYgA EARilCpuYPl31FYJk3DXo+wA9gvVhcvAObVbUAuWQk029jVmHL1RdJrxBJzk k5mnGymJTWORgbQOAa1bDM+MuhYtEhSXGM01TQkp7W0iq9Q47rsAtWIdbwE3 Jq/bQJHj+t6hY4FWNYo9+hMCeYlQ8y2g5IidM7+vAKdqtenAaPYPlfrMcKdQ VValWGS81EPjuIF63VupTqt5Vr/gcNxkaBmgTizeKTENFFilG1JkHy0WZ87Q KF+DkcrLYXuKsRrKfATK4J3+YjOSvg7nuWYEE5QlM4lOXG5w5iQCuH2zGTLK oQu66wQ3cBjwfvE/h4TAfNxCBHUev2LIAqsC/G1ul2n/apPnkKojJpreT1yr DMOnSUWBybyzeZKKoSPBVFzTLwG3YEghoTix0lzUMIe28rAZTFWIH+C0lNhw mMmvOjJpSCpcifafSJACa01Aq6QHFXLKnAY5aGwwwpCiTjkiqty0ToYRjgBJ R7mqDb6LReReXr8LQ2Lw/TPLCM58UxXBw2IhbpEgqJq5BbsCFThqvHBTl5zr RSjl6NU2MpJBC0DOXwPvafAGfeHJfT3kRs5Ih1tA6cUACCSX6VDue4Qz4gxi 3Tbq+O5guFfDNV9OSTqjqYDOh8tb7MyNy9OlNkW6e3JzrQKHNqnK6WTW58hS yeyYQFoddNATBnpsu7l+Y9dcreWaw+lz9xxSkw0MRi7YKpqKcBaqQtQZxFCG MxCAXpt8Pyq3baHXB7wWAhxLWtTCRIN9LQ7p6WuLDkkaxiqBrYcWsaD6XxrO LAdIhVHjaK4xhGs0Ll1UodhszNzjrgwFu4aeZaOEaQnILFbu7PT77eC6i1BF lAg5SClUL6C550RU5zJvdSnVtdLB0aRwSG3Ssl22VooiaG6iZDkszWmZJCtY uDH8lVBMTkCrkfNnT4cJ1rkijfHyscIwvASKWps8csG7lmcBLjUkMQ18X2/q It3m5bRrPogBu8OfCv4z3Tni6G6qjmu2CHLRPgNGAhS3L8/sOyuBUfOqgaj6 XXjqP8Ffbv3Mbue7QvjI0chehNBWU7KBSLxfU4WlotxuklpN0sJn4+FQi1pa iFuUwHqck4KrY/LT58rVEQejdVOhvxMUqnsd9kpt+OQ44Rvax50XS2l8Oh40 SjGydQALkd6LGtsyMDJojHW6BRCyeeG4DHR8Znrj6WMKU7b1NiDMbTlIOVZB RVOF8mTK7/Ui1N5q3CJLFFmtxJ9Qh+oEt5Tdcx8pCopis0zVurylLCrnPEuL riSKUTeSb3rG9lMOxNdVA2gBh+f5wW2KNBjauWmJxpCcRjlaE84cUrYW5Zgs HWv7ybGuJIQd50WMJbNa/bjZOarxnVYw9uoyW3UTNsn2cukqp6Yn/VcuCVVA pJNeVqo1iDxpk5Gg0xdR1nqMNbGknFRV6NS7LL7vCQM24rLbX1jVQQmo56V5 IuxSVWKuCQ63MR2v5Ecknl0WLVKhq8wsBG4sh9+OYTVSY2uFDMPEBcAonaZ5 dgL00eWQzfs20yq9gUXkatc0dZhHyt0Y3boW6Odm1spNySZVWaXa7O5YuFaH fEs47h3NwS1DKWTkYptd9qx0tuuPlRhQ7dFL6BtKFIlpXKANy7SB1YeftGaH mBahRMhdTyZbC64L32kGyVVM+JfPP8WcjiGXDWeNco4py9Y890jinMLjzz5F TTcosC7RxHM0rPITdKO0cx9HMPhnwh+aWS3ENqwNeGcGzYyFzNxmYmfp6+az QnV9l3IQAjFTFN5U2p51yjTqypYSdKsJtR0azSMqrmbCk7HVKiV7dsVQbJcD GL1TGAoizCcUznUbDurj4qxeaDw6mlZSWnsX9G5ZA0feJhz8OeS/vAf4GhhS 0j3Ioc/DZlwAIEs8l0Sgu5EYeA0aeDooRz9c6r99Ar5VQ7wl/hcfDZrh5doh f9Kn+qnmF9IdRZp+fQq5dkqmccrg8SEOIB8O+D1KeBxqvv0qGyT54moh+ahx SaDqVw9UlrRWUBOZ3UOWxoFJvzSuLotRzcGRJmgI0oWNY+3m6yAbov6n5ojA 1TY6Q0aZJu6KW5UHhGgdYRStHMxvOKduV4th1MY5Km2DSMuXlMkJkRABp6dm w8V0uRuWdhLg7I+oGfSOyReX7C4hVOJpl4CSjSZAg6hIo6gLSlM0NrlbOBJk EiidJyHDmRO5MEwuBu/yafbcKN4U6716uCN14q2Tq6imds3PWmDD3mGtpYrq p3J5Gp1OOVNmS3fG0kCmWJiHeTTutjUziwvHRlPtdzCxqImqG+Bkqqgh11yM Apj1s+Xalosj8SKUDvWg0HUXLDoxPEXaDVyUKc84vBwVd1pL+SqZs4NtYoS0 dFivKefFbpFsrxp/Cw1Y+G5rX2NQkDeYwBprMCmOwpuBcyRgeOV8szRyFOa1 FQUqpCnzBwjqdz9l54oesrmiVtQzCpTRR3JU8FmeP48YDEvAnJWp3HAsPao4 4VkAXZhvifCJ+Ix5lRxK4gDeCThVMeUppkK0Li8/uVw1HlcVYtSaCmG0K4QG xFWUTmgJiWuMoF0fS9LXSYQLgnhNTAlMp46Uo9SDq+H+tXjVhG6mazAI+iBl 1pyOAp7QM0OgqGFsSIQPvy3pfh0ztsLQFXkFSHAsUPBBerAYQ+auslAR4Ai9 RBroOUSfKqMnF5IjjHwkMw10iBeaMJMpyZzQsmQWUlgij0iz+15epRCtduHn tVBL1YTTWVC35dXAMK4hWN8KosyMqpRoMnUmzP/Wc8YgOtaXfkVeS8GH1zIV hCqXRLl8tjUYZAY5euVXdG/JMjrTFLHwoEaI125AC5kD50HEOFMsAhJsFWRk 0l27Gqgy7j4ZyHTVKBtwWjMf0QYkJDj3owYWzHkUTf3TqtjLTFsfjmy1OE5w 5nQCy6Zx2Y2fIaGwzNl8FTnmp1OrcCDpRok3EFrWYZ0ox1Acz5wJoHGxxcZF ZUOyh68FiVpwAirxzC1Ca0tq9GGsmCm1sSXcouBOqUq7nXjNSIUR9E7yDMmK Q++R1uA3bcfj7gBsJrOtvyOCTmDVRCHjsIqdPMTqbZVxjtApcKxC4gKsYmIt LPXC32+ZEfSoOycceY5NK1Opd/XIPvHrHHMg+x2a/26dgQunDIg19J4MpBV6 izK3Y9Vf6jkTejVN+LYHYb8dMHO7ZA67GYPEEcmMWocC7TkTdjYE4si3BW8T TOrK5W37g6XVqDkTCLgyf9dC22sEl/VuPNWizjVQGixwospyqLEnbyykYIvp qdEXPLudhlht2jD6tmQ0LdQzBwtehwqUZDlqxcdDjmqdt8XRPkFmjBWWcNDc 4y+UWCc5gKr1owPOHU/pi2u4JdywXEwfgDQdT6IuMRhEl7CZ/oil9snBSB9t ODVpQt8tvOwcmBWq3ioJ/gDDHOCWiJZF8CydwDctILckHGAy9xQOemt2JM6Z kAN6tsPvsFw5IcTO0gtmaLVZq4LeuVFQzRcZzkZtZQ6kXnI7OZpfCcytGGll bg8U2zEqMku4PgqN5wNh85oKcWocPR1cJdq191jsaai3BZ5yL0F5AQGc4hjj bwi3zTIsAWdVvgda11LqZV8IpFmmE3Dr0YQUG3KpD4LjbF3f5iDn4OdSKzow fvXUQLOfAhd00BNXYUSumgWDAH5DQ19C25eKonUmDKsSYFfphh5jgINXljcS R0ay5q32kdKFlnF40HIshRS9YIMRAjiGTP4T1jhfghHbLf9sxr4bmPXVJtXp oMFoB64iqFhqxRHNCVBzF8YYt0t8rhxXNtMAQvINStn0HwDKK9aMgFxneaJj hn0APDHSzU1ulBTl2priusLRbjgN63y9iiOIAfG2AZRZeUlOxSSoDXVRQST0 OM/rp5qNMcXLn0f4dcpSIuDCKzhynTOz9vw9pADPiiqc5FMC0gs5b48OeQtZ L09i6ghYy0i0hasGaymdnQNVecB+NVHeJnoZksqflhNZOxrssGVmfl5YZN35 uJjbPPPJt6N+VrvdUeyq0DZPOi0W67ihQsnm841wHmgNgErh68IQsviRTLBI cr8TowefbZ0lt64J8JY4LXGcaRtpS3zAcPjctBStOOWnstR2FQfoaLF7C+W+ RApLcDhX1ApuAvaheK9nnrhWY5MIroSmFkeLECdVeuyvlfFk0NPOyh8ByVRt xjxMd4ZQEHKOf60Mo0KYulky4rkK4N5uMuHOQAcsQ5OY1vzsUW1aw2nmcaOc NllBq3QKtKKD61kW4Kk5xtoODfw0bLP2nqDcXUkj+KKk6xsQISY16gBuTgdG YaO63miIT4qHKvSjYKmmVpbJ3YLSxsXb2CwiWjg9aPiU4qxaR1ok6a9XPw+e nFprg+8boXKg4HrD6ZZuW686/XnS4sSVurCVjaLM/cWMRdeEDeO2OgcYrxGf JS1yQV+BjG45NlW37BrLLGnC1jJpZwb6WRuoakryVXQLqCiE70YIEnMvGBD1 FloSIHMWoqjopRSYmbDolptW1HoXNvTZ7l2dpLruRVQ9cukLBE0YFvrVpmYj p7F/Rg0lwmaIQqgLO8Ja5Y9SF/XfSDoW6q4R/qBGVYTFjsRmK2jnTZmThBC7 lNW6HvJvDOPZZaT8tS6Arc6XQBwAAOtltN4+MOEoNcdV2rI8EfLQzj9LbMXD pzM6GkMBfbMr1gYOatghRLZmIC0uxMnE6nOor2rHVGhsFeSGhxMq+ytu0l4b 7Ajk9uU422Yb2037ZwLIZyh/a8SnXwcYG2/rJQR6Otw6E+V5Qcua7eVZky0k 4SpxoFZHVN8iy6S1xVxwhCalgKvD2hrd1y4nyqQOdpTZm0P52VbNpwBZNgn1 rRvrJ2GasmFr7i9GitHCbZt5jTVoFjJdDsXyktiot1ps+GW2b2TrEtFLSLuV rMdiLEQqvC+FjAC0K3YBSddGj+knYDi9+C33IPBuWqGOksOQ7BPdZsLdLGJE LQIyraet+1gVSNhMDYRovOJ/3qbmq6psrHCKjmrXT6/CZiarzMqbsHA1XAR9 Nezxq/MdUIkEZfpQjAv1HCFF9NKHEesm8PFBmFVl41fTmR+GOZ2T6xZEH7Cy 0stCHMkhY44lRV9aG0tV3IWMR07z5PMho4AnytFKW51QZfRsLtR0q4+sSwDa ABYrGOcgTFJ7WHjgFy572QBLN+K/OwiF3xvBel6YMUKYLdtVahifIcZx00Wp gPp2JSOdHUDTjkZZClNJbdhODs+UB5Zjpxzci4kxE6dbEq4zZClYxnnigmZ7 c8TIkOY6jDp2CbtOFCNeCGdsoN12WTE1QnE1WD8GyfbDopPb0wrPR94RrZjc 1nmdz5rhYuFQ52LPRcXFoItDFoouui6+L38XYRf0xdnF38XhojOINsh2+fTR OLjPhaCL5SHvONQbXv9r2+1+p/Ztfffv7XY7r2vp9rrB/z9T7o8/sP0Z7/zB xavzS9JXU9fx0HOJ89JsA+3kkWTsz7ouPGPr6+DlajzPnjzWvrzcbSWHsc7X bqepPp8zXD90HIyaM9RKx1fEIucQjd7aBGXPIs3pOeTz9z0r0XBoJiLkxDkZ Gfl+NVAFjM5vjnqmKp+0AX+0CFd+dCV8z3x8w9168c/s+RVvpjyesjx79+Nf Gey575ib4cXpq7jNza7oK6pHL7pzPeaGBP7/lseqr4JHjhO8r/AgzveZqNyM jscmM95Vf1/E5+5rtD3kIfJxw+mii0cVv3mY3qXEWG7Nwv9Oc8pP46Q9D63l 64apggR0LGuRSM7GPs45xxwiqlGp99fzwX/+CFn65kpF5+dB6PvCPGwwwVyA MbvAT577UoK/0sV4hwbxB8qhFtUPT36DqsBPx8tBBrY3novY+mQe8Q5n06DU Idh6hB3nMJoMb/7b08fuD7PBRZ3iO77dFlTsOJQcV8XnoM8hViv4EJ+r3Y5n cw4r7iVDOZRx5Xjur0Vf5Fcjj5+gedp9DknC6SLQp86fj0Fwh2mnQbdD3mpE Rn443yPSCJHhY25i1cU3kqjG524QWKHmZ6DmkNC8EUevjfF/F98f99f5H3/5 v3h/foOV+/Tbb/cdINlzCTYEmvk/XqUcbkPuzYG78njz6zcxH8djVOOrkc+A EEnA6BTMVc8qWpeYRzDhy57tbRLcejBkreDBoAudc3uSdlQHHn6KHxk+dxF0 ycfOrjftRd3F7hJAfWxvX0kHxEPQYSeDG/b1iDvUP8uuQbJD4GIg2iHpcZB1 SHNJIZ4eNoERDzZER83GgRJ0WS9WRFO45cSK9BUdMRF3iqE+/FLf7333/3vv 7AvxkxyEoBOPr7BIXzYGAz0qMC+PjgI+lk3RluJkfsgVf6zv9mEW5CI1ABdz XqBLh6dPnq4v5Iuwi7KL50X1Yu4i+5F+WLw4ttFt4s8kvnRRuoi1UWrixYvV Rc1F7aL3EXvYuui+PF2sX+ZGLd/G+DFP/5INYh03qk0ONnxdr6tB9ZDw/NIM 6h0UX+/4v8v+/+W6I8XyfxfA/F/0+BGxnTOFX/ZSxBgkF5RfOFDCjhWw/S6f DfkUeWxxS4it+R2bxi7g0Eh5axYPPoNknz2XRoPc9JF8lD7z4CDYdlF8r4MX quzi+Oh63/sg0naxdT9KL5Zw3z4J/Z1tW+mP5rikFhpq6qHP5zmmrstnWJJ3 j2XPaavMeSk+ecXcxsgf8xxiMMFein3NyRz+VwyPX5s9Hk+QYPwxx6AgYU9h 63c8znxv5r0RG/Ji7f16D8qHnfYJ5+xvYdGIi/ixuvjegjehi6KIBKdZG+H+ Huvq/F7r8P834UHdfwev5O39fu9ks14ZN/6SuI+GXKP3sarya2dP/7GO+sUW KqfHsf5/cov9l9EHBxQXZ+Onz9CL7fs0HeoeZ9qg9wh/l9ug2SH6fUIPBQ6b 99BNQ7X+BBX9UniRsHv0HxP6Iu1Q/WTd++r+AJC38lR5bshIb7P4IkOfn7/u dy/UyX40UZ/XG/yd/1PO9/jd/BLeP/uousvhHYJU7/09WGs6d/Mtw5RGftbv jLiL39GFBoaroTnVy81cqHUCuMSqizWGY62bJfDE0U/KFvZm3lKQueoVvtyL wSgJBm4dg0LL21jXHmCltyj1xbXbJmSaA71LkbVWoi1CcNb4cY82qrq3ACMV 5AF03jhbSq9GsTd4ZFF5TZdXQe0c1flY3CytfPGYlxMrhUQkXUrHnLGhtPhp Ps1tyTQM5nIsZbVlOb5ebqTB0G2CWhZe3eeLY4S9A+U1nZrAwPqerI+xvJDs CXaDIjwZDuV/C9Ibdis1Ki9E8vpdWLakc3X9iNhBO/YLSUhrpzcLlBlVmaHR MBJTaQXpYLgtesTpMXrNXohxc3bGT40WIKRsHcaH+V6eIOivBZ75L5lz8OcC AC9GD/40ktroXtsWrxpy7qbnej9LDn39u25ekKmUoQFiiYzU3GXssDT6vVuL y78rJKwGaU2Obb7DqX0hl03EN/lAnzIgnPbIkX9LuoTUz2uGO02lSl6pixQj QdE4z6jSh3M2PArfU4mWG5tjVjpkY3zH9WWxn+0WagdMg5CBm7ilMspT4hOQ diOai2Wa+4ttkiVg7g0/WRRJ+ElUBVMk32UBnlNt4t5zJYBZSZdDAFTs1SZe expADxQbaBMWsa2eqxvZK8YSIzfrlGE5JciCNZRj7MYkTHX4TSJxpbX42TgQ y2wWhNbtlwFqsDVNBWmL2FxlWEFVMiqGawihpWrtXXsM+WqsDX1ieBFwGuSz dYJ5kS2xtjSTAY+ib9hZBOFQmz1cn2SbOa2iyYNo1cGEdBQeFtwzGLWYvmUl u4LALqlQz1VeivhgQlZaE8YxJlpKQSJKLLGOZsRa+hvV7yke2s041S5R9FXQ 7SkD2yddy0kpjQ8JtPsBsiZpDSZlb8txeXrumO0lTsDJgSTVxDGsnljpLnQr OJslIchN+GxblrBCC3s5CUShMaghOfU0AIEycm4wa9e4vHIhcEoItx12R9ng 0ISeFFjAyH1yxBKcm08WIGI4XJFLUFx/g080SPWPk1UIYNw3CJgmkF2hugJn B3hsASZRuCVhLF8Upg2NNlLwYvB2zRZNZjaxLMdRGJCp45XDh8RneXklmMNm hcGzKqZPUtErIjDs26GHNkfFJFrOBCI6zHZ8Q05x6BTpTp2IxPbvK7pDBrVQ SeFMliWDNFCqhjjmEBLRZ4zbCTkekMgjBaMicuVBAhstN3PZg85tOBUIfTS4 qmbXrFCcmVjAuWeGwC7zrD1NSy3HGjKqEt2IxEZVJUW2Lw0yhH0ELlBiNy/X u/diEgZv1737nGrhm7lJTcJGlMSatILTkEwrMfNSQOMzc03PAco1wVzl0Uo/ jciGRpJT0gdJNIDhtozJFzm47qUM6WMMJw8Ce9dq6YbrPbHAmC2qtOq9QYhm dhS7unwcnovvSOLNB544/xpNCSICTaQHRHdejN3CN45zfubJGsBg9W80tUgZ MqkcMmmtfQrcg6nV5atPbpDkkNyJOJLzML5sHUagIfHTnCPhzaZbfQnaSd9C 7MY88EXk6tYfE6ai2jc5uTt07ZT5quhbLxOOJj03CmFvCSEs3HSAAsiSYCFC izC1bJ9KrO+xUZ9cixIEKea8PBubHGAaP7MV7KOsm7QbJwDMcLjIcanN3GAb Yvk1ss05VSSCi50gnOSp4AGwGKyIAQq9qING+/jxb5BNuF3XHfZMjdKQjzVE 460ZzCfRVW3wOu4ZEwZT412oui0cpppzanhsaRDN0xJdQW9ScchfqA7EcESK yt2obspIUlzzgvObo3ObJbFYrAZVUl+AUJUrVu5xITqBstKeRm6/IHGORV8B FPtFkgMz1Ljy7iktGGoSG0jWSF0pLMyQ5+ZUK3JSfpaQD6bJhk8Nu2e/Flry yZSXVOqgeeiDJf8Cj+u1wpMZwElFsQkq2uWdvXNCFasRJqjGhfOfLGbdFwic Cd0yigP3WtlOHhEQmx+6NXJ1uq4d6WMdUlxRMhNDLh7kP3smyYgmOCUvfxjj TDoLJmai2q6ZYpcqRTapSl1cGJEhmjQQWx6xNCIRPN6gTM18xkG4FJ14239p 8ou6jyzSsKPnULEg7g9VN6FSRzjPEGrSq9AiApXp0lXFZGq4QmkSGIZAw4fe ySmko8YjSWEyrePVNSqlNGCTxboocjgGSXoW4T2V5Q5dttOxcmAAv4Vqi2PJ lRzOf3GlzkGpkXUJ65ilwomCcaFcGkTmSm0vxkxxbHlpSOVq3NWWpaNVnhFJ lh8x6hgjxQt2cSpbDFaSq2ryo4RZMC6cZOkUIpXzd5pORYyAcalbzSpC5NVp S3oCHLC3nUNQ0kgI5+/wHm5mrN2wrRUFKvEflciYShV5l0gISnB1EHOhsyvl IOhSIXplJUOUT+vUJ+vdPtINgr4XoKiWkwf0Je/NkjX1EguKYQS0jWCuCm16 P00tsDSFeNIH4TCHoIbVtRcraF61SajajvRO/JCiPLLfF4ODgIlVb6yt9PXI lnjysdah/CgqKHQo4AvE0LDSIhnCsSCswSz9HZdqznkSs2LSmCWAbc9ygYir o3ZGJubN3CE7EMp8LTgZJ0EHQkJnU7+A7z6NGWeIF5A88Ip0jTC6KHj0fnTJ DnqCPOCnMiFEcGH8Q5zhQZPQzLEmRTqyL0HG5f00LzqqZuG8tBGrbeN4Lzmb m2YbXmuldK9aVbTDL6pZqGsLgTpV5yzXlEKc8nnCI6Wkv09NBkUB4LAelN6P IekNIzf0dweWf5abIcpZUsf1V5p9TZlkdJzrFpKTRswvWJr1ArS4qchZALbD KzWJSIKh+etqcFGFmxt2MeXZUyXYA6U2xcUga8c2m7NACwr6mOebmimAs/pk 3mAgHMCjoygpCuZt87EhvmxLAUsWLxhMDqTnUJUI1QiheMTnObTzlpHlyJC3 L1WrNvjDwnaayKIGTEjxn4M+LYGJmKOpjGh5aF4L3rQr7JYtAVLaKUHWR29Q KpFMIsC2Qr64ZrQ2S0YZF569YPtkUXj4YtylQDt/qLZg2jTKRHBNaeLVQO9Q tIEOUBbsUqmQ60l8ZKmNC5McBU16cRsP4GYrQ6fO2dY8y1zCcYAxKHLyFrki cigFgoVewQj3kSomqGLU3r44R1BZ+sM+tGTKGAiZunLKczofvKjmk4Hiku+w CxQuGIUWRhby0HtUnY7FR6bNhxSquhpITkW2jWRnaO7ICPnGMh8bLzDHP5Fb HvGJ0p1UNUXrOpVwjofSZXkDUchQOk+vrFEAq9Lx6oYxPXEFvBPHb2G5Zp9v eyj49k0dyyV9G6jbZX5D97od3/tlAu9B1uXtDZEuGxPqGlDpjBdbI+2Ffp9C PYpRLewSiatIFSzVANpdNZRbJrNjBb7RXXSJTvSuvdOtZNxUHMRe3bXMZhYK nY6rlWgx8xcOLFbcp82xEjYT17Wwf8k5FOEkKMWDXQY0GICUVludMm+3oF9S n29KnzzsaHw+ySGs6DBg51P62qfp9rBZp5VdBnsscdn17TO7QWKINw22DJC4 0Wuu6dcJLu/IarvA9Ds5vXL1qt+xC6qbXVE2aGPUNXn0yRimJEa73Z0lRk6Y MmmjYwMl9EtGWlWjrci51qWQ1PGU7uESYUSHuWSHntU3e59NwumT+S2wxNLA 1W5as8vZft45oXwoy1b0eD6ZSOYmTV1EubGXMHESBz29JD6XUt1DXqJLyc5S JpBo4V28W3inaI+f+ZB0VrLFd55cti14RXhFIu55tZwN2Cgq6ROB7kk/726J b2326ikNiiuTPklYGZ6QU9y6sE92/aJyz3PxufgcmMKsly6ZlYkzcBU4TMWN eh4c2P+1xaJjSGpTQNsZMuPxQOTgq+e+bM+K7lWa3RIQF2S2mK4EdXr1UDRw u40iWMZinSTuG06WgnISA1qTMiMBtnA/nuMgkidLyIOKPJRSJmhZN7YIOIbT +X7KhpFasiLgSlxkqakgI9NaEOkSU8zVdcu/6ROtx/U2HRxlG6jjOyGqmNob 9dju375KTAjYiceMiRFbzbqR+r1Z66Do0++1T0vOb/Vi7zM+op8vTt8SSfQE JxSB137rh/pd3eoq1YS/Ez8pmzAlEZPJnBcTirRSCQecg1EVI89JvqWZvDG2 NROxtbYk0siJWiYVgpSjSrHMmZOOhJSjF3+v4CsJz0HTsFZ0agZ59DLhTlPK z9Zi5q6RJW37cZSa4AGx5Ggo0EIk7S2/AlNNMS7SkaVrYTm7ZVOtLL6qIKmZ +xpekuSNB/daXoXo9lDEj4coq+Oh4uSpZpM65dVbClaUydDlB4jGpuvH4cBG gtJ0afo9Mbw0MhLH0zsEAyPRKRKZEhvah1EtG0LSAl4LZQ2jWQ1e7Q8cLKl/ w9D6DeaIyC3vhavE7mdgBxmQErbY6Y1vmDZebZwXVHxW6iM3ljMIXQS3U892 BHLqQ3YJDWKLCoq/PKwS6fcxinmbT0pmJhfWrWQ6UtYyBRjlIxhNsHLlXY2u WqrOrUa14ZjOVckZqAUlHwWAxUrmOLLImFiSlyossUpzPlnmjoGJDLm0ZtWC 3WDBlzll2XjdzWiRQOixvXdzDLSiiXulJEDS07tpDHay1tDHZQSkpMX9Z5Oh 5U7XMlIwmPms3eUw+2sol6OHmrgtnBrSRblRJEATa0W2kxgMJYj5dXWZ4/YZ H6cnrbMd2BFKiDlSDFU3kZE+1aSgPGiik0qYxQKO0cIsSYyanHYFYasYrZpE bLZwS+hDXd2ezWFzyJcKanOK1iaipTNG4JTL04/p55z6AYoJyBxAFs7vRGLV M0xWbnXK2nE0yWUlRXIkGkZlJFLLqnV5Khyzo2dFbqqq5/paSIvJO9hh14bQ 7LzKm3pU4IybYA48tANW1OClZCNAmNd9FW3PQWxUmrizzq/CEi8Rrxs4Sb/L wVluS20lZa1GbkZtlPlRt5jv7wkOKZTWfL0gl6rE1uitKJp0iZv4nd21O1jr 3dbcuu/0BZObZPN0ZLaxGyATSOSqPS6vU5HIh1QjBI2FtAkNcM0h7XVw9VpE EP5JxtvLr8d/9qZcuDDTd3O2+r4FGJAEAvbr0FRbWZ3LSdKtGFOjhwfHwSPX 18FmwbGS+4v1tF8dV6nti8QpzDgsi6IwiafY0p8nE6DCyhen3HQrCI1ZBpSM LtiyPwmG4JJog4it43FK3Nt70yEKHyEOEz/WsHDS7z0S54s6G+fLyQieejKb ZQOOGBWwdy9SY9K9Ck2Pty9CoFuie2/hE1VSNvxZuCRtytubrMzrZfUVVMmU ydJjESbjSVxCIukbxRaT26LF0woBxr+s5VTcmjDezNZRuLYxtRtnVWGcVr3Z ZtyTCeM8RTirbyVrIvLnZWUNiozKLeM44YZabYhme4TbIFfCx2F578NtHLaP WrT5hanbfR+OoDCd1cx3e5Bdjo13IOigsmuAFUgAFdm3dLvX4bVfZuvOQ8lL WeM4IL4kAeDVWsdhKFrPJFcK55dyu3OilKQAlzm0FxbN2Vvo1aOajCztHWKd 82+S7sLXuqauJNYmLZBAbpiQ8heAQIpqo0wJKnOkTmYG+y1gv9Ybnl0SidNI MhAJer2qgOrXSUoLqFw+gILsws+tTE6iHtr1mnac3XhEybHfvqk0LVNM4u01 a0Y6qNUsmygcGGPrYnujL6LZuDZ1jB59B50j5zm8PqtN0JTCtdKQfyA1OHUz M9HO/S6joT5Qs3sGxytx8GgJ1k6Pgp7Qn1Nr21O1MRJm7zDb4vL0ocyrslM+ V+PdJZwwV6AbLsCeZEQFhag8H4NuemC+1yzgxEi/dHNuGDnpWcZRtcKrrmsu uXDg3Ibm7VOvepTGmqzQJuCHk0Td8rmkyZQ6Qn4Ux43l/a9u8jSyB3CAWG7M BS3SkwuGLPBTm+cby5W9cRWrwVjVVturhOPmDrpxOQafdzcmyc1j+XK2iwZ6 flNDBTAUWhCWMKXt6/qmr7lJrJt12TvzrDkBSNRyMgDLHfhFFasOOrLuYTre 5escA8KxxwbdFgCMuqlSnIuuDWI7jpeO774pyLoHKEegRhTAjagQckN+HR4W TM8FUEzLyVXbKef1BPidyBZujJCBkyrQ0RJbw91UEtsU83DpjFNlNxphZTj0 TkrRDjr+k5obm5Ilh5LqvCnhMFh2a2eraQOpcBKDsnjA2SlcNuykKQ1BnVJA Mqeji0Jl9K7N2aMo+QoW2tnVe8zbBD0M5LVOHturpG3IC24o5A85dqLxnLzj H04bdIlfPERtVM5bb3A6aU24RRW03UPanyJbDtJzFML2/GD/mjoFUaHDq+MY AKn46CtkMGe0HrqshIJ2+b0qPjqgsuVA5B+DqqSW9xbuQX40DgHE5AB6Ue74 pNe3br/okS4nWzu5jtKvfdeGuQ0d9J3mZlmvzaZlNbCgamQu5c5TZowSTNt0 Bc4h96mDfm03N0DihSVZslM7XIZv228hspVjTryXb3TdOoyezLJ3dzGLo1NW JTc+F1KGKfu3YnbY5oA+djUclJwWzGD8AYBMfiXxeltoE0iW4J1X7XHap+Uy JpsqE7fnmTo7TJDYPM3c4NgHw2kbUD1rD9nSeAoQ/XlrbErNrrjduW3H6Exo 6FCSb04xnV76qbomE7mUf5z+BDkNXTn2aiBxx0xLeIUIPSkHUNypB0FcyFnZ ZdU2k5+gqOLkTaL+Om8oOPb3wkNJUc/k6jSPXs6WSA5thc+pI3zrzBlO3yMp PuQnbnLMBCe+4KT1eZPNN5ifMhQGsgZVJN3Gh4QBvG7JhX7h6I69spFpghVO VnOImpyZUD0jpjRJs3EnOnm0gyDSXV4JkOsvTCxsmHDLUtqAu6uiZIcTBwvS cy2+dGDp184V8W9fxQs3eMMZFZcACjSjeuCRNXpfuyCVBJKZIOBYJaqBxukM gUBT3evSNDnkUZjvwdk1KJI7YrpSA6F4TU358Qs39ncS7xJHMQlyY2P/ImwB rTvCM5qa+HK6Xopn5yJZyty6nttpFOAbDGILpenFAGMqnKdL41VbhuHQGPUc frq8iYTpJzrkIYwE2r251eQyhinpERyrPwkQE+TovKrAmsp2VtrEPvpE5unQ YNFN400zHH68dDUp20YCqQyZpz9KPnXTjwrVdw2WUw9KItP1CHqAvrlqF1c6 jTk0aPa0l4WploXRk0MpTnpEL5XaKLIiFXm/+xClT0GUZVCllmi7Zo6OdR7M Uh1ahS06xK7kEy6Lia726BkTMXS3ciEa9t3ZYYy6xw4/cmm/T3e0y6qmDVTu n6Irc4+4TDgmKbpk7Im/fLmXGkxDJRVjRHn2LPy/P47SPv6YUYDdWTOMckvM ApkiRHjE/MQNMnGFqztGZjrldgpuUTTFuqYA6ewWr0AcLqqUlnVhOvvocNJs q/WHpYpZ2rLqo4Z5R3R1KQzCzDyyuC7O4uriYm2qmqIUYvMnd+Awl1ZLKVLw lagbTeEf1pZYdKt83EyCGmOiJ1yUJgUqXyS7N123WaizZaN6ZdBqyFMKQtvc rtowyREs+qZfkqkaFF+WF5nYnTL2wOWqR5kJTOb2LclKs47JB6cIaPjJXflk XmguljdjWkQoXdJXPP9mCh54/FAqx08IerlVA1eV2UV1rXCG5zmhLls7PAqY Ic88FUG7jfsN9qHMYuc42Qa5vWici+yTDRNX1vFy3d8sgVxkYFv049FKUKLn bFSUZQzO2b4fvdHrPQsmkC7pS6uYOH75bfR4VSYoTPL1Uq0869LURGYcTtDv 4byTCA2qMiKHVLm40HIIk2aPAcjSu7bEOy8FLhn6yU0Jti11IslXt1sJpO6M 2HTJzLD5oeMdsPj6RMTiFnRNIwkQ2ufA1kg+mMdGqqdj3bRVehKqt9cRWhJl bpLE3VIbjXnLqtsUCYLHVFFbKd4fJRgFfrEvodHe2RXr1Ln+ORQfSqRzKOyl puGdgrpErfFQZEUIftVBKQVZjOx7EzsZeVAHNnLI/3/z2HwJQ/oIAAIiOl4D NIMB2E6QXhLs26fUgrayidAuucLZIpicfu4AArYW3querUIayzyGn5fhOLVQ St6pELtSIXZrOsEvCEBPa5VLxhThbNsate2u+vUGmoO99b9+EBBu81Q7EStu 9keTzaOcvra1F9hRT9w2W4U+KQXiuyyOCuVR5kuIqeUx9ZVpfAzZZCdgH2BO egyxuHdyWGB8/sbvqa5R+jhQphjjl+zlEJSIT7q9hCNLQEOFZUOsYUOV3HTo ysJd5ZT7l5n1JmKQ3ErJO6qk5vOyJ3RNP5MT6GiSWtLoyskuobY2kcPmwGkX Qx6Iqlv+e7MUr++so4gRt2iOIUzUyxMTTFzblGiD0cGGSdamvsusmpeY+6V3 6wHYl/LotlKtOgRkmguKWknkIhwriZoJNlVkw3a4MpkGy3ex0cOtWQ1DSiCE HXIy5Z21ILtrRVUIQmB0iXeRQNW6kOt8LZmVD7zO3H5qlEzu769NEKkZfyle elR3mSSFatmMlJ+J37UFyXsN2f6dWXmr95k6BsU2Tebqm8AlakmG7PbLvwBa qgsMOFZOuvayb2C3DjYJqyth4JhEbDP2oBnw611jPriT2ZQWLcbtHUqGXp6i g03bg6ODoYOeB86emg6aDpU/rzkGxNCiqTNNzlsO3PK5UiZzzzP7cgb0mGYq LQF/a93UgKCg1qJ2UdzQTNEhknjF5Up9BW1LA5Jx8NVgGOoP2waFUmwnNKi5 D7QDhXjQyFoZxsggRzrYXVRcGUhWr1ks1UatI9hnYpigY5xZuS9U6/qq5fPW efDB9bbKRr+aNDAMHZOkczcI6R2chnsEQbtlyzuT0Z7fYLOIaNIBOCalMN3Z LkQM0Ta+ZL7RanC1FCKoBxwwx+WtwGmp+sVy14xTc2ctnfSVUlKS8/2AAoGV ccMiv1Mx1rplrkSFih3DqahwrEsQ3dfMATZ3aAaiCeaubqkm2qF6sYpq6N08 kiZ4ZpeM0maVlvwvrehSatqthu5lxts2L6g4DH1iIq81mVlCR0UmpLOB8z5U NzMj7oRoXBaKxaNKXHyztrOkd/Kn13Rj7qv2EYMZXcwxBtN64I+1uirU+3qa taniDtns3czKqNd0cyhjf8biCUECiqcMejjcCp5iRr1mixZ31iUy/KLu0Ul6 r7CIgAegAjWMA7URJX7EgS0jOWx7l4bjS88PiOC5tqxHYsoNtvG7usWyk7l4 4uqSj5YlylWiJNL+m2UP5xs/sLL/fB5ugnGluybaqZu9FJRCk3Wvm81ZI51C +D5ZW8y0NJdvWGha5/ARj5Lk1wxdgkg3CprpRqY2hlf1abAU9w6PNqcJ1Z+c 7OONyHWTQdE24oGvGlvmyPnTbI1Uz6KUN/Ka/RT95apTl1Fmy/1YgHaREeOp dgFJ6AXeGbvLBW8y/oJ8+RF8X4qDs0Or7NW+8+ejfiDvvbeIjM9Ueq+ZBB7v /sg94h6+LQ9qrfgenjdRFqovH/28fvNy/Z+T3nwP4fge0+B3kXP8xhQZV4kS BWr0W29vkSZEJ8IiUZ2Mp9dcikvvLnhkW9jVuHJ3nDWt5mftrfAmkla5zY2/ vQSsirDfZngutfp88z81B06H3EXvIuti1/z0HPIdhF0sXtovBig+gghQ8PFn Yusi+JF8eLtYvoRcz9JPGjfdxYP04IMaLv9mg8JD5EW3izH1UGgQ6SLpYvbR dVF4nffa2fy/gSfx73cvfVD5ffdL32z554T/VoR6qb8naZFzTZbvhwGNRoxp e87LAvfuZckXey3vjLTdT9IbiAHnTdsg1/2oz6H+EXfp8/CT0vxI34sXyovC i8SLQ9z+1pJzx8ZFnZRe+q3s/5osqaiSj6sNNXrkGu5zdtckuoM02Qc8s+WR JqoJN+e1sEdCRIPfo/2skHdlMk/uGDDbuE+fxxeFF5kWe/8INIh00U2LVxay LmovF+/9T7/9XW9J6jrZ+kDCv3PQ/nQh+crkHV1SG8355Ox1vCQjy/aJ/WX6 atb/30OT4uw4VCH5j1dTJ6Oqc+P2pIWvJv1sy+pQhLhEcU1LmwvTzqfPWfWQ dah97F86L7cX3Yu7i72Lvou/i2sW2i3EUH10EKH2KSG+ljfI8D7uz+V/T7v+ n5Xstn6zE9Zs/u+BgwZV4lyh1mg7P2P1UOw9V3UEzX8QFfFX/AIlQhdDV+DB bV+6LD2PyU4bZjM1x+GsHFFr/6fMrLI2kHpM+r75ThF1I8e1des6zxB4cGir X28hvnAte8oqnLJeeWb5aFY5i4JuPGd6XthL79ynz18XZxfJi2sXlRcX9lBo EOc7dBpEPWRdbF3cXeRQ/3oMwh00Wni6eLqYu1i+dF3kXexaFJleijaUWri1 kQGacvG2MbZxvRRdJFsoviRfFiA0Twfw/b2fyNy9hUPwl6n/P4et6cv0gyx4 yyFNZPfaI/1tu/ZXr06JvDpjpl2Q9mVSM1l8GrZ6+dXJbZhPWoALvrJ897F4 MXXvH8gZPvdVHwYtpFAk/yGNzEWaizkWei0EWhi0UVnFpop8V5FQi5eLyv80 H6Pv9x9TuPmdx78P9++hT6/Mjdj3Hp+4grfiWTVa1FzWsleHtoUZbZmHtWlc 4OP+J/jm2ON+pXc1STAf7QkXXl3Iog46VuyF1venD/fcH9h/44Hy0jxpEvbi I91cP7kyuKj/PpQr+v0WEvJd/9ZAn6fI4fmuIl68y78abI6zikS4Uav8fPHO +7RRaOKrWxpDcKU/UACg4IL6c0nz9j8CDWd5Fy6Hp4tZ3qDlvxxf5+FFw+2i 5vbxdkh8OLTecg6/cRfbTQudrkHD8NGfiQ/ji2sXkmtB32foRYeVZnkx/y// qOjV63zwY8f7D8cRGZrTwZvWVzBv84NlmHEHBqyZmZM9pU/8l+RngLJ1n3xv 3zKHoE+dhF1MWD3oiD5T8SfvqOs/9IOWQ4yRF8vG9DF0kX3fCESfleGgzCb7 ztvEQbeo9X4qaIk4r4XkRnxKj4O1QcP/xFPQ9PFmPKQeN+bufn9z+b4Yf7+P 4bfX96o+vqMG/fiWzeuEx9fwUHK5KR89dVKymMc49ZFVoknj3Hdk9fHAKd7f 0vnfhUNahn/ShcHRJ85rbDjnzO3HHTsCx28EsebFCGPfXIQx8tUPbp8/aiAg P8sbpklz9QjfUxfMi+tFzVdXKIR6mN6uLccEgz2Yi1nBxa9D9DNoO3Q91wqD u0Oa4YSJuujevi7uLw+97n6PcoC/3xI33ve9TG7r6CNH4Y44Cuxcot9Yjb0l UokmTi95eF1aSknJj0n1mVSv5yyLWWrzNo5gcJqO7ItzwEPkEW9tfy7XwIPR 94R/kzA3yBLr1/BIyy4pYE6CK267YV2l7Xq7Wx7X7VGy7X42Ys+15aw4/rui h0yfPIJXD3Gdr29foI3heuQQej7wj67pnE59WXtoK7YV07vOC3VYflsePT7d 03nqM3WE4nGJMcg1XeWG8SPPtNCdSnxmpVN72Ubq4Fr89cO5VHhWG1rv4tNQ gynxxEEPjcon1zsGa8bMxVwJ/k9HbwZvxvPOM91XfB+D8OD69dnEp9MhNX3m U/TZ+OiP57DSZL7+w3sqVWed89qE/7eD8aEaffVfsGrK9HY1yHL11ZeZOMfp MmTV7t/KBP1+ZjjERumOkvLF9Hpnli/Ehdk/yVcv9U8d1/j4fUeX/b93ife9 XB8mDE/szYWTxirr5UMqjw/ozwHudNQ7+bZP/fjD+pIS7/XntoTx/PHdsEbe Rw6fWur7D0Bo3dVh7ziQqfPPXdPnp551CvT8IVfS81hlTzYIlYIw5YzQf/85 IFgjsa9HtYUa/X2FcysI+Fghg9H3iKKKKKKKJH0meg4lKREEw3EAjuyaUozB 8fIr0+vCx14Nv8LsJbliv5tt0CdTfm5/W62uh5xPrsdbxsPtI3pooJHjem0c HyMj4YUpf8zns+f+MOlNpdrQbGurW6XFbr7mKpHqYPYYPk5Hz4PUmoPEGq8p 7ks7cajy9FBxnlNyB/6Ef04JemX30B83G2qcteNrkdsn1gZT2aGYIRNvpUQI ByB8T4PT838SDx4J6gTUrj4micUMmysEG8JiQ3pcrhA18/CwF2NBzXN72avr sY3PcM8GCpFQJ37LqQ/nM+849o4eEMrz5UhP85fegvBp96vCH87gl/NQ/ZpN b+Gbu4ZPnXxYsXJxcvF0kXi5xB7riYvgobHjUHqNDF1KGhxyD7CGx5BBpkM2 L/vF/dF7vToOvQ3HIpr2N8WLaRfC1CDjMl2SQnvuqj923QYFxF6dDyWAn542 lgoOxwovrobbXIP3kOp5NB7HHi+Qh0/LIPfcvFrPTxeqQ7PmEH/hD9aL7MXg Rfji8uLzIvOi3EWZ9Sm1I3josXmUH/VD7+Lsw/f1iD+fnYz8HPxe02Kpox/2 xv+0W4i+j0iDlfZxaPpYvJ9vF6tISesjdhFyfUV0xYY10dB8dVXK+vOIsX9u yruxTacC+e6pXH9WnRqFi5y6+LquBPrrfTf2QR3R/nEe4/Po7OvR9TYowcKj F6Ob9x+H/cgiGxg7GO9wEM7KB81NCu4DwUrdg9hU5wM9kd/lMmcf8/qUZYEe x6RGXm+BOXsI9KusavSY+54FtyPN06NAPHo+SIo7HHRvr0W/k4OpKWRsxlfH EdMmdSquXXwIwZMs4jLHhq/TbKOUMeWGZU8+jBYoyuXRr6mWp8zYowSRSRse /MZOWp5+JHc2PAZOmZgRkzNYxbzMFTLnOA8FM1wJYMuol/KydCYjq/t3po/K 8mjG6qAx36zy4I8GZglPHjFx9zCuy8aewiiewCyZ8M9Z0ioAcS/HkvSFLwjS 7JEuiZLcpS2K+7FqTUYFf0zAnsv/GGh1yuybsH8I/03mmfiX8UCnJz/Gh64X vfH8o9mTk9jUUz9TS+VNCLlOCl0hZBGtQ//kX8kX/Vv9OuU435vKIP9E+f0R J7Gw9BG+3i7X0ybJjc743efl8X8Xie+/0/Pu7uK6uV/89O2n93ifZ2n4dp9L aeR5P/r9OJ5ffbT+Lx/F8j/Dx9ntPW+Pxnka/b8R5Xi7Xydt2f6frePr9t7/ x+28raeP9Hbdx+n1v/Fv5XGeN6vbbfyfqeb03j/FyP7fH+Rkdr+nceXuNt7f I+fkeH5fh+b4WR97xur8PjfKtvM7HbW22+b3PKeZ5v6fO3GRuO38rotvm/K7 /y/aeZyG19f5P9e07Tyfk+T+Paf57X5flfW2mj8zw+cg/Wfjg4Ef5OBHFPnF +HBHi0O11308jwua/JtPFnfg+x+TzvL871xfR8tbJPj/Wx733XyPufxp/+R5 sG4T8HmCyV+24fhXw5MeUr992PP3y1e/zsgeyz+5GQrgj+fLWycj+o/sHACg 7zIerGULUje1/pT+fNjkngK+WCt/1Fffo+8I08jI/1g+6n0/3SGEEsFPiVxE Dxn4I/jPywI7PRbTXfT21puOpyOq2+Z83vvx/J83kPI2PIe5yMjy+E6rwvvb Hsv9/FyPN9b5ux8ncf6/1+R93y+J8v7vmdt5fYeX4nmfB2/2PO0Xm8PtvUeb +nuf8PN7vOe48n9/b/a2+v8zrPM1uR3O26zzur/i/8+d8fzOayP5dvg8tmdv 23nV1z8zprbb/A87+//j/Dw/9/E+n/xvR/jbbZbfkPPHb+82/s/M/B5u1831 fnnkYu36Tb/46zI/o/N0G+A+jttV5v49x6zzON2+n8363neLzkH6/8SCf9Ti vFg72d5rhx93N72Cp9sBG8ARfMc8giR9T+VfoknfAJPnID5/OMS/nnETfgk7 +JO+bhXzq+XcDRwfQHD87cDQN6bty57JmJR+FT5V8e4Hp+gyHP9+3yd/2nMI NrzAqcfBwQp875WvqNglBb7CDYxV0H08/sPUeV9TnedyOIf/woo5T+pf+4jQ J8+77qv4n3fYbjP/a4LeH3azHNJ9/NxJfA/4+v3meVT56PUJo8/S8ZVHvqoE YdlwSK7tRu6I92YQ5hE+jgR+HSZlFahG1CPdwaHg0T+RlFS4ObjrkkbkkfTz nDorUI2oR9PwM4itQjahH0+14pFahG1CPp9VxaK1CNqEfT5TjUVqEbUI8oDP +OxX9Z39XF+4+u6fj672TO139V1enM37goBzJczG/mD5S9/I9BvXkwUwl/IJ YJ/e56H88hcX1a4vOm5Bq3fuWVsedgWO8B1Nemr9+FXN9cyH7ppPv69Xx16G vRtX17v1+/Q5GDwydE/Xj8xArz4HC4tcGc/wfuHhfrXrgkfK8jBKCDoaCmEx zY1OD14VFOLi6qL37Qnvec9PB0UHsk+ejg9vB0SvlPlOND+g6fsjIf/cOJh8 X11d9xNj7mLDgoeCr7CH+HqYAz/eqXQyo8wcuoj3n4PaJ+7GT6+3GW0mxCWa m5JyaGm888Fuiu4PMV/BLNxOoKqsD00HUJ5POhF26oW+nV1ubzENeHiPHRg6 VPXc4rk09YiLDiOD31thHJ12Dv6kUpqq3eV9cmnz6YZaUJjJj01RumdWm37h VQbFFtSnqAlqBzyubzgVGIKwptDeYsKjVOspIck9kmN4E890yai9mErmdyYE 5VA4Ow4TfdcFvSKtbAV77VVtBUCw5jL3MKDOB7xHz5gJVx+vg54vX0O9yWac J/9nmes0EHjJdzuwV077VDofteInzUiwgTol4g23E1DougDFeb5WI8WGc76R 8vfF0+/471Lxj9fvo+8I9P42Y6KH6EG5fde6m3AXnnjQcWfGodT04+cn9TRn 7XW//PiQunmYKz41sctT42RxCSX7TpevyQqLf3+Cq+QLH3IyM6zpbFmE8rQq L9ZXxnBUj9JT7UTvwI/0CSJ4gf8BwfA/6f1eR5ePsM52nvvQF9LyPz/9JiHm a6CDiS+/ritjsFdduT4pGP92uShgr9Uum7giv67sifgyZuEJUv/Olnbxmqjo C1v/6auCGz4gmJ9eHioRcRFq4gsHFjeKVBECuuAGtIVQ2NiP7qtGOgVTq/Yb Fvz1LoVdjdH0ux5zoZPJDobeDJnnkPJ+w9d0vR+06PoOmseY3keesbaZazIF GYc9t8YLbyZcL7bw878L7NdF0nS3egQ2BdTYFjZYQDjcxpd+j7xFFFFFFFFF FFFEj+Kq5/1fUj8Hc/g7K147Ofzf0Ruq8v5mri4J747iuHPj4Us2zYQDnqdI SgD1UXWQCoN9cC7ySgzm0OyJRL7OAc+ntYBWv/+nAKgD9gqZ96B3P0jjW9Hs efTBb92BKxoet8imp6dE6OazSujT4qY9JnBrwlB7hc4PT7pCUV77nwPz/j8D xfC/NAvPe+VXtz2bEvjnlV2CXvryrv1vKa7V+t1uLrsbE9MyvqKHnq9MPLDQ 9EkD1gQNrpYevBIdKSqbv5NRuAuZXGo28/65XrwtU6PPIuy01+ZNMuILzJlw keHRQQcBzZ4k9JfQdHkyzEeHQI9EQbq/Q2CPc6aDjnKZK373+hC/o+Ho+8RR RRRRRRRf/HYAgEUgMAAiAIokXshHyH8/sMmfwecyI+fzeTjn9TCi7aCP5Cuy HfWs/X+6OWvfoqr7zkinoPP90buE+tTb0S+OWBnNdMhwkS6VKixU9Li0rDq6 IpTJ4QViT7ER/4DxznndbhpYwf95M5+I3Vh2kk4Gb/85qCvrj2NBk6PXtZ7t tBy6lKZPYk3J6XDp66uJVEj1uyQ7fkUT5iNS0ddWn19dURV3emgy740Keury VGY9apFrp8me8v6ZXVbFSpe6iDXJ63oFVSHwpaUQKsdX8ajgAPu1Rv4KRb7f upp9RhMbHBHo/TN11cLVZ6SDHSIL2MG/vjOg172/dvVI9jAjuOAeuj2riJ7j 8+jytcm/thmhFC+W5oEPb7Tw/J8T83i+RYuNH+gaa3J+mD9tX0frlYT8H72q fZ7XY8/0XTWs+Da3fzvZwej7wj57/+TEPXsAQAcA --= Multipart Boundary 1214020139-- From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Dec 19 10:58:24 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18650 for ; Thu, 19 Dec 2002 10:58:23 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBJFtSFp028482 for ; Thu, 19 Dec 2002 07:55:28 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBJFtSiO009324 for ; Thu, 19 Dec 2002 07:55:28 -0800 (PST) Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gBJFtB4p017999 for ; Thu, 19 Dec 2002 07:55:11 -0800 (PST) Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id HAA00757 for ; Thu, 19 Dec 2002 07:36:37 -0800 (PST) Received: by xbl.ma.emulex.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Dec 2002 10:36:36 -0500 Message-ID: <3356669BBE90C448AD4645C843E2BF289B8F89@xbl.ma.emulex.com> From: "Williams, Jim" To: "'sctp-impl@external.cisco.com'" Subject: SCTP for RDDP Date: Thu, 19 Dec 2002 10:36:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" I have been looking at the implications of using SCTP for RDDP. This would typically be a small embedded implementation with severely limited resources (SCTP on the NIC card), and am trying to understand how this would work. I am starting from zero with respect to SCTP knowledge so apologies in advance if some of my questions are from basic ignorance. 1. It seems that multi-homing will be of limited value for RDDP. An implementation can certainly advertise only a single local address, by how is the case handled where the remote end sends too many IP addresses? Since remote addresses for an association consume non-trivial local resources, the implementation will want to set a limit (quite possible one) on the this. My impression is that SCTP sets no limit on this, and provides no simple mechanism for one end to reject a subset of the addresses offered by the other end. One possibility is to simply ignore some of the addresses offered by the other end. The creates a problem if a packet arrives from one of those addresses. The naive behavior would be to respond with an ABORT, but that would not be correct. Alternative behavior of receiving an "out of the blue" packet might be to use the VTag as a hash key to recover any matching association. If there is one, and the parameters all match except the source address, then ignore the packet rather than sending an ABORT. 2. It seems that window management could be simplified a lot by assuming outstanding data is equal to ( (last_TSN_sent - last_cum_TSN_ack) * MTU ). This would result in overly conservative behavior, but seems like it would be compliant and not perform badly. Is this correct? 3. It seems that an implementation may want to limit the amount of information sent in a SACK, and limit the amount of information it pays attention to for incoming SACKs. I am not totally clear on the MAY/MUST boundary here. Are implementations free to regard gap ack blocks and duplicate TSNs as hints the may be ignored or withheld when convenient (to bound resource usage)? Thanks, Jim From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Thu Dec 19 16:53:49 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27976 for ; Thu, 19 Dec 2002 16:53:48 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gBJLjcfm008610 for ; Thu, 19 Dec 2002 13:45:39 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBJLjaKi003189 for ; Thu, 19 Dec 2002 13:45:36 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gBJLjZjp011476 for ; Thu, 19 Dec 2002 13:45:35 -0800 (PST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gBJLR2v2005881 for ; Thu, 19 Dec 2002 14:27:02 -0700 (MST) Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id OAA08024 for ; Thu, 19 Dec 2002 14:26:47 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id gBJLN5f13874; Thu, 19 Dec 2002 15:23:05 -0600 (CST) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id PAA11897; Thu, 19 Dec 2002 15:24:31 -0600 (CST) Message-ID: <3E0238B7.51B4CE25@Motorola.com> Date: Thu, 19 Dec 2002 15:23:03 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Williams, Jim" CC: sctp-impl@external.cisco.com Subject: Re: SCTP for RDDP References: <3356669BBE90C448AD4645C843E2BF289B8F89@xbl.ma.emulex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Jim, "Williams, Jim" wrote: > > I have been looking at the implications of using > SCTP for RDDP. This would typically be a small > embedded implementation with severely limited > resources (SCTP on the NIC card), > and am trying to understand how this would work. > I am starting from zero with respect to SCTP knowledge > so apologies in advance if some of my questions > are from basic ignorance. > > 1. > > It seems that multi-homing will be of limited > value for RDDP. An implementation can certainly > advertise only a single local address, by how > is the case handled where the remote end sends > too many IP addresses? Since remote addresses > for an association consume non-trivial local > resources, the implementation will want to set > a limit (quite possible one) on the this. > My impression is that SCTP sets no limit on > this, and provides no simple mechanism for > one end to reject a subset of the addresses > offered by the other end. > > One possibility is to simply ignore some of > the addresses offered by the other end. > The creates a problem if a packet arrives from > one of those addresses. The naive behavior > would be to respond with an ABORT, but that > would not be correct. Alternative behavior > of receiving an "out of the blue" packet > might be to use the VTag as a hash key to > recover any matching association. If there > is one, and the parameters all match except > the source address, then ignore the packet > rather than sending an ABORT. To abort a legit peer is not good. I think the easiest and cleanest way to not support multi-homing and remain compliant is to: * always advertise a single local address when sending your INIT or INIT-ACK; * accept and keep the full list of address(es) your peer gives you; * when validating an incoming packet, use all the peer's addresses, so you will not get the above ABORT situation. * when sending (including both fresh sends and retrans), only use one of the peer's address as dest addr. This way, you no longer need to code the CC, RTO, heartbeat, reachability, etc, on multiple destination addresses, since you will always only use 1 dest addr to send. > > 2. > > It seems that window management could > be simplified a lot by assuming outstanding > data is equal to > ( (last_TSN_sent - last_cum_TSN_ack) * MTU ). > This would result in overly conservative > behavior, but seems like it would be > compliant and not perform badly. Is this > correct? I am not sure about performance of this. But, yes, being more conservative is surely going to be considered compliant. > 3. > > It seems that an implementation may want > to limit the amount of information sent > in a SACK, and limit the amount of information > it pays attention to for incoming SACKs. > I am not totally clear on the MAY/MUST > boundary here. Are implementations free > to regard gap ack blocks and duplicate TSNs > as hints the may be ignored or withheld when > convenient (to bound resource usage)? Sending and receiving gaps reported in SACKs have too much implication to the behaviors of the protocol. I wouldn't want to skip that. Duplicate TSNs are mostly hints and I think you should be fine if you choose to ignore them, especially your associations are most likely singly-homed. -Qiaobing > > Thanks, Jim From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Thu Dec 19 17:47:35 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29569 for ; Thu, 19 Dec 2002 17:47:34 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gBJMkRKv006573 for ; Thu, 19 Dec 2002 14:46:27 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBJMkQCE000309 for ; Thu, 19 Dec 2002 14:46:26 -0800 (PST) Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gBJMk94p002445 for ; Thu, 19 Dec 2002 14:46:09 -0800 (PST) Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id OAA12128; Thu, 19 Dec 2002 14:29:14 -0800 (PST) Received: by xbl.ma.emulex.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Dec 2002 17:29:14 -0500 Message-ID: <3356669BBE90C448AD4645C843E2BF289B8F8E@xbl.ma.emulex.com> From: "Williams, Jim" To: "'Qiaobing Xie'" Cc: sctp-impl@external.cisco.com Subject: RE: SCTP for RDDP Date: Thu, 19 Dec 2002 17:29:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Qiaobing Xie [mailto:Qiaobing.Xie@Motorola.com] > I think the easiest and cleanest way to not support multi-homing and > remain compliant is to: > * always advertise a single local address when sending your INIT or > INIT-ACK; > * accept and keep the full list of address(es) your peer gives you; This is the problem. How many addresses do I reserve space for? If I reserve space for 10, do I abort the association if the remote end sends 11? I am sure a software based implementation would simply malloc a list of whatever size was needed to hold all of them, and abort the association if the malloc failed. While it is possible to do this in an embedded hardware accelerated implementation, it is worth serious effort to avoid. > * when validating an incoming packet, use all the peer's > addresses, so > you will not get the above ABORT situation. > * when sending (including both fresh sends and retrans), only use one > of the peer's address as dest addr. > > This way, you no longer need to code the CC, RTO, heartbeat, > reachability, etc, on multiple destination addresses, since you will > always only use 1 dest addr to send. OK, but the bigger problem is being able to bound the worst case size of the association state representation. Minimizing the typicial size is much less important. Oversizing is fine as long as the maximum is finite, known, and managable. > Sending and receiving gaps reported in SACKs have too much implication > to the behaviors of the protocol. I wouldn't want to skip that. I wouldn't want to skip it either. But I would like to limit the number of gap ack blocks in each direction to three. If three is not enough, how about six? The answer I don't want is "as many as the remote end wants". He can send me 137, by I will only note the first three. My concern was I don't know if this violates a "MUST" in the spec. From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Dec 19 18:19:33 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00379 for ; Thu, 19 Dec 2002 18:19:32 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBJNJ4Fp014704 for ; Thu, 19 Dec 2002 15:19:04 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBJNJ4Yr004153 for ; Thu, 19 Dec 2002 15:19:04 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gBJNIj4p025373 for ; Thu, 19 Dec 2002 15:18:46 -0800 (PST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id gBJN0fne000335; Thu, 19 Dec 2002 16:00:41 -0700 (MST) Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA03769; Thu, 19 Dec 2002 16:00:41 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id gBJN0ef20743; Thu, 19 Dec 2002 17:00:40 -0600 (CST) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id RAA11991; Thu, 19 Dec 2002 17:02:06 -0600 (CST) Message-ID: <3E024F90.E4AF0E6B@Motorola.com> Date: Thu, 19 Dec 2002 17:00:32 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Williams, Jim" CC: sctp-impl@external.cisco.com Subject: Re: SCTP for RDDP References: <3356669BBE90C448AD4645C843E2BF289B8F8E@xbl.ma.emulex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Williams, Jim" wrote: > > > -----Original Message----- > > From: Qiaobing Xie [mailto:Qiaobing.Xie@Motorola.com] > > > I think the easiest and cleanest way to not support multi-homing and > > remain compliant is to: > > * always advertise a single local address when sending your INIT or > > INIT-ACK; > > * accept and keep the full list of address(es) your peer gives you; > > This is the problem. How many addresses do I reserve space for? > If I reserve space for 10, do I abort the association if the > remote end sends 11? SCTP does not dictate how or how much resource you must put aside for an association. Therefore, you can always set your own internal resource bound and reject an association with a "out of resource" error. This is completely legal. E.g., you can have your impl to handle max 3 peer dest addr. If you get an INIT or INIT-ACK with >5 addr, send an "out-of-resource" ERROR back and reject the association. In fact, any robust implementation must set this internal bound. > I am sure a software based implementation would simply malloc > a list of whatever size was needed to hold all of them, and > abort the association if the malloc failed. While it is > possible to do this in an embedded hardware accelerated > implementation, it is worth serious effort to avoid. ditto. > > > * when validating an incoming packet, use all the peer's > > addresses, so > > you will not get the above ABORT situation. > > * when sending (including both fresh sends and retrans), only use one > > of the peer's address as dest addr. > > > > This way, you no longer need to code the CC, RTO, heartbeat, > > reachability, etc, on multiple destination addresses, since you will > > always only use 1 dest addr to send. > > OK, but the bigger problem is being able to bound the worst case > size of the association state representation. Minimizing the > typicial size is much less important. Oversizing is fine > as long as the maximum is finite, known, and managable. ditto. > > > Sending and receiving gaps reported in SACKs have too much implication > > to the behaviors of the protocol. I wouldn't want to skip that. > > I wouldn't want to skip it either. But I would like to limit the > number of gap ack blocks in each direction to three. If three > is not enough, how about six? The answer I don't want is > "as many as the remote end wants". He can send me 137, by > I will only note the first three. > > My concern was I don't know if this violates a "MUST" in the spec. Again, the "MUST" is meant to make the spec theoretically sound. My feeling is that to ignore some of the gaps in either direction will have some performance penalty and thus should be allowable. One possibility is that you will lose some opportunity to perform fast retransmission that is supposed to be a performance enhancer. In the spirit that one can always be more conservative than the spec, I think it should even be allowable if one says "I will trade fast retransmission for simplicity". IMO, it is ok. For example, by giving up fast retransmission capability, you could remove a lot of complexity. As far as one does not do anything more aggressive than the spec and does not claim such a lite version a general purpose SCTP stack, then he/she should be politically correct :-) -Qiaobing From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Fri Dec 20 08:29:11 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26853 for ; Fri, 20 Dec 2002 08:29:10 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gBKDQUKv016125; Fri, 20 Dec 2002 05:26:30 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ABE54601; Fri, 20 Dec 2002 05:26:28 -0800 (PST) Message-ID: <3E031A84.10407@cisco.com> Date: Fri, 20 Dec 2002 07:26:28 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Williams, Jim" CC: "'Qiaobing Xie'" , sctp-impl@external.cisco.com Subject: Re: SCTP for RDDP References: <3356669BBE90C448AD4645C843E2BF289B8F8E@xbl.ma.emulex.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jim a couple of comments... Williams, Jim wrote: > > >>-----Original Message----- >>From: Qiaobing Xie [mailto:Qiaobing.Xie@Motorola.com] >> >> > > > >>I think the easiest and cleanest way to not support multi-homing and >>remain compliant is to: >> * always advertise a single local address when sending your INIT or >>INIT-ACK; >> * accept and keep the full list of address(es) your peer gives you; >> >> > >This is the problem. How many addresses do I reserve space for? >If I reserve space for 10, do I abort the association if the >remote end sends 11? > >I am sure a software based implementation would simply malloc >a list of whatever size was needed to hold all of them, and >abort the association if the malloc failed. While it is >possible to do this in an embedded hardware accelerated >implementation, it is worth serious effort to avoid. > > I think Q mentioned this but I will re-iterate it as well.. You can always set up your resource limits the way you want.. then if you don't like what the peer gives you (i.e. 28 addresses) send an abort(out-of-resource). I believe one of the early versions of SCTP for IOS did this only it was even more restrictive... you had to tell it which addresses were expected on each side.. If you missed one the association would get an abort() .. I think it has changed from that now.. but it WAS and IS legal to do this... > > >> * when validating an incoming packet, use all the peer's >>addresses, so >>you will not get the above ABORT situation. >> * when sending (including both fresh sends and retrans), only use one >>of the peer's address as dest addr. >> >>This way, you no longer need to code the CC, RTO, heartbeat, >>reachability, etc, on multiple destination addresses, since you will >>always only use 1 dest addr to send. >> >> > >OK, but the bigger problem is being able to bound the worst case >size of the association state representation. Minimizing the >typicial size is much less important. Oversizing is fine >as long as the maximum is finite, known, and managable. > > Which you can do completely within the bounds of the protocol by sending a ABORT(out-of-resource). > > >>Sending and receiving gaps reported in SACKs have too much implication >>to the behaviors of the protocol. I wouldn't want to skip that. >> >> > >I wouldn't want to skip it either. But I would like to limit the >number of gap ack blocks in each direction to three. If three >is not enough, how about six? The answer I don't want is >"as many as the remote end wants". He can send me 137, by >I will only note the first three. > >My concern was I don't know if this violates a "MUST" in the spec. > > I do believe the implementors-guide makes sending gap-ack-blocks a must.. however I think one could limit these to some fixed number and still be ok... performance would suffer.. but it is legal as long as you put in 1 gap ack block when you have one (or more)... So I would think one could limit this to "six" and be within legal bounds... you will not perform as well in lossy situations.. but that is probably ok.. R > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Fri Dec 27 06:08:37 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05662 for ; Fri, 27 Dec 2002 06:08:35 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gBRB6ofm005053 for ; Fri, 27 Dec 2002 03:06:50 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBRB6k8Z027354 for ; Fri, 27 Dec 2002 03:06:46 -0800 (PST) Received: from out008.verizon.net (out008pub.verizon.net [206.46.170.108]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gBRB6hhN022359 for ; Fri, 27 Dec 2002 03:06:44 -0800 (PST) Received: from duck ([67.212.84.214]) by out008.verizon.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with ESMTP id <20021227104753.DFZ27807.out008.verizon.net@duck> for ; Fri, 27 Dec 2002 04:47:53 -0600 Message-ID: <475624-220021252710514640@duck> X-Priority: 3 Reply-To: market.access@verizon.net X-MSMail-Priority: Normal Errors-to: market.access@verizon.net Organization: Market*Access Int'l From: "David Dickson" To: "SCTP-IMPL@EXTERNAL.CISCO.COM" Subject: Homeland Def. Trng & Grants - Jan 14-16, 2003 - New Speakers Added-Colo Sprngs Date: Fri, 27 Dec 2002 05:51:04 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA05662 TO: SCTP-IMPL@EXTERNAL.CISCO.COM Homeland Defense and Homeland Security in the 21st Century Regional, State and Local Strategies Homeland Defense Training Conference *** Includes special Grants Workshop and briefings by the new DoD Northern Command -- See below for details *** Colorado Springs, Colorado Three-day Training Conference and Grants Workshop Tuesday – Wednesday – Thursday * January 14, 15, 16, 2003 The Broadmoor Conference Center Colorado Springs, Colorado 80906 Hotel reservations and Information (800) 634-7711 (Special room rates have been established for conference attendees. When you call to make your reservation, register using the following code: HDJ03.) *** Call our Events Hotline at 703-807-2027 to learn how to register on-line and see updated speaker list *** ****** If your company has a product or service directed at the Homeland Defense Community, then this is the conference you should attend and exhibit at. Early registrations indicate strong attendance by state and local information technology, CIOs, document managers, GIS users and emergency management leaders from the Western states. The new Northern Command will be in attendance. If your company sells products or services that will be purchased using grant funds, then you will not want to miss the Grants Workshop ******* About this conference This administration will direct billions of dollars through federal and state agencies with the goal of improving America’s ability to detect, respond, recover and reconstitute from terrorist attacks. Many of these improvements will directly assist state and local leaders as they also respond to national disasters and major industrial accidents. Funding will include pending funds from the First Responder Initiative now before congress. This $3.5 billion dollar initiative will be focused at state and local needs for communications, emergency medical and first responders. America’s 3,000 counties and 18,000 cities all have varying needs and requirements based on infrastructure and threat. An important element of planning is the development of regional agreements thus saving valuable resources by developing joint support agreements and response plans. This conference will examine the development of strategies, requirements, solutions and plans at the regional, state and local levels. Federal agency support programs will also be examined. **** WE ALREADY HAVE OVER 250 REGISTRANTS. SIGN UP SOONEST **** Other topics include: * Report on federal and state grants to support homeland defense initiatives * Grants workshop with tips, tools, lessons-learned * Briefings by Northern Command on roles, mission and requirements * Report from Capital Hill on pending legislation, funding and new programs * Federal agency reports on roles at regional, state and local levels Who Should Attend * Regional, state and local emergency management executives and senior staff * Federal and DoD managers with an assigned mission in homeland defense * Industry executives with products and services that support homeland defense * Trainers and instructors in emergency response * State and local grants staff interested in updating their understanding of available grants and grants application techniques Speakers Include: Speakers Include * Rear Admiral Daniel H. Stone, United States Navy, Director of J4 Logistics and Engineering for North American Aerospace Defense Command (NORAD) and United States Northern Command (NORTHCOM) * Dr. Ron Sega, Director, Defense Research & Engineering (DDR&E) (invited) * Dr. Charles Benight, Associate Professor of Psychology, Department of Psychology, University of Colorado at Colorado Springs * Jeff Goldberg, EMT-P, Emergency Management Advisor to the Director of Integrated Support Services, Library of Congress * Eric Mason, Supervisory Special Agent, CALEA Implementation Section, FBI * William E. Ayen, Ph.D., Director, Network, Information, and Space Security Center (NISSC), University of Colorado * Robert E. Roberts, Regional Administrator, EPA * Valerie McNevin, Chief Information Security Officer and Privacy for the State of Colorado, State of Colorado Office of CIO for Info Security * LTC Frederick Hoon, Commander, 8th Weapons of Mass Destruction - Civil Support Team (WMD/CST) * Speaker TBD, Colorado Department of Public Safety * Montana - Office of Emergency Management (Invited) * Lyn McCall, COO, Will Interactive Inc * Dennisses Valdes, Deputy Director, Environmental Response Team (ERT) West, EPA * Speaker TBD, Nextel Communications * Mary Beth Enggren, NASASP (National Association of State Agencies for Surplus Properties) * Mr. Rick Meador, Division Chief for the Plans, Policies, & Warfighter Support Division, Joint Interoperability Test Command, DoD Grants Workshop Speakers * David Maurstad, Regional Director, FEMA * Michael Paddock, President, Grants Office LLC. (Mr. Paddock will chair the Grants Workshop) * Stephen M. Sorett, Attorney at Law, Reed Smith, Washington, D.C. (Nationally recognized Grants law expert) * Christopher L. Rissetto, Partner, Reed Smith, Washington, D.C. (Nationally recognized Grants law expert) * Mr. Donovan Puffer, FEMA Region 8, First Responder Grants Program Special Exhibit and Sponsor Opportunities Available. Call Cara Lombardi at 703-807-2743 for more information. *** Call our Events Hotline at 703-807-2027 to learn how to register on-line and see updated speaker list and list of early registrants.*** Homeland Defense Training Conference Agenda Day One * Tuesday * 14 January 2003 Afternoon: Registration and check in Evening: Networking reception at the Broadmoor Hotel Day Two * Wednesday * 15 January 2003 All day: Briefings by federal, state and local emergency management executives on plans, requirements, challenges and needs. Day Three * Thursday * 16 January 2003 Morning: Briefings by federal, state and local emergency management executives on plans, requirements, challenges and needs. Grants Workshop. Afternoon: Networking, check-out Special Grants Workshop During the three-day conference a workshop will be presented by the Colorado Springs Economic Development Corporation, the Homeland Defense Journal, Grants Office and the law firm of ReedSmith. This three-hour workshop will guide attendees through the maze of federal grants, provide tips and tools for preparing your grants and a proprietary database of over 160 federal, state and private grants for homeland defense and homeland security. Two distinguished legal experts in Grants law will walk the attendees through post award requirements for audit and compliance. No state, city or county grants manager should miss this important session. If your company has a product or service that will likely be purchased with grants funds, you should attend this very important workshop. Sponsor Exhibit Area A limited number of sponsor exhibits will be available for networking and information exchange. These exhibits will focus on industry and government agency solutions for homeland defense related products and services. Major corporations and Colorado small business will be featured. Exhibits, case studies and demonstrations will provide the attendee with a wide range of product and solutions information. Sponsors * Colorado Springs Economic Development Corporation * Colorado Springs Chamber of Commerce * Homeland Defense Journal * University of Colorado * XAWare, Inc. * Computer Sciences Corporation * Perseus * NexTel * Symantec * ESRI * Raytheon * Will Interactive, Inc. * Disaster Recovery Institute International * Contingency Planning and Management Online * Grants Office, LLC * ReedSmith, LLC * INPUT * Colorado Space Enterprise (Formerly Colorado Space Council) * Market*Access International, Inc. Registration Information Corporate/Industry $795 Government $345 Small business (less than 100 employees) $495 Includes meals, reception, conference, proceedings binder, Grants training, Grants database researched and compiled by Market*Access. This database retails for $295.00 and is provided to each attendee at the training course for Grants. *** Call our Events Hotline at 703-807-2027 to learn how to register on-line and see updated speaker list *** __________________________________________________________________________ Homeland Defense and Homeland Security in the 21st Century January 14-16, 2003 **** Registration Form **** (Use additional pages as needed for multiple employees) Attendee Name: Title: Company/Agency: Company/Agency Web site: Address: City: State: Zip Code: Email: Telephone: Fax: Note: Payment requested in advance. Please check one of the following as your form of payment: [ ] Check Make checks payable to: Market*Access International Send to: Market*Access, 4301 Wilson Boulevard, Suite 1003, Arlington VA 22203 [ ] VISA [ ] MasterCard [ ] American Express Account Number: ___________________________Exp. Date___________________ Cardholder Name: ______________________________________________________ Signature (required) or telephone order _______________________________________ Pre-Registration Fee: Industry: $795 Government: $345 Small Business (100 employees or fewer): $495 Additional Information can be obtained by calling our EVENTS HOTLINE at 703-807-2027. Registration and Information: Call Parrish S. Knight (703) 807-2748 Fax this form to 703-807-2728. Thank you. This business communication was sent to you to inform you of a training conference for homeland security. If you wish to be REMOVED from this communication, please place REMOVE in the SUBJECT line and REPLY to this message. We do NOT wish to send you emails that you are not interested in receiving. The email address used to send this message was: SCTP-IMPL@EXTERNAL.CISCO.COM *** Call our Events Hotline at 703-807-2027 to learn how to register on-line and see updated speaker list *** If you wish to be REMOVED from this list, please REPLY and place REMOVE in the SUBJECT line. From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Dec 30 04:46:11 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21025 for ; Mon, 30 Dec 2002 04:46:10 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gBU9YPKv015403 for ; Mon, 30 Dec 2002 01:34:25 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBU9YPSw008185 for ; Mon, 30 Dec 2002 01:34:25 -0800 (PST) Received: from hindon.hss.co.in ([202.54.26.202]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gBU9Xqpj027859 for ; Mon, 30 Dec 2002 01:33:54 -0800 (PST) Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gBU8tkr16491 for ; Mon, 30 Dec 2002 14:25:46 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gBU8tj816486 for ; Mon, 30 Dec 2002 14:25:45 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gBU8vkD19679 for ; Mon, 30 Dec 2002 14:27:46 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C9F.00307F70 ; Mon, 30 Dec 2002 14:19:43 +0530 X-Lotus-FromDomain: HSS From: mrajpal@hss.hns.com To: sctp-impl@external.cisco.com Message-ID: <65256C9F.00307F0E.00@sandesh.hss.hns.com> Date: Mon, 30 Dec 2002 14:24:23 +0530 Subject: Error Cause TLV in ASCONF-ACK Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi The addip draft says: "The entire TLV that is refused is copied from the ASCONF into the error cause.", but in the example TLV shown below (as in the draft) +--------------------------------+ | Type = 0xC003 | Length = 24 | +--------------------------------+ | C-ID = 0x01023474 | +--------------------------------+ | Cause=0x000C | Length = 16 | +----------------+---------------+ | Type=0xC001 | Length = 12 | +--------------------------------+ | Type=0x0005 | Length = 8 | +----------------+---------------+ | Value=0x0A010101 | The Request being refused to ADD an address does not have the correlation ID, which is not the case when TLV is copied from the chunk. Please clarify the right behavior. Should 1) the ASCONF ACK contained TLV copied from the asconf chunk (as written in text)?, or 2) The sender of ACK must build the parameter without the correlation id (as shown in all examples) regards manish www.hssworld.com From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Dec 30 08:05:17 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24034 for ; Mon, 30 Dec 2002 08:05:16 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gBUD47Kv014238; Mon, 30 Dec 2002 05:04:07 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ABG00445; Mon, 30 Dec 2002 05:04:04 -0800 (PST) Message-ID: <3E10443E.7000506@cisco.com> Date: Mon, 30 Dec 2002 07:03:58 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mrajpal@hss.hns.com CC: sctp-impl@external.cisco.com Subject: Re: Error Cause TLV in ASCONF-ACK References: <65256C9F.00307F0E.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit mrajpal@hss.hns.com wrote: > >Hi > >The addip draft says: >"The entire TLV that is refused is copied from the ASCONF into the error >cause.", > >but in the example TLV shown below (as in the draft) > > +--------------------------------+ > | Type = 0xC003 | Length = 24 | > +--------------------------------+ > | C-ID = 0x01023474 | > +--------------------------------+ > | Cause=0x000C | Length = 16 | > +----------------+---------------+ > | Type=0xC001 | Length = 12 | > +--------------------------------+ > | Type=0x0005 | Length = 8 | > +----------------+---------------+ > | Value=0x0A010101 | > > > >The Request being refused to ADD an address does not have the correlation ID, >which is not the case when TLV is copied from the chunk. > This is an error in the draft and I will fix it in the next pass :-0 R >Please clarify the right behavior. >Should 1) the ASCONF ACK contained TLV copied from the asconf chunk (as written >in text)?, or >2) The sender of ACK must build the parameter without the correlation id (as >shown in all examples) > > >regards >manish >www.hssworld.com > > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)