Received: from cnri by ietf.org id aa29384; 6 Mar 97 18:29 EST Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa20537; 6 Mar 97 18:29 EST Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA28625 for ipsec-outgoing; Thu, 6 Mar 1997 18:16:37 -0500 (EST) From: Dan McDonald Message-Id: <199703062319.PAA08906@kebe.eng.sun.com> Subject: Re: IP packet fragmentation To: Raul Olaya Date: Thu, 6 Mar 1997 15:19:33 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: from "Raul Olaya" at Mar 6, 97 06:07:08 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > How are IP security transforms applied to fragmented packets (for > example a 2000 byte PING which is fragmented into a 1500 byte fragment > (header+data) and 548 byte fragment (header+data))?. Is the packet > reassembled in the outbound direction and then the security transform > applied to the entire reassembled packet? IPsec _must_ be done before fragmentation. This is specified in RFC 1825, and why this is a good idea is documented in Bellovin's USENIX Security paper from last summer. Bump-in-the-stack encryptors are a nice short-term fix, but in the long term, IPsec NEEDS to dig its meathooks into the general IP code. Basically, outbound processing is: 1.) create IP headers 2.) Fill in headers 3.) Apply IPsec 4.) Do I fragment? If so, fragment. 5.) Send out the wire. On inbound packets... 1.) Get off the wire, check if for me. If not, forward. 2.) Reassemble 3.) Apply IPsec 4.) Determine HLP/endpoint/etc. > or is the security transform applied to the first 1500 byte fragment, and > 548 byte fragment independently? NO NO NO! This is bad. I'm sure lots of implementations currently do this, but it's bad because either: 1.) You have to keep security information per reassembly queue ** OR ** 2.) The bad guy can inject fragments of his choosing. IMPORTANT SAFETY TIP: IPsec, THEN fragment. -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (415) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush   Received: from cnri by ietf.org id aa00920; 6 Mar 97 19:25 EST Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa21412; 6 Mar 97 19:25 EST Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA28901 for ipsec-outgoing; Thu, 6 Mar 1997 19:09:02 -0500 (EST) Date: Thu, 6 Mar 1997 16:13:30 -0800 Message-Id: <199703070013.QAA26923@gump.eng.ascend.com> From: Karl Fox To: Dan McDonald Cc: Raul Olaya , ipsec@tis.com Subject: Re: IP packet fragmentation In-Reply-To: <199703062319.PAA08906@kebe.eng.sun.com> References: <199703062319.PAA08906@kebe.eng.sun.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk > > How are IP security transforms applied to fragmented packets (for > > example a 2000 byte PING which is fragmented into a 1500 byte fragment > > (header+data) and 548 byte fragment (header+data))?. Is the packet > > reassembled in the outbound direction and then the security transform > > applied to the entire reassembled packet? > > IPsec _must_ be done before fragmentation. This is specified in RFC 1825, > and why this is a good idea is documented in Bellovin's USENIX Security paper > from last summer. If you're running on a host, yes. If you're running on an encrypting gateway, you wrap each fragment in a tunnel mode packet. Of course, you might fragment the resulting encrypted datagram if it's too big. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841   Received: from cnri by ietf.org id aa24347; 13 Mar 97 11:59 EST Received: from uscore-1.mv.com by CNRI.Reston.VA.US id aa14313; 13 Mar 97 11:59 EST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA23557 for ; Thu, 13 Mar 1997 11:56:08 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 13 Mar 1997 11:51:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA23272 for pwg-outgoing; Thu, 13 Mar 1997 11:47:45 -0500 (EST) Message-Id: <199703131648.AA29795@interlock.lexmark.com> To: "pwg%pwg.org" , P1284_3 , "1394-prt-img%mail.fireflyinc.com" <1394-prt-img@mail.fireflyinc.com> From: Don Wright Date: 13 Mar 97 11:46:32 EST Subject: PWG> Austin - Ping Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-pwg@pwg.org Attention: P1284.4, 1394 Printing, IPP, PMP, JMP, Sense groups The time has come to ping me to let me know your plans for attending the IEEE and PWG meetings in Austin, Texas on March 31 through April 4th. Meeting details are available off the PWG Chair's page at: http://www.pwg.org/chair/index.html Please only ping me and not the mailing lists -- they are crowded enough as it is. So that everyone can see who plans to attend which meetings, I have made the ping list available at: http://www.pwg.org/chair/aus-ping.html I only need to know which days you will be in attendance. Since there is no group hotel, arrival and departure dates are not needed. Thanks! Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * *************************************************************   Received: from cnri by ietf.org id aa10139; 24 Mar 97 15:05 EST Received: from ietf.org by CNRI.Reston.VA.US id aa17736; 24 Mar 97 15:05 EST Received: from ietf.org by ietf.org id aa10128; 24 Mar 97 15:05 EST Received: from doggate.microsoft.com by ietf.org id aa10123; 24 Mar 97 15:04 EST Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id ; Mon, 24 Mar 1997 12:01:31 -0800 Message-ID: <0A684133865BCF118F0E08002BE7ADACE1AF69@DABONE> Sender:iesg-request@ietf.org From: "Mike Gahrns (Exchange)" To: 'IESG' Cc: "'Harald Alvestrand (IETF Area Director)'" , "'Keith Moore (IETF Area Director)'" Subject: Last call on draft-gahrns-imap-referrals-01 Date: Mon, 24 Mar 1997 12:01:22 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain The last call on draft-gahrns-imap-referrals-01 is to expire March 26. I have received a request, to extend the draft to allow referrals on other IMAP commands such as COPY and APPEND. I think this a good idea, and I would like to issue another draft that addresses referrals for these and additional IMAP commands. Hopefully in the next week or so, I will have another draft ready that addresses the above which I will submit to the UW IMAP4 mailing list for discussion. Please hold off advancing draft-gahrns-imap-referrals-01. Sorry that this came so close to the end of the last call period. Thanks, -mikega   Received: from cnri by ietf.org id aa05542; 25 Mar 97 5:29 EST Received: from ietf.org by CNRI.Reston.VA.US id aa06322; 25 Mar 97 5:29 EST Received: from ietf.org by ietf.org id aa05535; 25 Mar 97 5:29 EST Received: from tyholt.uninett.no by ietf.org id aa05531; 25 Mar 97 5:29 EST Received: from tikneppen.uninett.no (tikneppen.uninett.no [129.241.131.70]) by tyholt.uninett.no (8.7.6/8.7.3) with SMTP id LAA13372; Tue, 25 Mar 1997 11:26:23 +0100 (MET) X-Authentication-Warning: tyholt.uninett.no: Host tikneppen.uninett.no [129.241.131.70] didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 Sender:iesg-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: "Mike Gahrns (Exchange)" cc: 'IESG' , "'Keith Moore (IETF Area Director)'" Subject: Re: Last call on draft-gahrns-imap-referrals-01 In-reply-to: Your message of "Mon, 24 Mar 1997 12:01:22 PST." <0A684133865BCF118F0E08002BE7ADACE1AF69@DABONE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Mar 1997 11:26:23 +0100 Message-ID: <1047.859285583@tikneppen.uninett.no> X-Orig-Sender: Harald.T.Alvestrand@uninett.no Mike, it seems to me that adding COPY and APPEND to the redirects leads you into the area where you have to synchronize between multiple IMAP servers (espec. COPY). I'm not sure this is a good idea on the first try; would it be better to issue this Proposed Standard now, and add extensions later? Harald A   Received: from cnri by ietf.org id ab10410; 25 Mar 97 14:27 EST Received: from ietf.org by CNRI.Reston.VA.US id aa18102; 25 Mar 97 14:27 EST Received: from ietf.org by ietf.org id aa10403; 25 Mar 97 14:27 EST Received: from doggate.microsoft.com by ietf.org id aa10399; 25 Mar 97 14:27 EST Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id ; Tue, 25 Mar 1997 11:24:18 -0800 Message-ID: <0A684133865BCF118F0E08002BE7ADACE1AF76@DABONE> Sender:iesg-request@ietf.org From: "Mike Gahrns (Exchange)" To: "'Harald Alvestrand (IETF Area Director)'" Cc: 'IESG' , "'Keith Moore (IETF Area Director)'" Subject: RE: Last call on draft-gahrns-imap-referrals-01 Date: Tue, 25 Mar 1997 11:24:12 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Hi Harald, I agree with your concern regarding avoiding areas that would need to deal with synchronization between multiple servers, and will definitely avoid that. However, I am was thinking about a less ambitious approach. As in the SELECT of a mailbox case, the referral would be just a hint to the client that it needs to make a connection to another server to access that mailbox. For APPEND I envisioned something like: e.g. C: A001 APPEND mailboxfoo data... S: A001 NO [REFERRAL IMAP://Server2/mailboxfoo] Remote mailbox The client would then need to do a connection to the server2 to append the data. This saves the client from needing to select the folder first before doing the append. COPY would be more difficult for the client. Essentially a tagged NO with a referral would be a hint to the client that it needs to make a connection to another server, and APPEND the data itself, rather than relying on the server to do it. These suggestions have come about as our client team is getting some implementation experience under their belts with this draft. I would like to try to incorporate their ideas/experience if possible. What would your thoughts be, if a subsequent draft, took the less ambitious approach outlined above? P.S. I will be travelling the rest of this week, and may be quite unresponsive on e-mail. Apologies for any delay in getting back to you. thx, -mikega > ---------- > From: > Harald.T.Alvestrand@uninett.no[SMTP:Harald.T.Alvestrand@uninett.no] > Sent: Tuesday, March 25, 1997 2:26 AM > To: Mike Gahrns (Exchange) > Cc: 'IESG'; 'Keith Moore (IETF Area Director)' > Subject: Re: Last call on draft-gahrns-imap-referrals-01 > > Mike, > it seems to me that adding COPY and APPEND to the redirects leads > you into the area where you have to synchronize between multiple > IMAP servers (espec. COPY). > I'm not sure this is a good idea on the first try; would it be better > to issue this Proposed Standard now, and add extensions later? > > Harald A > >   Received: from cnri by ietf.org id aa28145; 26 Mar 97 2:08 EST Received: from ietf.org by CNRI.Reston.VA.US id aa03196; 26 Mar 97 2:08 EST Received: from ietf.org by ietf.org id aa28115; 26 Mar 97 2:08 EST Received: from tyholt.uninett.no by ietf.org id aa28108; 26 Mar 97 2:08 EST Received: from munken.uninett.no (munken.uninett.no [129.241.131.10]) by tyholt.uninett.no (8.7.6/8.7.3) with SMTP id IAA07091; Wed, 26 Mar 1997 08:04:57 +0100 (MET) X-Authentication-Warning: tyholt.uninett.no: Host munken.uninett.no [129.241.131.10] didn't use HELO protocol X-Mailer: exmh version 1.6.7 5/3/96 Sender:iesg-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: "Mike Gahrns (Exchange)" cc: 'IESG' , "'Keith Moore (IETF Area Director)'" Subject: Re: Last call on draft-gahrns-imap-referrals-01 In-reply-to: Your message of "Tue, 25 Mar 1997 11:24:12 PST." <0A684133865BCF118F0E08002BE7ADACE1AF76@DABONE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Mar 1997 07:05:53 +0000 Message-ID: <11356.859359953@munken.uninett.no> X-Orig-Sender: unknown@uninett.no OK - that level of ambition (only tagged responses) sounds like a perfectly reasonable extension - if your draft can suffer another 4-week delay, it sounds sensible to Just Do It now. Have fun! Harald A   Received: from cnri by ietf.org id aa06802; 27 Mar 97 1:22 EST Received: from ietf.org by CNRI.Reston.VA.US id aa02652; 27 Mar 97 1:22 EST Received: from ietf.org by ietf.org id aa06795; 27 Mar 97 1:22 EST Received: from doggate.microsoft.com by ietf.org id aa06791; 27 Mar 97 1:22 EST Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id ; Wed, 26 Mar 1997 22:19:11 -0800 Message-ID: <0A684133865BCF118F0E08002BE7ADACE1AF85@DABONE> Sender:iesg-request@ietf.org From: "Mike Gahrns (Exchange)" To: "'Harald Alvestrand (IETF Area Director)'" Cc: 'IESG' , "'Keith Moore (IETF Area Director)'" Subject: RE: Last call on draft-gahrns-imap-referrals-01 Date: Wed, 26 Mar 1997 22:18:56 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Great. As much as I hate to delay the draft, I think it is the right thing to do so I will go for it. I am trying to free up some time so that I can get a new draft submitted to the mailing list ASAP. thx, -mikega > ---------- > From: > Harald.T.Alvestrand@uninett.no[SMTP:Harald.T.Alvestrand@uninett.no] > Sent: Tuesday, March 25, 1997 11:05 PM > To: Mike Gahrns (Exchange) > Cc: 'IESG'; 'Keith Moore (IETF Area Director)' > Subject: Re: Last call on draft-gahrns-imap-referrals-01 > > OK - that level of ambition (only tagged responses) sounds like a > perfectly reasonable extension - if your draft can suffer another > 4-week delay, it sounds sensible to Just Do It now. > > Have fun! > > Harald A > >   Received: from cnri by ietf.org id aa01245; 27 Mar 97 13:39 EST Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa17406; 27 Mar 97 13:39 EST Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA29942 for snmpv2-outgoing; Thu, 27 Mar 1997 13:28:06 -0500 (EST) From: Keith McCloghrie Message-Id: <199703271833.KAA22598@foxhound.cisco.com> Subject: Re: Table idices To: John Leonard Date: Thu, 27 Mar 1997 10:33:15 -0800 (PST) Cc: snmpv2@tis.com, snmp@lists.psi.com In-Reply-To: <19970327175904927.AAA169@jleonard.wireless.tellabs.com> from "John Leonard" at Mar 27, 97 01:01:18 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-snmpv2@ex.tis.com Precedence: bulk > Is there any SNMP or SNMPv2 RFC that comes out and states that INTEGER > table indices can't take the value 0? I know that there is a *very* strong > convention that they not use 0, but is this actually forbidden? It's not forbidden. The convention is specifically for "small arbitrary" integers (e.g., ifIndex) are non-negative, not for meaningful integer values. Keith.   Received: from cnri by ietf.org id aa04050; 27 Mar 97 14:33 EST Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa18685; 27 Mar 97 14:33 EST Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA00480 for snmpv2-outgoing; Thu, 27 Mar 1997 14:24:15 -0500 (EST) X-Sender: bstewart@puli.cisco.com Message-Id: In-Reply-To: <19970327175904927.AAA169@jleonard.wireless.tellabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Mar 1997 14:26:28 -0500 To: John Leonard From: Bob Stewart Subject: Re: Table idices Cc: SNMPv2 List , SNMP List Sender: owner-snmpv2@ex.tis.com Precedence: bulk Circa 1:01 PM -0500 3/27/97, John Leonard bitwhacked: >Is there any SNMP or SNMPv2 RFC that comes out and states that INTEGER >table indices can't take the value 0? I know that there is a *very* strong >convention that they not use 0, but is this actually forbidden? Zero is a legitimate table index. It is typically avoided for the "arbitrary integer index" so it can be used for other purposes, such as in a reference to indicate no index is set or applies. Bob   Received: from cnri by ietf.org id aa08207; 27 Mar 97 15:37 EST Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa20098; 27 Mar 97 15:37 EST Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00829 for snmpv2-outgoing; Thu, 27 Mar 1997 15:25:58 -0500 (EST) Date: Thu, 27 Mar 97 12:28:01 pst From: David Perkins Subject: RE: Table idices To: SNMPv2 List , SNMP List , John Leonard X-Mailer: Chameleon V0.05, TCP/IP for Windows, NetManage Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Sender: owner-snmpv2@ex.tis.com Precedence: bulk John, On your question below... On Thu, 27 Mar 1997 13:01:18 -0500 John Leonard wrote: >Hi All, > >Is there any SNMP or SNMPv2 RFC that comes out and states that INTEGER >table indices can't take the value 0? I know that there is a *very* strong >convention that they not use 0, but is this actually forbidden? > There is no such rule that states that the value of zero cannot be used. Also see page 106, and background pages 24-27, and 100-109 in "Understanding SNMP MIBs" by Perkins and McGinnis. Regards, /dperkins@scruznet.com, David T. Perkins Date: 03/27/97, Time: 12:28:02   Received: from cnri by ietf.org id aa20788; 27 Mar 97 18:49 EST Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa24441; 27 Mar 97 18:49 EST Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA02055 for snmpv2-outgoing; Thu, 27 Mar 1997 18:30:36 -0500 (EST) From: John Leonard To: David Perkins , SNMPv2 List , SNMP List , John Leonard Subject: Re: Table idices Date: Thu, 27 Mar 1997 18:36:52 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <19970327233436625.AAA74@jleonard.wireless.tellabs.com> Sender: owner-snmpv2@ex.tis.com Precedence: bulk David, Thanks for your answer. I immediately tracked down our department's copy of "Understanding SNMP MIBs" (who is this "Perkins" guy anyways? I think somebody stole your name), spent some time with it and will point out the suggested sections to the person who asked me the question. Happily, we've all given the same answer. By the way, the book is great resource I hope you keep on writing, Thanks Again, John ---------- > From: David Perkins > To: SNMPv2 List ; SNMP List ; John Leonard > Subject: RE: Table idices > Date: Thursday, March 27, 1997 3:28 PM > > John, > > On your question below... > On Thu, 27 Mar 1997 13:01:18 -0500 John Leonard wrote: > >Hi All, > > > >Is there any SNMP or SNMPv2 RFC that comes out and states that INTEGER > >table indices can't take the value 0? I know that there is a *very* strong > >convention that they not use 0, but is this actually forbidden? > > > There is no such rule that states that the value of zero cannot be used. > Also see page 106, and background pages 24-27, and 100-109 in "Understanding > SNMP MIBs" by Perkins and McGinnis. > > Regards, > /dperkins@scruznet.com, David T. Perkins > Date: 03/27/97, Time: 12:28:02 >