From owner-ietf-ppp-outgoing@merit.edu Wed Apr 4 03:05:37 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7F78E5DE05; Wed, 4 Apr 2001 03:05:37 -0400 (EDT) Received: from ws9.cdotb.ernet.in (unknown [202.41.72.121]) by segue.merit.edu (Postfix) with ESMTP id 24FE65DE0A for ; Wed, 4 Apr 2001 03:03:11 -0400 (EDT) Received: from jnana.cdotb.ernet.in (jnana.cdotb.ernet.in [192.168.51.201]) by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id MAA04846 for ; Wed, 4 Apr 2001 12:23:15 +0500 (GMT+0500) Received: from cdotb.ernet.in by jnana.cdotb.ernet.in (8.8.8/1.1.22.3/28Nov00-1214PM) id MAA0000017680; Wed, 4 Apr 2001 12:23:29 +0500 (GMT+0500) Message-ID: <3ACAC743.25ECDBC9@cdotb.ernet.in> Date: Wed, 04 Apr 2001 12:33:32 +0530 From: "N.Suresh" Organization: C-DoT X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: PPP towards router Content-Type: multipart/alternative; boundary="------------27ADEBA5EA6DDA650F8A65EB" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --------------27ADEBA5EA6DDA650F8A65EB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi , we are planning to use PPP over E1 interface towards the router..... will RFC 1812 (Requirements for IP v4 Routers) alright for starting with the requirements capturing.... bye regards -- -----------------***************************************---------------- N.SURESH Research Engineer, Centre For Development of Telematics, 71/1,Sneha Complex, Bangalore-560052 -----------------***************************************---------------- --------------27ADEBA5EA6DDA650F8A65EB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi ,
        we are planning to use PPP over E1 interface towards the router.....
 
       will RFC 1812  (Requirements for IP v4 Routers) alright for starting with the requirements capturing....

      bye
      regards

-- 
-----------------***************************************----------------
                                N.SURESH
                            Research Engineer,
                  Centre For Development of Telematics,
                           71/1,Sneha Complex,
                            Bangalore-560052            
-----------------***************************************----------------
  --------------27ADEBA5EA6DDA650F8A65EB-- From owner-ietf-ppp-outgoing@merit.edu Wed Apr 4 07:55:33 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8D0695DE5F; Wed, 4 Apr 2001 07:55:32 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 3FF615DE31 for ; Wed, 4 Apr 2001 07:51:03 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA01607; Wed, 4 Apr 2001 04:50:45 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26419; Wed, 4 Apr 2001 07:50:44 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f34BpNB98830; Wed, 4 Apr 2001 07:51:23 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15051.2747.117772.216163@gargle.gargle.HOWL> Date: Wed, 4 Apr 2001 07:51:23 -0400 (EDT) From: James Carlson To: "N.Suresh" Cc: ietf-ppp@merit.edu Subject: Re: PPP towards router In-Reply-To: N.Suresh's message of 4 April 2001 12:33:32 References: <3ACAC743.25ECDBC9@cdotb.ernet.in> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu N.Suresh writes: > we are planning to use PPP over E1 interface towards the > router..... OK, that part sounds reasonable. > will RFC 1812 (Requirements for IP v4 Routers) alright for > starting with the requirements capturing.... I think you have sent your message to the wrong mailing list. The PPP Extensions working group doesn't set or maintain router requirements. (RFC 1812 is a fair place to start, but there's an awful lot of unwritten information that's needed to build a working router. I'd recommend hiring a consultant instead of fishing through RFCs.) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Apr 5 01:25:18 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D768E5DE3D; Thu, 5 Apr 2001 01:25:17 -0400 (EDT) Received: from ws9.cdotb.ernet.in (unknown [202.41.72.121]) by segue.merit.edu (Postfix) with ESMTP id 190695DE4F for ; Thu, 5 Apr 2001 01:23:22 -0400 (EDT) Received: from jnana.cdotb.ernet.in (jnana.cdotb.ernet.in [192.168.51.201]) by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id KAA23810 for ; Thu, 5 Apr 2001 10:44:26 +0500 (GMT+0500) Received: from cdotb.ernet.in by jnana.cdotb.ernet.in (8.8.8/1.1.22.3/28Nov00-1214PM) id KAA0000008076; Thu, 5 Apr 2001 10:45:40 +0500 (GMT+0500) Message-ID: <3ACC01D6.3955E489@cdotb.ernet.in> Date: Thu, 05 Apr 2001 10:55:42 +0530 From: "N.Suresh" Organization: C-DoT X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: [Fwd: PPP in HDLC-like framing (fwd)] Content-Type: multipart/mixed; boundary="------------3086F895816759D4D61932A8" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a multi-part message in MIME format. --------------3086F895816759D4D61932A8 Content-Type: multipart/alternative; boundary="------------12B1024B9314B89BFFC935D4" --------------12B1024B9314B89BFFC935D4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In ISO/IEC 3309:1993 about HDLC frame structure is is seen in section 4.7.1 that " The FCS shall be transmitted to the line commencing with the coefficient of the highest term". This means that the msb of the least significant octet of the CRC is sent out on the line first. However, in RFC 1662 it is mentioned in section 5.5 that "All octets are transmitted least significant bit first". Does the term "All octets" include the CRC octets also? If yes, then RFC 1662 specifies a framing structure different from HDLC. Please clarify. regards -- -----------------***************************************---------------- N.SURESH Research Engineer, Centre For Development of Telematics, 71/1,Sneha Complex, Bangalore-560052 -----------------***************************************---------------- --------------12B1024B9314B89BFFC935D4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

  In ISO/IEC 3309:1993 about HDLC frame structure is is seen in section
4.7.1 that " The FCS  shall be transmitted to the line commencing with the
coefficient of the highest term". This means that the msb of the least
significant octet of the CRC is sent out on the line first.

However, in RFC 1662  it is mentioned in section 5.5 that "All octets are transmitted
least significant bit first".

Does the term "All octets" include the CRC octets also? If yes, then RFC 1662 specifies a framing structure different from HDLC.

Please clarify.

regards

-- 
-----------------***************************************----------------
                                N.SURESH
                            Research Engineer,
                  Centre For Development of Telematics,
                           71/1,Sneha Complex,
                            Bangalore-560052            
-----------------***************************************----------------
  --------------12B1024B9314B89BFFC935D4-- --------------3086F895816759D4D61932A8 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from ws9.cdotb.ernet.in by jnana.cdotb.ernet.in (8.8.8/1.1.22.3/28Nov00-1214PM) id JAA0000007609; Thu, 5 Apr 2001 09:58:51 +0500 (GMT+0500) Received: from jnana.cdotb.ernet.in (jnana.cdotb.ernet.in [192.168.51.201]) by ws9.cdotb.ernet.in (8.9.3/8.9.3) with SMTP id JAA01847 for ; Thu, 5 Apr 2001 09:57:36 +0500 (GMT+0500) Date: Thu, 5 Apr 2001 09:58:51 +0500 (GMT+0500) From: Roopa C To: nsuresh@cdotb.ernet.in Subject: PPP in HDLC-like framing (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ---------- Forwarded message ---------- Date: Thu, 5 Apr 2001 09:48:23 +0500 (GMT+0500) From: Roopa C To: roopa@cdotb.ernet.in Subject: PPP in HDLC-like framing In ISO/IEC 3309:1993 about HDLC frame structure is is seen in section 4.7.1 that " The FCS shall be transmitted to the line commencing with the coefficient of the highest term".In RFC 1662 about 'PPP in HDLC like framing' it is seen that "The FCS is transmitted least significant octet first, which contains the coefficient of the highest term" ( section 3.1).In the same RFC in section 5.5 about Bit-stuffed framing transmission considerations it is given that "All octets are transmitted least significant bit first". So what shall be the transmission strategy for FCS bits? Shall they be sent msb first as in ISO/IEC 3309 or does it mean that they shall be sent lsb first? Please explain. --------------3086F895816759D4D61932A8-- From owner-ietf-ppp-outgoing@merit.edu Thu Apr 5 09:07:04 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 44B9F5DE59; Thu, 5 Apr 2001 09:07:04 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 796605DE4F for ; Thu, 5 Apr 2001 09:07:02 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA12334; Thu, 5 Apr 2001 06:06:02 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14719; Thu, 5 Apr 2001 09:06:00 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f35D6dM01956; Thu, 5 Apr 2001 09:06:39 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15052.28127.272119.160532@gargle.gargle.HOWL> Date: Thu, 5 Apr 2001 09:06:39 -0400 (EDT) From: James Carlson To: "N.Suresh" Cc: ietf-ppp@merit.edu Subject: Re: [Fwd: PPP in HDLC-like framing (fwd)] In-Reply-To: N.Suresh's message of 5 April 2001 10:55:42 References: <3ACC01D6.3955E489@cdotb.ernet.in> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu N.Suresh writes: > Does the term "All octets" include the CRC octets also? Yes. > If yes, then RFC 1662 > specifies a framing structure different from HDLC. No, it does not. PPP uses HDLC framing. > Please clarify. Look more carefully at the FCS polynomial in RFC 1662: /* * The FCS-16 generator polynomial: x**0 + x**5 + x**12 + x**16. */ #define P 0x8408 The CRC calculation is reversed so that the highest-order term of the residue shows up in the LSB position. Most media are LSB-first. The only case that's broken is PPP over SONET/SDH, where the SONET/SDH specifications require that the bits be sent in MSB-first ordering, but PPP specifies the same FCS calculation (as though the bits were transmitted LSB-first). If you're doing it in hardware, this is an important nit to consider. It makes the usual shift register approach wrong. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Apr 5 11:53:28 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 523BC5DDC1; Thu, 5 Apr 2001 11:53:28 -0400 (EDT) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id F36F65DD97 for ; Thu, 5 Apr 2001 11:53:26 -0400 (EDT) Received: from karl-w98l.xc.org (ai70-004.aiinet.com [38.195.70.4]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H75MQ8A4; Thu, 5 Apr 2001 09:53:25 -0600 Message-Id: <4.3.2.7.2.20010405112220.046cdda0@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Apr 2001 11:32:41 -0400 To: Bruce A Thompson , Ali Irfan-FIA225 From: Karl Fox Subject: RE: Comments: ppp-over-aal2 Cc: "'ietf-ppp@merit.edu'" , Pazhyannur Rajesh-QA6283 In-Reply-To: <4.3.1.0.20010330115255.01d6de98@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 03:57 PM 3/30/01, Bruce A Thompson wrote: >>At 03:38 PM 03/29/2001 -0600, Ali Irfan-FIA225 wrote: >>Section 8: Should mention that PPP LCP FCS-alternatives extensions is >>described in RFC1570. (Any reason for using option values 32 and 64 and not >>8 and 16 for 8-bit CRC and 16-bit CRC? Is there a specific name to the 8 and >>16 bit CRCs described in the draft? > > From the last meeting, we decided to get rid of CRC-8. This will get rid of much of the complexity described in the draft. It also means that there will be no negotiation for CRC via LCP. This section will now just say that CRCs cannot be negotiated via LCP and that only CRC-16 is supported. There's no need to do that. Simply say that CRC-16 is the default FCS. If someone wants to implement RFC 1570, then let them. Those who don't will just reject the option. >>Section 8, last sentence: See first comments. Also Is the following >>statement from RFC2364 applicable here: >> >>The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a >> larger size than the maximum CPCS-SDU size specified in the >> associated direction for the virtual connection's traffic contract. > >The SSSAR function does not have any maximum payload defined for it. We should define the maximum payload based on CRC length from comments above. Better yet, ignore all the discussion about CRC length and payload length and just define the default packet size and default CRC type. That's what other PPP encapsulation documents do. >>Bigger question on section 6.2: In previous email-trains, there was concern >>that allowing multiple options for CRC based on length of payload causes >>complexity and should be avoided; however, the current draft still has two >>options CRC-8 and CRC-16 based on the length of the payload. The difference >>is only one byte. In most cases, the smallest size payload including the >>PPP-protocol id will be about 10 bytes. The difference between 8 and 16 bit >>CRC is 10% and will be lower for smaller sized payloads. Can we not just >>stick with the 16 bit CRC? > >That's what we decided in the last mtg. Note though the complexity is optional since 8 bit CRC is negotiated. If an 8-bit FCS would be useful, you could always write an enhancement to the FCS-Alternatives option described in RFC 1570. Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Sat Apr 7 13:45:14 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6EC585DDB5; Sat, 7 Apr 2001 13:45:13 -0400 (EDT) Received: from gate.internaut.com (unknown [64.38.134.101]) by segue.merit.edu (Postfix) with ESMTP id 581CC5DD9A for ; Sat, 7 Apr 2001 13:45:10 -0400 (EDT) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f37HYfN20926 for ; Sat, 7 Apr 2001 10:34:41 -0700 From: "Bernard Aboba" To: Subject: Comments on draft-ietf-pppext-eap-srp-01.txt Date: Sat, 7 Apr 2001 10:46:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Find enclosed below a review of this specification. Overall, I think that this work is quite promising, although there are some incompatibilities with RFC 2284. However, I believe that the spec can be reworked so as to be compatible, at the cost of an additional round-trip. Section 1 "Unlike all of these protocols, SRP is resistant to man-in-the-middle attacks." Do you have a reference to a security analysis that describes the man-in-the-middle vulnerabilities of MS-CHAPv2? I thought that only MS-CHAPv1 had this problem. Section 2 "Unlike CHAP, SRP-SHA1 requires more than one exchange to authenticate the peer. For this reason, the usual EAP Request/Response is insuf- ficient, and two separate Request/Response messages are defined." Actually, EAP methods are not restricted to a single Request/Response sequence. RFC 2284, section 2 states: "After the Link Establishment phase is complete, the authenticator sends one or more Requests to authenticate the peer. The Request has a type field to indicate what is being requested.... The peer sends a Response packet in reply to each Request. As with the Request packet, the Response packet contains a type field which corresponds to the type field of the Request. The authenticator ends the authentication phase with a Success or Failure packet." So an EAP method can use as many request/response sequences as necessary within a single method. ================================================================== "The adaptation described in this document uses the EAP Identity Request/Response mechanism to obtain C from the peer. It then uses two new message types -- EAP SRP-SHA1 Parts 1 and 2 -- to handle the SRP authentication." Using Identity request/response to obtain C is fine. But using two EAP types to implement EAP SRP-SHA1 is unnecessary. RFC 2284 states: "In practice, within or associated with each PPP server, it is not anticipated that a particular named user would be authenticated by multiple methods. This would make the user vulnerable to attacks which negotiate the least secure method from among a set (such as PAP rather than EAP). Instead, for each named user there should be an indication of exactly one method used to authenticate that user name. If a user needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method." Because of this, existing EAP implementations are typically not built to handle two-stage authentication techniques such as what you describe. My recommendation would be to use only a single method. =================================================================== Section 2.6 "The PPP EAP SRP-SHA1 Success message MUST be sent by the authenticator in response to a valid EAP SRP-SHA1 Part 2 Response packet, and MUST NOT be retransmitted on an authenticator time-out." Responsibility for re-transmission of EAP packets lies with the authenticator. Thus, if a Response or Request is lost, the Request is re-transmitted. The exception is EAP-Success messages which are not ACK'd. RFC 2284 section 2.2.2 states: "Implementation Note: Because the Success and Failure packets are not acknowledged, they may be potentially lost. A peer MUST allow for this circumstance. The peer can use a Network Protocol packet as an alternative indication of Success. Likewise, the receipt of a LCP Terminate-Request can be taken as a Failure." Note that this implies that on loss of the EAP-Success packet, the authenticatee will need to look for alternative signs of the authentication result. If the authenticator sends an NCP packet, then it will conclude that it authentication has succeeded. The authenticator will not know whether the authenticatee has received the packet or not -- and thus, whether the authenticatee has received the data that was included within the Success packet. I believe that this is one of the reasons why EAP Success packets do not contain data. =============================================================== Also within Section 2.6, you redefine the EAP-Success packet described in RFC 2284 to appear as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value M2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M2 (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M2 (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M2 (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M2 (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I must admit that there have been many times where I have wished for the ability to transmit data with an EAP Success packet. Unfortunately, this usage of the EAP Success packet is not permitted according to RFC 2284, Section 2.2, which states: A summary of the Success and Failure packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length 4 In other words, according to RFC 2284, an EAP Success packet MUST NOT contain a type field or data. This is a result of the lack of ACK'ing, as described above. Given that EAP Success messages conforming to RFC 2284 do not contain data, existing implementations will typically not pass anything contained beyond the length field to the EAP method. There are also NAS devices that will not forward such packets on to the client. My recommendation is to add an additional round-trip to the protocol and use the RFC 2284-defined EAP Success message. As much as I would love to fix RFC 2284 to permit this usage, I think that this would also require addressing the lack of ACKs for Success and Failure messages, which would create a backward compatiblity problem, so I can't see a way to make this work. ====================================================== Date: Tue, 20 Mar 2001 18:55:55 -0500 (EST) From: James Carlson To: pppext Subject: Secure Remote Password interest I asked this at the working group meeting today, and I'd like to put it to the group at large: if there are folks out there looking at the EAP SRP-SHA1 draft (draft-ietf-pppext-eap-srp-01.txt) please let me know; either privately or on the list. I have tested an implementation based on ANU ppp-2.4.0, and I'm planning to release this under a BSD license (pending some document signatures within Sun). This could serve as a reference implementation for testing purposes. I've gotten reports from the open source community that there's user interest, mostly because it fixes the CHAP shared secret problem. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon Apr 9 09:25:23 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 672C65DDD7; Mon, 9 Apr 2001 09:25:23 -0400 (EDT) Received: from fsnt.future.futsoft.com (unknown [203.197.140.35]) by segue.merit.edu (Postfix) with ESMTP id 4B0185DDA4 for ; Mon, 9 Apr 2001 09:25:21 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 09 Apr 2001 19:03:11 +0530 Received: from radhard (radhard.future.futsoft.com [10.0.12.108]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f39LTNL27276 for ; Tue, 10 Apr 2001 02:59:23 +0530 Received: by localhost with Microsoft MAPI; Mon, 9 Apr 2001 18:49:20 -0300 Message-Id: <01C0C125.C94B9B60.radhard@future.futsoft.com> From: Radha Rani Reply-To: "radhard@future.futsoft.com" To: "'ietf-ppp@merit.edu'" Subject: DHCP Relay Agent Option Date: Mon, 9 Apr 2001 18:49:18 -0300 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi, Please clarify the following doubt in DHCP relay agent option rfc (RFC 3046). In Section 2.1 of the RFC3046 it is mentioned that overall adding of the relay agent option is configurable. Is this configuration per-interface or for all users of relay agent. Thanks in advance. Regards, Radha From owner-ietf-ppp-outgoing@merit.edu Mon Apr 9 09:35:43 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6C73A5DDA4; Mon, 9 Apr 2001 09:35:43 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id C01185DD98 for ; Mon, 9 Apr 2001 09:35:41 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01804; Mon, 9 Apr 2001 06:35:35 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07152; Mon, 9 Apr 2001 09:35:36 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f39DaHX11967; Mon, 9 Apr 2001 09:36:17 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15057.47824.186624.210869@gargle.gargle.HOWL> Date: Mon, 9 Apr 2001 09:36:16 -0400 (EDT) From: James Carlson To: "radhard@future.futsoft.com" Cc: "'ietf-ppp@merit.edu'" Subject: Re: DHCP Relay Agent Option In-Reply-To: Radha Rani's message of 9 April 2001 18:49:18 References: <01C0C125.C94B9B60.radhard@future.futsoft.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Radha Rani writes: > Please clarify the following doubt in DHCP relay agent option rfc (RFC 3046). > In Section 2.1 of the RFC3046 it is mentioned that overall adding of the relay > agent option is configurable. Is this configuration per-interface or for all > users > of relay agent. Why did you ask this on the PPP Extensions mailing list? Are you sure you didn't intend to write to the DHC working group instead? Just because the interfaces in question happen to be PPP links isn't a good reason; this working group is concerned with extensions to the Point-to-Point Protocol, not all users of the protocol. In any event, the granularity of the enable/disable configuration is up to you. The IETF documents have nothing to say on the matter. If you need to configure Relay Agent operation per interface, then do so. (The rest of section 2.1 describes situations in which you might need to configure Relay Agent operation differently based on the whether the interface is considered "trustworthy." That should probably point in the direction of a good answer.) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Tue Apr 10 07:05:50 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2715A5DE11; Tue, 10 Apr 2001 07:05:50 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 8715B5DDFE for ; Tue, 10 Apr 2001 07:05:48 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11132; Tue, 10 Apr 2001 07:05:47 -0400 (EDT) Message-Id: <200104101105.HAA11132@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-posvcholo-03.txt Date: Tue, 10 Apr 2001 07:05:47 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Extending PPP over SONET/SDH, with virtual concatenation, high order and low order payloads Author(s) : N. Jones, C. Murton Filename : draft-ietf-pppext-posvcholo-03.txt Pages : 8 Date : 09-Apr-01 The RFC 1661 Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The RFC 1662 PPP in HDLC-like Framing [2] and RFC 2615 PPP over SONET/SDH (POS) [3] documents describe the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-posvcholo-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-posvcholo-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-posvcholo-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010409144248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-posvcholo-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-posvcholo-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010409144248.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Wed Apr 11 18:52:23 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 061475DFE5; Wed, 11 Apr 2001 18:44:24 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 4829F5E1F9 for ; Wed, 11 Apr 2001 18:29:27 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23246; Wed, 11 Apr 2001 15:29:20 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01723; Wed, 11 Apr 2001 18:29:20 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f3BMU0K35168; Wed, 11 Apr 2001 18:30:00 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15060.56039.730030.353116@gargle.gargle.HOWL> Date: Wed, 11 Apr 2001 18:29:59 -0400 (EDT) From: James Carlson To: "Bernard Aboba" Cc: Subject: Re: Comments on draft-ietf-pppext-eap-srp-01.txt In-Reply-To: Bernard Aboba's message of 7 April 2001 10:46:33 References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Bernard Aboba writes: > "Unlike all of these protocols, SRP is resistant to man-in-the-middle > attacks." > > Do you have a reference to a security analysis that describes the > man-in-the-middle vulnerabilities of MS-CHAPv2? I thought that > only MS-CHAPv1 had this problem. There's a good discussion of the weaknesses of MS-CHAPv2, but not the man-in-the-middle attacks, here: http://www.counterpane.com/pptpv2-paper.html I don't have references on the man-in-the-middle vulnerabilities, and my statement was an overbroad generalization. As Vern Schryver pointed out in an earlier message, I should rework this section. A much bigger benefit of SRP is that it's highly resistant to dictionary-based attacks, and none of the alternatives (including MS-CHAPv2) are. > Section 2 > > "Unlike CHAP, SRP-SHA1 requires more than one exchange to authenticate > the peer. For this reason, the usual EAP Request/Response is insuf- > ficient, and two separate Request/Response messages are defined." > > Actually, EAP methods are not restricted to a single Request/Response > sequence. RFC 2284, section 2 states: [...] > So an EAP method can use as many request/response sequences as > necessary within a single method. What I mean here is that the *USUAL* use of Request/Response is not enough, and that multiple Request/Response sequences are needed within this single method. I agree that this needs some work. > Because of this, existing EAP implementations are typically not > built to handle two-stage authentication techniques such as what > you describe. My recommendation would be to use only a single > method. The multiple stages are a requirement of SRP. There's no getting around that. I can, however, collapse this down to a single type, and I think I probably should. The new Request/Response type would have a discriminator octet at the beginning of the payload, and use these values: 1 - Part 1 of authentication 2 - Part 2 3 - M2 transmittal This also fixes the oddly-modified EAP Success message. > My recommendation is to add an additional round-trip to the protocol > and use the RFC 2284-defined EAP Success message. As much as I > would love to fix RFC 2284 to permit this usage, I think > that this would also require addressing the lack of ACKs for > Success and Failure messages, which would create a backward > compatiblity problem, so I can't see a way to make this work. Agreed. Many thanks for the comments! -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp-outgoing@merit.edu Wed Apr 11 21:27:09 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 91C955DFA3; Wed, 11 Apr 2001 21:15:59 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id C31B15E037 for ; Wed, 11 Apr 2001 21:07:07 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id SAA60028; Wed, 11 Apr 2001 18:01:15 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 11 Apr 2001 18:01:15 -0700 (PDT) From: Bernard Aboba To: James Carlson Cc: ietf-ppp@merit.edu, aboba@internaut.com Subject: Re: Comments on draft-ietf-pppext-eap-srp-01.txt In-Reply-To: <15060.56039.730030.353116@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > A much bigger benefit of SRP is that it's highly resistant to > dictionary-based attacks, and none of the alternatives (including > MS-CHAPv2) are. Yes, that is it's major advantage. That is particularly important in wireless applications, I think. > The new Request/Response type would have a > discriminator octet at the beginning of the payload, and use these > values: > > 1 - Part 1 of authentication > 2 - Part 2 > 3 - M2 transmittal > > This also fixes the oddly-modified EAP Success message. This seems like a reasonable way of going about it. > Many thanks for the comments! You're welcome. I think that EAP-SRP should be on the Standards Track. Is that the plan? From owner-ietf-ppp-outgoing@merit.edu Wed Apr 11 21:28:07 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DA0485DEDA; Wed, 11 Apr 2001 21:24:07 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 339FF5DE86 for ; Wed, 11 Apr 2001 21:12:07 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA19903; Wed, 11 Apr 2001 18:10:29 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA17136; Wed, 11 Apr 2001 21:12:00 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f3C1Cd237432; Wed, 11 Apr 2001 21:12:39 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15061.262.487694.984731@gargle.gargle.HOWL> Date: Wed, 11 Apr 2001 21:12:38 -0400 (EDT) From: James Carlson To: Bernard Aboba Cc: ietf-ppp@merit.edu Subject: Re: Comments on draft-ietf-pppext-eap-srp-01.txt In-Reply-To: Bernard Aboba's message of 11 April 2001 18:01:15 References: <15060.56039.730030.353116@gargle.gargle.HOWL> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Bernard Aboba writes: > > A much bigger benefit of SRP is that it's highly resistant to > > dictionary-based attacks, and none of the alternatives (including > > MS-CHAPv2) are. > > Yes, that is it's major advantage. That is particularly important in > wireless applications, I think. In fact, one of the folks who contacted me off-list is involved in LAN-type wireless effort, so I think that's a fair guess. (My interest was in tunneling, but the issues are somewhat similar.) > > Many thanks for the comments! > > You're welcome. I think that EAP-SRP should be on the Standards Track. Is > that the plan? Yes. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp-outgoing@merit.edu Wed Apr 11 23:39:42 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 41EF75DEA2; Wed, 11 Apr 2001 23:39:42 -0400 (EDT) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by segue.merit.edu (Postfix) with ESMTP id D5FBE5DE75 for ; Wed, 11 Apr 2001 23:39:06 -0400 (EDT) Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id UAA24879; Wed, 11 Apr 2001 20:38:56 -0700 (PDT) Message-Id: <200104120338.UAA24879@red.juniper.net> X-Mailer: exmh version 2.0.2 2/24/98 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox To: brucet@cisco.com (Bruce A Thompson) Cc: Ali Irfan-FIA225 , "'ietf-ppp@merit.edu'" , Pazhyannur Rajesh-QA6283 Subject: Re: Comments: ppp-over-aal2 In-reply-to: Your message of "30 Mar 1901 19:57:19 GMT." <4.3.1.0.20010330115255.01d6de98@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 11 Apr 2001 20:38:56 -0700 From: Dennis Ferguson Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Bruce, I don't get around to reading this list very often, but I wanted to comment on this since no one else did. > >Section 4, para 2: Is the limitation of 1500 bytes MRU for CRC-16 a > >hard-limit? Is this necessary? The MRU probably depends on the > >error-characteristics of the link. Probably leave it as an exercise to the > >configurator to determine the appropriate MRU for a link using CRC-16. The > >same comment carries over to the last sentence in Section 8. > > I think you may be right about the 1500 byte CRC being incorrect. We put > the 1500 byte MRU in because I thought that this was the maximum payload > size that a CRC-16 could protect. From talking to people more knowledgeable > than I about CRC's, I understood that in general a CRC of X bits can > protect for errors in a payload of up to 2**X bits. I assume this formula > is for single bit errors. I'm sure this is not correct. The CRC-16 will protect against all errors in a frame with a burst length (i.e. the number of bits between the first bit in the frame in error and the last bit in error) of 16 bits or less. A single bit error in a frame has a burst length of 1 bit, so single bit errors will always be detected independent of frame length. Note that the standard CRC-16 also has the feature (misfeature in some contexts) that it detects all errors where an odd number of bits in the packet have errors. 1 is an odd number of bits so, again, all single bit errors in a frame will always be detected. This all is a consequence of the fact that the CRC computation is a modulus operation on the packet data, which means that undetectable errors will be even (polynomial) multiples of the (prime) CRC polynomial. Since the CRC-16 polynomial is 17 bits long it has no even multiples (i.e. undetectable error patterns) which are less than 17 bits long. Since the standard CRC-16 polynomial has an even number of terms, it has no even multiples with an odd number of terms. > Now that I run the numbers though, it looks like 2**16 bits comes > to a protected payload size of 8K bytes instead of 1500 bytes. So the > 1500 byte MRU is incorrect based on the formula above. I don't get what you mean by "protected". Note that it is possible for a 1 byte packet (i.e. an N+1 byte frame when the N-byte FCS is added) to have an error which can't be detected by the CRC-16, or by the CRC-32 for that matter. With an n-bit FCS, random burst errors greater than n-bits long will only be detected statistically, with a probability of 1/2^n, so all frames that are longer than the FCS itself can have undetectable errors. Given this, I can't figure out how there could be any magic frame length, below which a packet is "protected" and above which it isn't. I do understand that the probability that any particular packet will have an undetected error is (p * 1/2^n), where p is the probability that a frame has at least two bits in error separated by more than n bits, and that theoretical models which consider bit errors to occur independently and randomly to individual bits will have p increasing at a greater-than-linear rate with increasing frame length, but (1) the increase is continuous, i.e. there is no magic frame length where this suddenly goes from being ok to really bad, and (2) the assumption of independent bit errors doesn't necessarily match reality, there are a lot of ways data circuits can screw up causing errors to occur in bursts which leave you solely at the mercy of the (1/2^n) error detection probability of the FCS independent of frame length. > I think we should base Max MRU in this draft on the CRC length. > Above a certain payload size, CRC become ineffective. I'm not sure > though what formula we should be using for CRC length to max payload > length. Do you have better info on the relationship between CRC > length and payload protection again errors? I'm not sure the formula you want exists. I think that the choice of FCS length is far less a function of maximum frame size than it is of the expected error rate on the circuit, the nature of those errors, and your (very subjective) risk tolerance for undetected errors in the frames you receive. At a high error rates you may wish you limited your MRU even when the 32-bit FCS is in use, while at very low error rates it hardly matters which FCS you choose no matter what your MRU. Dennis Ferguson From owner-ietf-ppp-outgoing@merit.edu Thu Apr 12 05:07:24 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 72FEE5DEDB; Thu, 12 Apr 2001 05:07:24 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 1070B5DDC3; Thu, 12 Apr 2001 05:07:21 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3C82o820109; Thu, 12 Apr 2001 11:02:50 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 12 Apr 2001 11:02:00 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 12 Apr 2001 11:01:58 +0300 Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E625AD@treis03nok> From: henry.haverinen@nokia.com To: ietf-ppp@merit.edu, aboba@internaut.com, aaa-wg@merit.edu Subject: RE: Comments on draft-ietf-pppext-eap-srp-01.txt Date: Thu, 12 Apr 2001 11:01:54 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: ext Bernard Aboba [mailto:aboba@internaut.com] > In other words, according to RFC 2284, an EAP Success packet MUST > NOT contain a type field or data. This is a result of the lack of > ACK'ing, as described above. Given that EAP Success messages > conforming to RFC 2284 do not contain data, existing implementations > will typically not pass anything contained beyond the length field > to the EAP method. There are also NAS devices that will not forward > such packets on to the client. > > My recommendation is to add an additional round-trip to the protocol > and use the RFC 2284-defined EAP Success message. As much as I > would love to fix RFC 2284 to permit this usage, I think > that this would also require addressing the lack of ACKs for > Success and Failure messages, which would create a backward > compatiblity problem, so I can't see a way to make this work. I guess this additional round-trip means that the last EAP-Response the client sends doesn't contain any actual data but it is just an acknowledgement. Could we avoid the additional NAS-AAA-NAS round-trip by making the AAA server indicate success already in the AAA message that contains the last EAP-Request? For example, the AAA server could include an attribute that tells the NAS device "if you recognize this attribute, you can consider the authentication to be accepted". Hence, the NAS box could compose the EAP Success packet to the client itself after getting the last EAP-Response fron the client. If the NAS doesn't recognize the new attribute, then things will still work but an extra round-trip is required. So this fix would be backward compatible. Do you think this could work? It would be very nice to have some solution to avoid these extra roundtrips in EAP. Regards, Henry From owner-ietf-ppp-outgoing@merit.edu Thu Apr 12 05:29:26 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E8A135DE34; Thu, 12 Apr 2001 05:29:25 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id B3F135DDE0 for ; Thu, 12 Apr 2001 05:29:23 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3C9UB824781 for ; Thu, 12 Apr 2001 12:30:11 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 12 Apr 2001 12:29:20 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Thu, 12 Apr 2001 12:20:07 +0300 Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E625AF@treis03nok> From: henry.haverinen@nokia.com To: ietf-ppp@merit.edu Subject: WG opinion on draft-haverinen-pppext-eap-sim-01.txt? Date: Thu, 12 Apr 2001 12:20:01 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi all, I just submitted a new version of the eap-sim draft (draft-haverinen-pppext-eap-sim-01.txt), which is now available in the IETF directories. This version contains a couple of clarifications and editorial changes. We also have an implementation of the protocol up and running. I'd like to hear the working group's opinion on this submission. Do you think this could be a standards track document? Or, if there isn't enough interest for this to be a working group item, could the draft become an experimental RFC? Regards, Henry From owner-ietf-ppp-outgoing@merit.edu Thu Apr 12 07:06:49 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 58B2C5DE95; Thu, 12 Apr 2001 07:06:49 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id A87F15DE4E for ; Thu, 12 Apr 2001 07:06:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26145; Thu, 12 Apr 2001 07:06:46 -0400 (EDT) Message-Id: <200104121106.HAA26145@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-aodi-03.txt Date: Thu, 12 Apr 2001 07:06:46 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Always On Dynamic ISDN (AODI). Author(s) : M. Holdrege Filename : draft-ietf-pppext-aodi-03.txt Pages : 15 Date : 11-Apr-01 Always On/Dynamic ISDN (AO/DI) is a networking service that provides an always-available connection to TCP/IP-based services through a specific wide area connection. This service provides several advantages over current practices for dial-up access to Internet services. * For the end-user, there is no need to dial-up the service each time access is desired. * For the Internet service provider, it is possible to give the end-user a notification, such as the arrival of new mail. * For the Local Exchange Carrier, the switched circuit trunk utilization is more efficient. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-aodi-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-aodi-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-aodi-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010411124549.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-aodi-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-aodi-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010411124549.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Thu Apr 12 08:21:46 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AE4695DEC0; Thu, 12 Apr 2001 08:21:46 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id AF5B95DEBB; Thu, 12 Apr 2001 08:21:43 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA19398; Thu, 12 Apr 2001 05:19:50 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10013; Thu, 12 Apr 2001 08:21:39 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f3CCMJh38572; Thu, 12 Apr 2001 08:22:19 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15061.40442.922528.991370@gargle.gargle.HOWL> Date: Thu, 12 Apr 2001 08:22:18 -0400 (EDT) From: James Carlson To: henry.haverinen@nokia.com Cc: ietf-ppp@merit.edu, aboba@internaut.com, aaa-wg@merit.edu Subject: RE: Comments on draft-ietf-pppext-eap-srp-01.txt In-Reply-To: henry.haverinen@nokia.com's message of 12 April 2001 11:01:54 References: <6D1A8E7871B9D211B3B00008C7490AA504E625AD@treis03nok> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu henry.haverinen@nokia.com writes: > I guess this additional round-trip means that the last EAP-Response > the client sends doesn't contain any actual data but it is just > an acknowledgement. Yes. The last EAP Request would have the M2 value, and the last EAP Response would be empty. > Could we avoid the additional NAS-AAA-NAS round-trip by making the > AAA server indicate success already in the AAA message that contains > the last EAP-Request? One could reasonably assert that sending the last EAP Request (at least for EAP SRP SHA-1; where M2 is sent to the authenticatee) itself indicates success as far as the AAA system is concerned. Since I don't have a defined AAA usage (and the usage there has some interesting twists; such as the bother with the shared encryption key), I'm a little confused by the question. I don't see where there's an implication that the last empty EAP Response needs to go to a AAA server for any sort of validation. > For example, the AAA server could include an attribute that tells > the NAS device "if you recognize this attribute, you can consider > the authentication to be accepted". Hence, the NAS box could compose > the EAP Success packet to the client itself after getting the last > EAP-Response fron the client. I see no reason that can't be part of the definition of the AAA interface for this protocol, if one were defined. > If the NAS doesn't recognize the new attribute, then things will still > work but an extra round-trip is required. So this fix would be backward > compatible. > > Do you think this could work? It would be very nice to have some > solution to avoid these extra roundtrips in EAP. I'm not sure why the extra authentication messages are considered to be a problem, but the solution you've suggested makes sense to me. (That itself might not be a good thing .... ;-}) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp-outgoing@merit.edu Thu Apr 12 15:29:07 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4481E5DDB5; Thu, 12 Apr 2001 15:29:07 -0400 (EDT) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id 0768B5DD9D for ; Thu, 12 Apr 2001 15:29:06 -0400 (EDT) Received: from karl-w98l.xc.org (ai70-152.aiinet.com [38.195.70.152]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H75MR26S; Thu, 12 Apr 2001 13:29:04 -0600 Message-Id: <4.3.2.7.2.20010412152727.00c4a9b0@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Apr 2001 15:28:54 -0400 To: Thomas Narten , Erik Nordmark From: Karl Fox Subject: AODI to Informational Cc: ietf-ppp@merit.edu, Steve Coya Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thomas and Erik, The PPPEXT Working Group recommends that Always On Dynamic ISDN (AODI), draft-ietf-pppext-aodi-03.txt, be advanced to Informational. Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Thu Apr 12 15:37:11 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6AB925DF6E; Thu, 12 Apr 2001 15:37:10 -0400 (EDT) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id 03CA25DF56 for ; Thu, 12 Apr 2001 15:34:43 -0400 (EDT) Received: from karl-w98l.xc.org (ai70-152.aiinet.com [38.195.70.152]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H75MR27B; Thu, 12 Apr 2001 13:34:41 -0600 Message-Id: <4.3.2.7.2.20010412153012.00c63950@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Apr 2001 15:34:30 -0400 To: ietf-ppp@merit.edu From: Karl Fox Subject: PPP over SONET with Virtual Concatenation - Working Group Last Call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is last call. I will advise the area directors that we want to take "Extending PPP over SONET/SDH, with virtual concatenation, high order and low order payloads" (draft-ietf-pppext-posvcholo-03.txt) to Proposed Standard on April 27 unless there is substantive comment raised on the list. Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Thu Apr 12 15:47:17 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D7F4B5DF98; Thu, 12 Apr 2001 15:47:16 -0400 (EDT) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id 8B8B75DF96 for ; Thu, 12 Apr 2001 15:47:15 -0400 (EDT) Received: from karl-w98l.xc.org (ai70-152.aiinet.com [38.195.70.152]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H75MR28F; Thu, 12 Apr 2001 13:47:14 -0600 Message-Id: <4.3.2.7.2.20010412154547.00cd6390@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Apr 2001 15:46:59 -0400 To: Thomas Narten , Erik Nordmark From: Karl Fox Subject: PPP Multiplexed to Proposed Standard Cc: ietf-ppp@merit.edu, Steve Coya Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thomas and Erik, The PPPEXT Working Group recommends that PPP Multiplexed (draft-ietf-pppext-pppmux-02.txt) be advanced to Proposed Standard. Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Sat Apr 14 18:50:36 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 908C85DDB8; Sat, 14 Apr 2001 18:50:36 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id B6F6A5DDB0 for ; Sat, 14 Apr 2001 18:50:34 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA18377; Sat, 14 Apr 2001 15:50:37 -0700 (PDT) Received: from tmima-w2k.cisco.com (tmima-dsl4.cisco.com [144.254.211.45]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AFL02068; Sat, 14 Apr 2001 15:50:30 -0700 (PDT) Message-Id: <4.3.2.7.2.20010414154552.032127d0@mira-sjcm-2.cisco.com> X-Sender: tmima@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 14 Apr 2001 15:50:32 -0700 To: Karl Fox , Bruce A Thompson , Ali Irfan-FIA225 From: Tmima Koren Subject: RE: Comments: ppp-over-aal2 Cc: "'ietf-ppp@merit.edu'" , Pazhyannur Rajesh-QA6283 In-Reply-To: <4.3.2.7.2.20010405112220.046cdda0@mail.via-net.net> References: <4.3.1.0.20010330115255.01d6de98@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 11:32 AM 4/5/2001 -0400, Karl Fox wrote: >At 03:57 PM 3/30/01, Bruce A Thompson wrote: > >>At 03:38 PM 03/29/2001 -0600, Ali Irfan-FIA225 wrote: > >>Section 8: Should mention that PPP LCP FCS-alternatives extensions is > >>described in RFC1570. (Any reason for using option values 32 and 64 and not > >>8 and 16 for 8-bit CRC and 16-bit CRC? Is there a specific name to the > 8 and > >>16 bit CRCs described in the draft? > > > > From the last meeting, we decided to get rid of CRC-8. This will get > rid of much of the complexity described in the draft. It also means that > there will be no negotiation for CRC via LCP. This section will now just > say that CRCs cannot be negotiated via LCP and that only CRC-16 is supported. > >There's no need to do that. Simply say that CRC-16 is the default FCS. If >someone wants to implement RFC 1570, then let them. Those who don't will >just reject the option. > > >>Section 8, last sentence: See first comments. Also Is the following > >>statement from RFC2364 applicable here: > >> > >>The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a > >> larger size than the maximum CPCS-SDU size specified in the > >> associated direction for the virtual connection's traffic contract. > > > >The SSSAR function does not have any maximum payload defined for it. We > should define the maximum payload based on CRC length from comments above. > >Better yet, ignore all the discussion about CRC length and payload length >and just define the default packet size and default CRC type. That's what >other PPP encapsulation documents do. > > >>Bigger question on section 6.2: In previous email-trains, there was concern > >>that allowing multiple options for CRC based on length of payload causes > >>complexity and should be avoided; however, the current draft still has two > >>options CRC-8 and CRC-16 based on the length of the payload. The difference > >>is only one byte. In most cases, the smallest size payload including the > >>PPP-protocol id will be about 10 bytes. The difference between 8 and 16 bit > >>CRC is 10% and will be lower for smaller sized payloads. Can we not just > >>stick with the 16 bit CRC? > > > >That's what we decided in the last mtg. Note though the complexity is > optional since 8 bit CRC is negotiated. > >If an 8-bit FCS would be useful, you could always write an enhancement to >the FCS-Alternatives option described in RFC 1570. Thanks for the comments We'll include them in the next revision of the draft Tmima >Karl Fox >Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Fri Apr 27 14:29:56 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 33A235DE28; Fri, 27 Apr 2001 14:29:56 -0400 (EDT) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id BA83B5DE26 for ; Fri, 27 Apr 2001 14:29:54 -0400 (EDT) Received: from karl-w98l.xc.org (ai70-070.aiinet.com [38.195.70.70]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JB8STQQR; Fri, 27 Apr 2001 12:29:53 -0600 Message-Id: <4.3.2.7.2.20010427142556.04b66a30@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Apr 2001 14:29:39 -0400 To: Thomas Narten , Erik Nordmark From: Karl Fox Subject: PPP over SONET/SDH with Virtual Concatenation to Proposed Standard Cc: ietf-ppp@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thomas and Erik, The PPPEXT Working Group recommends that "Extending PPP over SONET/SDH, with virtual concatenation, high order and low order payloads" (draft-ietf-pppext-posvcholo-03.txt) be advanced to Proposed Standard. Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Mon Apr 30 17:14:08 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 06BBD5DDCA; Mon, 30 Apr 2001 17:14:08 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 8176B5DDA6 for ; Mon, 30 Apr 2001 17:14:06 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA11326; Mon, 30 Apr 2001 14:14:04 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25102; Mon, 30 Apr 2001 17:14:01 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f3ULEjn75926; Mon, 30 Apr 2001 17:14:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15085.54724.518874.898599@gargle.gargle.HOWL> Date: Mon, 30 Apr 2001 17:14:44 -0400 (EDT) From: James Carlson To: pppext Cc: tissa@force10networks.com, neena@force10networks.com Subject: POS flow control: draft-tsenevir-ppp-flow-00.txt X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Has anyone else looked at this individual submission? It is defining new LCP options to negotiate a SONET-and-802.3x specific flow control mechanism for PPP, plus a new control protocol to actually signal flow control. This doesn't sound like a good thing to me. Implementations are typically expected to buffer as much as practical for expected bursts (250ms+, usually), and to drop otherwise. Adding flow control in here makes a bad situation worse -- it pushes the buffering back into the network rather than in the hosts where it belongs, and presents TCP with more delay variance. It sounds like the result of a misunderstanding of how IP-based congestion control works. Is it possible that the original authors just need bigger buffers and/or RED? I know it's not a working group draft, but ... -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp-outgoing@merit.edu Mon Apr 30 20:15:56 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 149315E82B; Mon, 30 Apr 2001 19:35:11 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 238315E535 for ; Mon, 30 Apr 2001 19:08:55 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.3/8.11.3) id f3UN8rA12551 env-from ; Mon, 30 Apr 2001 17:08:53 -0600 (MDT) Date: Mon, 30 Apr 2001 17:08:53 -0600 (MDT) From: Vernon Schryver Message-Id: <200104302308.f3UN8rA12551@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: POS flow control: draft-tsenevir-ppp-flow-00.txt Cc: neena@force10networks.com, tissa@force10networks.com Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: James Carlson > To: pppext > Cc: tissa@force10networks.com, neena@force10networks.com > Has anyone else looked at this individual submission? yes, from the title and before reading it, I guessed it might be another aspect of the strange world of SONET. > It is defining new LCP options to negotiate a SONET-and-802.3x > specific flow control mechanism for PPP, plus a new control protocol > to actually signal flow control. > > This doesn't sound like a good thing to me. Implementations are > typically expected to buffer as much as practical for expected bursts > (250ms+, usually), and to drop otherwise. Adding flow control in here > makes a bad situation worse -- it pushes the buffering back into the > network rather than in the hosts where it belongs, and presents TCP > with more delay variance. It sounds like the result of a > misunderstanding of how IP-based congestion control works. > > Is it possible that the original authors just need bigger buffers > and/or RED? Yes, contrary to the thesis of the Internet Draft, dropping packets is a good thing and putting a flow controlling protocol such as TCP above a second flow controlling protocol like x.25 or this SONET proposal is a quite bad thing except in some special cases. The problem is that there is no way for link layer flow control to signal the real source of data, the distant TCP state machine. If one end of a link adds buffers, then the distant TCP state machine is supposed to put more data in flight and fill up the extra buffers. This desirable process is described in many textbooks and now in in various RFC's. The bad things that happen with too-smart-by-half link layers are evident if you run TCP/IP/PPP/{rlogin,telnet}/TCP/IP (say for testing). Similar bad things happen with necessarily smart link layers such as TCP/IP/wireless-modems, where the wireless links do retransmissions. There are Internet Drafts that discuss these issues in http://www.ietf.org/internet-drafts/draft-ietf-pilc-slow-05.txt http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-06.txt and http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-05.txt While the focus of those drafts is on very low speeds, the issues are not related to speed itself. The flow control in 802.3 networks referred to in the proposal involve another special case, and generally involve protocols other than TCP/IP and sometimes misunderstanding by link layer designers of overall network issues. > I know it's not a working group draft, but ... Doesn't the IESG supposed to listen to the relevant WGs when it comes to publishing a draft as an RFC? The danger with this draft is that unlike others, it is seems reasonable and plausible if you don't know about TCP versus smart link layers. Speaking of other kinds of I-D's, was I specially blessed by recently receiving a missive informing me personally and others of an unspecifed group that we "have the foundation for enumeration in the Binary System wrong" and that "the Foundation of the entire Mathematical Field is wrong too" and containing an encrypted (as a base64 .zip file) copy of an expired draft? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Mon Apr 30 23:42:59 2001 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 75E875E5B2; Mon, 30 Apr 2001 22:41:57 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 2706A5E497 for ; Mon, 30 Apr 2001 21:40:31 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.3/8.11.3) id f411eUg16501 env-from ; Mon, 30 Apr 2001 19:40:30 -0600 (MDT) Date: Mon, 30 Apr 2001 19:40:30 -0600 (MDT) From: Vernon Schryver Message-Id: <200105010140.f411eUg16501@calcite.rhyolite.com> To: ietf-ppp@merit.edu, tissa@force10networks.com Subject: RE: POS flow control: draft-tsenevir-ppp-flow-00.txt reply to Ver non Cc: neena@force10networks.com Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Tissa Senevirathne > To: "'Vernon Schryver'" , ietf-ppp@merit.edu > Cc: neena@force10networks.com, tissa@force10networks.com > This is similar to flow control like XON/XOFF. Do you think it was bad for > original designers to have XON/XOFF. XON/XOFF dates from at least mechanical teletypes ("tty's") as a mechanism to start and stop a remote paper tape reader. In its realm it was the only and clearly necessary and appropriate flow control mechanism. IP applications already have a flow control mechanism in the form of TCP and various UDP mechanisms. Consider when and why XON/XOFF or RTS/CTS flow control is useful with PPP over modems. When the PPP link is connected to a host that is a TCP endpoint, the TCP state machine can notice when the local PPP/modem transmit queue is too full and stop the application. That does not apply to any router, including one with a SONET link. On the other hand, if a router drops a packet, a distant TCP sender will notice and stop sending so much. If any of the protocols or applications used above PPP needed help with flow control, would the reliable link form of PPP defined in RFC 1663 be dead and forgotten? If something other than just dropping packets that don't fit in queues were good for PPP, wouldn't we be doing that for modems? What is different about SONET except speed? > Please also see the reply to James. > What is your opinion on Ethernet PAUSE frames. Do you think that is not > useful and affects IP flows ? TCP/IP reacts badly to link layers that delay data. TCP/IP wants to know about congestion on any link or connection among links. To tell TCP about congestion in a link, you must signal it to the distant hosts that have the TCP state machines. You can do that by setting bits in IP or TCP headers (for an example, look for "ECN"), sending new kinds of packets (look for "ICMP source quench") or by deleting packets entirely. There is no fourth possiblity. A link layer that adds buffering or retransmits is failing to tell TCP about congestion, and that is usually a bad thing. Yes, if the congestion is very short term, TCP does not need to know, but the easiest way to do that is to do what network hardware has done since before TCP, Ethernet, and even the ARPANet, and that is to have a FIFO (or other kind of) quiet buffer. I don't know anything about Ethernet PAUSE frames, and given history including 100VG-AnyLAN 802.12, I'm afraid to learn. Maybe Ethernet PAUSE frames are good things that restore the link layer flow control lost with so called "switches" (really multi-port bridges) and then with FDX. The TCP state machines in hosts connected to classic Ethernet could notice when the wire was too full (i.e. collisions) and stop pushing more data. Switches and FDX broke that and can cause TCP retransmissions, but only when for hosts connected directly to the Ethernet. Does your proposal involve hosts or routers with SONET links? Vernon Schryver vjs@rhyolite.com