home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / pppext / pppext-minutes-95apr.txt < prev    next >
Text File  |  1995-05-26  |  12KB  |  269 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Fred Baker/cisco Systems
  5.  
  6. Minutes of the Point-to-Point Protocol Extensions Working Group (PPPEXT)
  7.  
  8.  
  9. Encryption Control Protocol -- Gerry Meyer
  10.  
  11. draft-ietf-pppext-encryption-03.txt
  12.  
  13. The ECP document was returned to the working group by the IESG for the
  14. following changes:
  15.  
  16.  
  17.    o Clarify some text.
  18.  
  19.    o Provide a means in addition to the use of IEEE 802 OUIs for
  20.      vendor-specific encryption technologies (through IANA).
  21.  
  22.    o Specify a encryption technology that most vendors will supply.
  23.  
  24.  
  25. Keith Sklower will write a draft describing DES Cipher Block Chaining
  26. Encryption.  Default:  ECP implementations should implement DES Cipher
  27. Block Chaining Encryption.  If encryption requested and not successfully
  28. negotiated, the implementation should take down the connection as in the
  29. authentication specification.
  30.  
  31.  
  32. ECP/CCP Patent Status Report -- Steve Coya
  33.  
  34. draft-ietf-pppext-encryption-03.txt
  35. draft-ietf-pppext-compression-04.txt with related procedure definition
  36. drafts
  37.  
  38. The IESG has received a letter of intent from the Vice President of
  39. Technology at Motorola Codex to provide ``fair, reasonable, and
  40. non-discriminatory'' licensing of its patent claims.  There is
  41. considerable sense in the working group that specific prior art can be
  42. cited for the technology in question, but the procedures specified in
  43. RFC 1602 require the IETF to wait for that letter before publishing the
  44. documents, quite apart from the validity of the claims.
  45.  
  46.  
  47. Multilink Procedures RFC 1717 -- Keith Sklower
  48.  
  49. The group considered the result of an interoperability test of the
  50. Multilink Procedure.
  51.  
  52. Clarification appears to be required concerning the meaning of
  53. ``Protocol ID Compression.''  Implementors please note that when one
  54. system indicates a willingness to receive PID compressed messages, there
  55. is no obligation imposed on the sender to send them.  The fact that the
  56. CCP presumes the negotiation of PID compressed messages in the payload
  57. therefore does not imply that the first octet of the message cannot be
  58. zero:  an IP datagram might start with 0x21 or with 0x00-21.
  59.  
  60. The group discussed the use of Endpoint Identifiers.  Some implementors
  61. chose to assume that any multilink implementation would implement EIDs,
  62. and did not operate correctly without them; others made the same
  63. assumption about Authentication.  Major interoperation problems occurred
  64. between the two implementation types.  Some means of identifying that
  65. two lines should or should not be in the same bundled is required, but
  66. either mechanism is a reasonable choice.  It was decided to add a usage
  67. note identifying the dilemma, and indicating that EIDs should always be
  68. ACKed on a configure request even if the other system does not use them,
  69. much as synchronous implementations ACK ACCM. Also, a new EID type will
  70. be generated which is only used in NAKs when requesting that the other
  71. end identify itself; this is the only valid value in a NAK (request for
  72. EID of peer).  Implementations should note that a valid response to such
  73. a request is the NULL EID.
  74.  
  75. Implementations also had problems when they assumed that one system was
  76. always the authenticator and the other the authenticated system.
  77. Implementors please note:  either system or both may choose to
  78. authenticate the other.
  79.  
  80. A problem arose in managing the number of connections open between two
  81. systems; systems often each took down a line simultaneously, and then
  82. simultaneously tried to bring up a line when they detected the total
  83. loss of connectivity.
  84.  
  85. Generally, it should be the responsibility of the guy who brings up a
  86. link to take it down.  Note, however, that there are cases when the
  87. called party validly takes the call down, or the call fails.
  88.  
  89. An advisable procedure is that when there is more than one link open and
  90. a system takes one down, it should hold it down for a random period of
  91. time.
  92.  
  93. Scott Wasson and Keith Sklower took action items to collaborate in
  94. developing a call management protocol.  This may either be an NCP (8xxx)
  95. or a control protocol (Cxxx).  The purpose of this protocol is to:
  96. Negotiate maximum number of channels open Negotiate bringing up new
  97. channel or taking one down.  When negotiating, Multilink implementations
  98. must negotiate MRRU, and may negotiate SSNHF.
  99.  
  100. Keith changed default MRU to 1500, for consistency with other
  101. procedures.  Note that negotiating MRU = MRRU + Multilink Header Size is
  102. advisable for any protocols that one really does not want fragmented.
  103.  
  104. The packet loss procedure is too restrictive; Keith will improve the
  105. description and add examples.  Implementations should discard message
  106. fragments that can be determined to be up to or including portion of
  107. frame lost.
  108.  
  109. The group chose to forbid asymmetric bundling of links.
  110.  
  111.  
  112. Extensible Authentication Protocol -- Larry Blunk
  113.  
  114. ftp://merit.edu/pub/ppp/eap-draft.txt
  115.  
  116. Larry made a general presentation of his Extensible Authentication
  117. Protocol.  There was some discussion of this, but mostly for clarity of
  118. understanding.
  119.  
  120. It was decided that the MD5 Challenge procedure would be a default
  121. algorithm, as the password is not sent in the clear, and implementation
  122. code is unencumbered and not very onerous.
  123.  
  124. It was also decided that an RSA and an ISO 9798-3 extension should be
  125. written; Todd Palgut agreed to write them.
  126.  
  127. There was widely-held feeling that one did not need versions with a
  128. password, clear text to be echoed, and clear text to not be echoed.
  129. Echoing is a local display option, to be left to the user interface.
  130. The recommendation was to reduce this to one of the above, and use that
  131. for both simple password and one time password procedures.
  132. Implementations should note, however, that simple password procedures
  133. are insecure and very much not recommended.
  134.  
  135.  
  136. Public Key Authentication Proposal -- Badari Narayana
  137.  
  138. ftp://ftp.cisco.com/fred/draft-ietf-pppext-public-key-00.txt
  139.  
  140. Fred Baker presented the draft in the absence of Badari Narayana.
  141. Novell here is developing an RSA Public Key approach; unfortunately, the
  142. draft does not point this out, and does not identify the control
  143. protocol used to achieve this.  For this reason, an interoperable
  144. authentication procedure cannot be implemented.  Further, concern was
  145. expressed by members of the security community that had read the draft
  146. that it did not in fact describe a public key approach, but rather a
  147. shared secret approach that perhaps uses RSA software to scramble its
  148. messages.
  149.  
  150. The consensus is that the draft is either poorly worded or fundamentally
  151. incorrect; in either case, it requires a great deal of work to be
  152. useful.
  153.  
  154.  
  155. IP Control Protocol -- Glenn McGregor and Gurdeep Singh Pall
  156.  
  157. draft-ietf-pppext-ipcp-00.txt
  158.  
  159. Fred Baker presented this draft in the absence of its authors.
  160. This draft has as its fundamental objective taking the IPCP from
  161. Proposed Standard status to Draft Standard.  IPCP was originally written
  162. as RFC 1172 in 1990, and cycled at Proposed Standard when updated (1992)
  163. as RFC 1332.  With upwards of 20 mature, interoperable implementations,
  164. it seems that the protocol should be able to become something we
  165. consider stable and ready for widespread implementation.
  166.  
  167. The effects of this update are:
  168.  
  169. The Type 1 IP Address option (defined in RFC 1772 and deprecated in
  170. 1332) was removed.
  171.  
  172. The Type 2 IP-Compression-Protocol option (which is capable of selecting
  173. the use of Van Jacobson header compression) remains unchanged.
  174.  
  175. The Standard and Van Jacobson header compression data messages remain
  176. unchanged.
  177.  
  178. The Type 3 IP-Address Option (Type 3) has been used in practice in
  179. describing unnumbered links, and there was an attempt to normalize the
  180. procedures having to do with this.  The normalization contains two
  181. errors, which the authors are to correct in an updated draft.
  182.  
  183. When the IPCP announces an address (``I am using address a.b.c.d as my
  184. source address on this link''), there are four possible responses
  185. defined in the draft:
  186.  
  187.  
  188.      Ack:  ``OK, you are that address''
  189.      Nak with address:  ``No, use this one''
  190.      Nak with 0.0.0.0:  ``I consider this an unnumbered link''
  191.      Reject:  ``huh?''
  192.  
  193.  
  194. Nak with 0.0.0.0 is not a useful response.  If the system is considering
  195. the link an unnumbered interface, then it does not care what address the
  196. peer uses.  It should treat the announcement as interesting but
  197. superfluous information, and Acknowledge it.
  198.  
  199. When the IPCP requests an address assignment (announcement of the
  200. invalid address 0.0.0.0), the draft defines two possible responses:
  201.  
  202.  
  203.      Ack with 0.0.0.0:  ``I consider this an unnumbered link''
  204.      Nak with address:  ``use this one''
  205.  
  206.  
  207. There is an additional possible response:
  208.  
  209.  
  210.      Reject:  ``I am not prepared to assign an address''
  211.  
  212.  
  213. Ack with 0.0.0.0 is not a useful response; it signals to the other end
  214. acceptance of the address it has chosen, which is an address the
  215. RFC 1716 and the current Router Requirements draft preclude in the
  216. section describing ``Martian Filters.''  If the requester has asked for
  217. an address assignment, it is very probably because he needs one.  The
  218. better response would be to reject the option, leaving the requester
  219. with the decision to either terminate IPCP (done when operation in the
  220. absence of an address is impossible or not implemented - for example, in
  221. an end system) or to treat the interface as an unnumbered interface and
  222. use its Router ID. In the latter case, the system rejecting the option
  223. may be presumed to not care.
  224.  
  225. An additional case should be noted:  if the receiver of an IPCP
  226. Configure Request needs to know the address of its peer and the address
  227. is not announced, it should Nak with the address 0.0.0.0.  The next
  228. Configure Request can be expected to either not have the Type 3
  229. IP-Address option (the peer did not implement it) or to contain an
  230. announcement of a valid address.  In the latter case, it should be
  231. Acknowledged.
  232.  
  233. The draft defines a new option, Type 4, the IP-Broadcast-Forwarding
  234. Option.  This is designed to provide a configuration negotiation for
  235. legacy applications (such as NETBIOS/IP) which use the directed
  236. broadcast rather than IP Multicast.  Some of them, notably NETBIOS, can
  237. be very noisy, and it would be nice to be able to dynamically reduce the
  238. server or router's configuration from sending those to not forwarding
  239. them when no application using them is active.
  240.  
  241. The option should not, in the collective opinion of the working group,
  242. be expected to increase what the peer will forward; if a system requests
  243. forwarding of subnet-directed broadcasts and network-directed
  244. broadcasts, and the peer is only prepared to forward subnet-directed
  245. broadcasts (which would probably be consistent with RFC 1716's
  246. discussion of the forwarding algorithm), one would expect the peer to
  247. Nak the option indicating the subset of the request it is prepared to
  248. honor.
  249.  
  250. The option specifies a Bit Mask indicating the broadcast types requested
  251. or approved.  A request for several types of broadcasts is indicated by
  252. the sum of their flag values:
  253.  
  254.  
  255.                 00  No Broadcast forwarding (default)
  256.                 01  IP Broadcast forwarding
  257.                 02  IP Network Broadcast forwarding
  258.                 04  IP Sub-Network Broadcast forwarding
  259.  
  260.  
  261. The consensus was that, since the IETF Process Definition RFC indicates
  262. that advancing a document to Draft Standard requires several
  263. interoperable implementations of each part, the presence of this option
  264. is inconsistent with the objective of advancement to Draft Standard.
  265. The authors are therefore directed to create a separate IPCP Extensions
  266. draft containing this option, permitting the remainder of the IPCP to
  267. advance.
  268.  
  269.