OFFRE DE STAGE
=20
Grande Distribution

Nous recherchons :

Des stagiaires (1^ère ou = 2^ème=20 année)

Vous assisterez les responsables commerciaux régionaux , et = vous vous=20 familiariserez avec les méthodes du commerce moderne=20 .

Vous prendrez en charge pendant deux mois la direction d’un point de vente=20 et de son équipe.

Vous êtes capable de vous intégrer dans une = équipe jeune=20 et dynamique. Les responsabilités ne vous font pas peur. Vous = êtes=20 extraverti et aimez le commerce de masse, c’est vous que nous=20 recherchons.

Postes à pourvoir : = Marseille, Lyon=20 (St-Priest,Villefranche), Tours (Chambray), Annecy, Bordeaux, = Valenciennes,=20 Blois, Tours, Chartres, Albi, Orléans, St-Quentin, Nîmes, = Poitiers,=20 Angoulême, Troyes, Lille (V-Asq,Wattignies) , Valenciennes = (Anzin),Laval ,=20 Toulon (LaValette), Béziers, St-Etienne, Avignon (Sorgues), = Bourges,=20 Châteauroux, Le Mans, Niort, Strasbourg (Vendenheim), Metz, Brest, = St-Malo, Orange, Dijon, Toulouse (Portet, Roques), Narbonne, = Clermont-Ferrand=20 (Aubière), Arles, Alès, Voiron, Paris et banlieue (Lagny,=20 Pontault-C, Créteil, Saulx-l-Ch, Vélizy, Fresnes, St- = Denis,=20 Ste-Geneviève).

( liste complète sur www.multichauss.com/listemag.htm )

Indemnité de stage conventionnelle.

Merci d’adresser votre candidature à

MULTICHAUSS S.A.

DRH

Patricia Coulange

Le Guillaumet

60 avenue du président Wilson

92046 PARIS LA DEFENSE CEDEX 70

tél : 01 47 76 23 46

fax: 01 40 90 95 92 E-mail : PC@Multichauss.com

------=_NextPart_000_0157_01BE328A.8A880C00-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Mon Dec 28 17:35:01 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA00219 for ; Mon, 28 Dec 1998 17:34:59 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA19202; Mon, 28 Dec 1998 14:30:36 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA27531 for nat-outgoing; Mon, 28 Dec 1998 14:29:51 -0800 (PST) From: Pyda Srisuresh Message-Id: <199812282229.OAA27524@server.livingston.com> Subject: Re: (NAT) Host NAT issues and Security Policy Servers To: mcr@sandelman.ottawa.on.ca Date: Mon, 28 Dec 1998 14:29:47 -0800 (PST) Cc: nat@livingston.com, policy@raleigh.ibm.com In-Reply-To: <199812080132.UAA04648@morden.sandelman.ottawa.on.ca> from "Michael Richardson" at Dec 7, 98 08:32:19 pm Content-Type: text Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Pyda Srisuresh Hi, Sorry to be late on this thread. Still catching up with my e-mail after the IETF. I mostly agree with the observations in your e-mail below. But, I would like to add a couple of comments. 1. Clearly, an IP packet traversing the Internet is subject to Policy based networking. There are a variety of policies in place. IPsec, QOS, NAT, firewall, BGP etc. to name a few and many of these policies require some kind of state on the enforcement nodes. At the same time as policy based networking is becoming pervasive, there is growing desire to make end-nodes smarter and network/policy aware. To that end, the SPS draft identifies a mechanism to offer policy service to end nodes and intermediate nodes alike. However, SPS is only a policy server, not an enforcement point. You do need protocols and enforcement points that execute specific policies. In particular, a Host-NAT protocol that can be used by private hosts to attain temporary external address to connect to external nodes is required. 2. There are parallels between Host-NAT and Mobile-IP. I agree. But, there are many differences. The goal of Mobile-IP is to preserve home-address based connectivity as a node roams outside its network. To that end, a MN uses a temporary Care-of-Address to tunnel home-address based end-to-end packets to HA. The goal of Host-NAT, on the other hand, is to facilitate end-to-end packets without requiring translation enroute. To that end, a Host-NAT-client uses temporarily assigned external address to frame end-to-end packets (not to encapsulate in). Unlike Mobile-IP, Host-NATs deal predominantly with private address spaces. In the case of Host-NAPT, multiple private nodes share the same global address with different TCP/UDP port. Also, Unlike a Home Agent (HA) node in Mobile-IP, a NAT node serving as Host-NAT server does not need to be a tunnel end point to route end-to-end packets within private realm. (Ref: NAT Terminology draft for alternative forms of Host-NAT operation). 3. I also agree with Brian Carpenter's observation (in a follow-on e-mail) that Host-NAT, Mobile-IP, IPsec and other end-to-end preservation softwares share the characteristic of requiring mods to host software (unlike traditional NAT). cheers, suresh > > -----BEGIN PGP SIGNED MESSAGE----- > > > [I'm going to appologize in advance for cross posting so widely. > I'm feeling a bit like every working group I attend is dealing with > the same problems. > I also, due to fog, missed both nat and aaa this morning. I heard > the aaa BOF didn't arrive at any clear conclusions, and I'm glad there > wasn't a fire drill during the NAT meeting or someone might have been > trampled. ] > > Mike> Jeff, > > Mike> The framework that is used by DNAT, and now host-NAT, > Mike> consists of several fundamental ideas: > > Mike> - Tunneling between a router or device with a public IP address > Mike> and an end host. > > DNAT specifically supported IPsec tunnelling to the NAT device. This > is important to a number of environments where they actually want > authenticated outbound firewall traversal. > > Mike> - Using TCP/UDP ports or some other mechansim or combinations > Mike> thereof to uniquely identify hosts from the private address > Mike> space. > Mike> - Assignment of global IP addresses to hosts for them to use when > Mike> talking with the outside world. > > I want to note that this problem is essentially *IDENTICAL* to do > the IPsec road warrior configuration problem. It is also a variation > of the problem that Luis et al. designed their security policy system to > solve. (draft-ietf-ipsec-sps-00.txt coming to a draft directory near > you. I don't have the URL handy right now) > > Mike> The PDP was meant just to distribute port numbers. Nothing > Mike> else. In our way of thinking, assignment of an IP address > Mike> or other parameters to a host might as well occur using an > Mike> existing extensible protocol, such as DHCP or as part of a > Mike> tunnel establishment, rather than reproducing existing > Mike> functionality. These parameters may require renegotiation. > Mike> See the "Perspectives" section of the DNAT draft for a > Mike> discussion of this. The PDP is not limited in any sense. > > The SPS policy server could well assign numbers. > And yes, DHCP could do it. This was suggested for client > configuration in the road warrior case. > In addition, extensions to ISAKMP are being suggested to do client > configuration. > > Mike> I recently started writing a draft about the general > Mike> framework of end-to-end communication through a NAT, listing > Mike> the issues that any solution must address. Here are some of > Mike> the most relevant issues: > > I want to point out that IPsec security gateways are essentially > stateful routers. Alas, we reinvent ATM! As such, the end-to-end > issues with NAT and with IPsec are essentially the same. (ignoring the > fact that NAT and IPsec often sit on the same box) > As far as I'm concerned, the IP address in protocol problem typified > by FTP, IRC (dcc), RealX, is less of a problem. These problems are > simple and easily solved both at the NAT stage (after protocol design) > and at the protocol design stage. But, getting rid of IP addresses in > the TCP data flow doesn't solve anything: The question that should be > asked by the IAB is does ICMP work through a NAT/IPsec box. > > The real issue is not, can NAT work in the presence of end-to-end > IPSEC (DNAT and host-NAT are existence proofs that it is possible > to do something), nor is the issue that IPsec makes traditional NAT > hard to do, but that IPsec and NAT both introduce stateful > routing. diffserv tries to not introduce more state. > > I think, the model that we have essentially converged upon in IPsec, > NAT, diffserv, intserv, rap, aaa, qos... is of the end host going out > to the network *policy* server and saying: "I'd like to do X" > The policy server responds and says: "I'll let you do X, but to do > so you will have to perform the following things: A, B, C." > If I'm not mistaken (and I probably am, since the closest I ever got to > an actual telephone switch, a DMS100, was when I once fixed the test > guy's lab Xterminal many years ago), SS7 provides similar types of > conversations. > > To recap, there are multiple protocols (or proposals) so far for > carrying questions from the end systems to the intermediate systems: > 1. RSVP > 2. ISAKMP > 3. host NAT, DNAT, DHCP > 4. router/prefix discovery stuff in v6. > 5. BBN's SPS protocol > 6. SOCKS > 7. ARP, ND > > [You may think that ARP doesn't belong, but I think that it does > because it is something that one does prior to sending a packet to the > node in question. There is no IS unless you consider a bridge to be a > layer 2 IS] > > From intermediate systems to policy servers we have: > 1. COPS > 2. SPS > 3. radius > 4. AAA > 5. did I miss something? > > A significant thing about the SPS work is that it operates both from > ES to IS, and from IS to IS, and from IS to policy server. In > addition, it permits *discovery* of IS systems and associated policy > servers in the forwarding path, which isn't something that I see in > the other protocols. > I would like to see COPS and SPS merged somehow, and I wonder if > this can provide the common AAA protocol, as well as the common > DNAT/host-NAT, IPsec tunnel end point discovery, ... protocol. I don't > know what this does to RSVP in the diffserv border router model. > > hmm. Pizza is here. > > ] At IETF43. Continental sucks |1 Fish/2 Fish[ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ > ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3ia > Charset: latin1 > Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface > > iQBVAwUBNmyBlx4XQavxnHg9AQH2AgH/f5ltwjZS94Tiw3z8fJReRyBJXCiypQbX > si7pz5NxK+TnQxj5DwmeJydFAxd8hTaYhEzA7eSLyPa7zn0B34MZQg== > =IusE > -----END PGP SIGNATURE----- > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Mon Dec 28 19:13:59 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA00684 for ; Mon, 28 Dec 1998 19:13:58 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA21514; Mon, 28 Dec 1998 16:09:34 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA06363 for nat-outgoing; Mon, 28 Dec 1998 16:09:08 -0800 (PST) From: Pyda Srisuresh Message-Id: <199812290009.QAA06355@server.livingston.com> Subject: Re: (NAT) Host NAT issues To: jlo@polke.neclab.com Date: Mon, 28 Dec 1998 16:09:03 -0800 (PST) Cc: Mike_Borella@mw.3com.com, jlo@ccrl.sj.nec.com, nat@livingston.com, David_Grabelsky@mw.3com.com, Ikhlaq_Sidhu@mw.3com.com In-Reply-To: from "Jeffrey Lo" at Dec 8, 98 08:59:13 pm Content-Type: text Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Pyda Srisuresh Mike, Jeff, Gabriel et. al, Host-NAT framework/requirements draft is fine. The goal is to find, design or converge on a protocol that enables Host-NAT operation. Jeff has apparantly identified some requirements in the e-mail below and in his HNAT draft. So did Mike and Gabriel in their respective DNAT and NAR drafts. There is some commonality amongst the three drafts. There is also plenty of room for making the requirements firm. I suggest gathering requirements specifically for Host-NAT and Host-NAPT. If the resulting protocol happens to have wider applicability beyond Host-NAT, that is fine. But, wider applicability in itself should not be the goal. The NAT-API draft has requirements/framework for wider applicability (including ALGs, Host-NAT clients and management applications) as far as NAT interfacing is concerned. I suggest, you take a look at (a) NAT Terminology draft, and (b) NAT API draft for some additional thoughts. Have a nice day. cheers, suresh > > > Mike, > > > I recently started writing a draft about the general framework of > > end-to-end > > communication through a NAT, listing the issues that any solution must > > address. Here are some of the most relevant issues: > > > > - Unique Determination of Local Destination Address > > - Negotiation and/or Specification of Demultiplexing Fields > > - Assignment of Parameters to Hosts by Some Device > > - Tunnel Use and Establishment > > Sorry for the short delay in replying to this email. Yes, a framework > document is needed. > > > In terms of where this should go within the IETF, I think that both the > > DNAT and > > Host-NAT drafts are too specific in how they describe solutions to the > > end-to-end issues. Perhaps what is needed is a generic end-to-end > > NAT solution with UDP-based setup and negotiation between the hosts > > and router or some other device. Using attribute value pairs, arbitrary > > parameters could be set up and negotiated through a "control channel" > > with a much more flexible packet format. This approach may re-invent > > the wheel to some respect, but it would be far more general than what > > we currently have. > > I agree that some form of "control protocol" would be necessary. That's > what we have been trying to drive at. In particular, the following issues > should be considered. > > 1. Built on existing protocol (DHCP, ICMP, COPS??) > Is there already something in the existing protocols that we can > exploit or do we absolutely have to build from scratch? > 2. Generality > Where should the line be drawn? How much do we want the protocol to do? > 3. Extensibility > > In the context of HNAT/DNAT, the protocol should enables the following. > > 1. Acquisition of multiplexing fields > Global IP address, TCP/UDP port, Protocol ID > > 2. Negotiation of tunnel types > A default tunnel type could probably be chosen > > 3. Negotiation of HNAT related parameters > Max Lease Time, NAT Type > > 4. Registration of client agent and specification of client type > Client ID assignment > > 5. Subnet enquiry? > > I think using a common control protocol like this would ensure > interoperability. > > Framework and protocol should probably be addressed in separate documents. > > Thanks. > > Jeff > > > > > > > Hi, > > > > This is sent in response to a recent comment about HNAT draft proposed to > > NAT workgroup. > > > > We are particularly interested larger scale deployment of private > > addressing. A case where a band of global IP addresses are managed by the > > address manager, which may or may not reside on the Host-NAT-Server. We > > realised the existence of DNAT draft and attempted to apply Port > > Distribution Protocol (PDP) proposed in draft-borella-aatn-dnat-01.txt in > > our scenario. It is during this attempt that we find PDP insufficient and > > does not support dynamic global IP address assignment. Hence our primary > > motivation is to propose a more generic protocol that serves a > > greater majority of the NAT community. As a result, we are proposing > > Dynamic Bindings Acquisition Protocol (BDAP). Having said these, we do not > > deny the fact that DBAP support port assignment as well and could be used > > in places where PDP is used. > > > > Another motivation for our draft is the fact that we feel PDP lacks many > > important features which are fundamental for larger scale operation. We > > don't see our differences as being minor but rather fundamental. To state > > some of the differences: > > > > Error Reporting > > It is important for accurate error reporting so that Host-NAT-Clients know > > about source of error. For example, is a request denied due to resource > > reasons, policy reasons or other miscellaneous reasons. This is not > > possible with PDP. > > > > Max. Leased Time > > It is important for Host-NAT-Client to be able to negotiate a lease time > > interval with Host-NAT-Server. This is especially important in scenarios > > where address management and NAT are performed by different authority. > > One example is the case when private addressing is adopted by an ISP and > > it wishes to delegate global address lease on an enterprise basis. In > > this case, Host-NAT-Clients deamons may not be situated in end host but > > may be some access routers. In this case, such global leasing may be > > directly > > connected to billing. In the current PDP, it is unclear how this is done > > apart from some default interval pre-selected during configuration. > > > > BindID > > This is vital for both efficient indexing and serves as an identifier if a > > Host-NAT-Client requests for more than one binds from a Host-NAT-Server. > > For example, we know that IPSEC ESP does not work with NAPT, a > > Host-NAT-Client > > may be using a port range for IPSEC AH. When an application is started > > requiring ESP security, a global address needs to be acquired. BindID is > > required to correctly identify bindings on Host-NAT-Server. It > > seems to us that PDP only supports a single port range bind at > > this moment. Although not a major motivation, BindID also introduces a > > layer of protection against security attacks. > > > > If you have some ideas or implementations that suits our purpose, we would > > be glad to hear about it. We feel that it is unfair for the authors to > > claim something that has not being documented. > > > > Thanks. > > > > Jeff > > > > > > On Thu, 3 Dec 1998, Mike Borella wrote: > > > > > > > > > > > A couple of notes regarding the recent host NAT draft: > > > > > > - We presented distributed NAT (DNAT) at the Chicago IETF in the > > > ngtrans WG. Host NAT is DNAT with only some very minor modifications. > > > Interested parties should look at: > > > > > > > > http://search.ietf.org/internet-drafts/draft-borella-aatn-dnat-01.txt > > > > > > - DNAT has been implemented (from the draft description) by a third > > party. > > > It works quite well. > > > > > > - The draft makes some incorrect comments about DNAT. In particular, > > > the authors claim that DNAT does not allow the sharing on multiple IP > > > addresses, but it does. This misconception seems to be the motivating > > > factor of the (very minor) differences between DNAT and host NAT. > > > > > > In case it isn't obvious, my point is that this scheme has already > > > been proposed and presented at IETF. I do not think that host NAT is > > > significantly different from DNAT, though I'll happily entertain > > > arguments to the contrary. > > > > > > -Mike > > > > > > > > > - > > > To unsubscribe, email 'majordomo@livingston.com' with > > > 'unsubscribe nat' in the body of the message. > > > > > > > > > > > > > > > > > - > > To unsubscribe, email 'majordomo@livingston.com' with > > 'unsubscribe nat' in the body of the message. > > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message.