home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-pppext-callback-ds-01.txt < prev    next >
Text File  |  1997-07-30  |  10KB  |  330 lines
  1. Network Working Group                                         W. Simpson
  2. Internet Draft                                                DayDreamer
  3. expires in six months                                          July 1997
  4.  
  5.  
  6.                             PPP LCP CallBack
  7.                   draft-ietf-pppext-callback-ds-01.txt
  8.  
  9.  
  10. Status of this Memo
  11.  
  12.    Distribution of this memo is unlimited.
  13.  
  14.    This document is an Internet-Draft.  Internet Drafts are working doc-
  15.    uments of the Internet Engineering Task Force (IETF), its Areas, and
  16.    its Working Groups.  Note that other groups may also distribute work-
  17.    ing documents as Internet Drafts.
  18.  
  19.    Internet Drafts are draft documents valid for a maximum of six
  20.    months, and may be updated, replaced, or obsoleted by other documents
  21.    at any time.  It is not appropriate to use Internet Drafts as refer-
  22.    ence material, or to cite them other than as a ``working draft'' or
  23.    ``work in progress.''
  24.  
  25.    To learn the current status of any Internet-Draft, please check the
  26.    ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
  27.    Directories on:
  28.  
  29.       ftp.is.co.za (Africa)
  30.       nic.nordu.net (Europe)
  31.       ds.internic.net (US East Coast)
  32.       ftp.isi.edu (US West Coast)
  33.       munnari.oz.au (Pacific Rim)
  34.  
  35.  
  36. Abstract
  37.  
  38.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  39.    transporting multi-protocol datagrams over point-to-point links.  PPP
  40.    defines an extensible Link Control Protocol (LCP) for establishing,
  41.    configuring, and testing the data-link connection.  This document
  42.    defines the CallBack option.
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52. Simpson                   expires in six months                 [Page i]
  53. DRAFT                         PPP CallBack                     July 1997
  54.  
  55.  
  56. 1.  Introduction
  57.  
  58.    CallBack is a facility that permits a call originating party (caller)
  59.    to request that the call terminating party (callee) originate a sub-
  60.    sequent call in the reverse direction.  This might be used for many
  61.    diverse purposes, such as savings on toll charges.
  62.  
  63.    Unlike most PPP operations, CallBack is not a strictly peer-to-peer
  64.    service.  The semantics of CallBack differ depending on which peers
  65.    are the caller and callee.
  66.  
  67.    The successful operation of CallBack requires a significant amount of
  68.    administrative configuration.  Such configuration might include per-
  69.    mission to use the CallBack facility, locations and time of day for
  70.    which the CallBack is allowed, and time delays prior to and following
  71.    disconnection.
  72.  
  73.    -  The callee might disconnect quickly, and return the call as soon
  74.       as possible.
  75.  
  76.    -  CallBack might be used to re-establish service at later time, when
  77.       sufficient additional traffic arrives at the callee to warrant
  78.       another connection.
  79.  
  80.    -  When the user is roaming, CallBack might be used to register a
  81.       variable contact location.
  82.  
  83.    Such policy considerations are beyond the scope of this specifica-
  84.    tion.
  85.  
  86.  
  87. 2.  Additional LCP Configuration Options
  88.  
  89.    The Configuration Option format and basic options are already defined
  90.    for LCP [1].
  91.  
  92.    Up-to-date values of the LCP Option Type field are specified in the
  93.    most recent "Assigned Numbers" [2].  This document concerns the fol-
  94.    lowing values:
  95.  
  96.       13      CallBack
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107. Simpson                   expires in six months                 [Page 1]
  108. DRAFT                         PPP CallBack                     July 1997
  109.  
  110.  
  111. 2.1.  CallBack
  112.  
  113.    Description
  114.  
  115.       This Configuration Option provides a method for an implementation
  116.       to request a dial-up peer to call back.  By default, no call back
  117.       occurs.
  118.  
  119.       Nota Bene:
  120.  
  121.          Like all such PPP options, this indicates that the installation
  122.          has the capability to be called back.  If the option is
  123.          rejected, link operation continues normally [1 page 39].
  124.  
  125.          Moreover, acknowlegement of the option does not require that
  126.          the peer take any additional action [ibid].
  127.  
  128.       A peer that Configure-Acks this option SHOULD Configure-Request
  129.       the Authentication-Protocol option.  The user information learned
  130.       during authentication can be used to determine the user location,
  131.       or limit a user to certain locations, or merely to determine whom
  132.       to bill for the service.
  133.  
  134.       When CallBack is successfully negotiated, and the Authentication
  135.       phase is complete, the peer will eventually enter the Link Termi-
  136.       nation phase.  At the conclusion of the Link Termination phase,
  137.       the peer will disconnect the link.
  138.  
  139.       Then, after a suitable interval of time, the peer will re-
  140.       establish the link.  When mutual authentication is desired, the
  141.       implementation SHOULD Configure-Request the Authentication-
  142.       Protocol option as it answers the call.
  143.  
  144.       Implementation Notes:
  145.  
  146.          The delay times between calls are characteristics of the call-
  147.          ing environment, and MUST be configured on a per user and loca-
  148.          tion basis.
  149.  
  150.          Since the information is redundant, the implementation is not
  151.          required to Configure-Request the CallBack option as it answers
  152.          the call.  However, inclusion MUST NOT affect the operation of
  153.          the protocol.
  154.  
  155.    A summary of the CallBack Option format is shown below.  The fields
  156.    are transmitted from left to right.
  157.  
  158.  
  159.  
  160.  
  161.  
  162. Simpson                   expires in six months                 [Page 2]
  163. DRAFT                         PPP CallBack                     July 1997
  164.  
  165.  
  166.     0                   1                   2                   3
  167.     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
  168.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  169.    |     Type      |    Length     |   Operation   |  Message ...
  170.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  171.  
  172.    Type
  173.  
  174.       13
  175.  
  176.    Length
  177.  
  178.       >= 3
  179.  
  180.    Operation
  181.  
  182.       The Operation field is one octet and indicates the contents of the
  183.       Message field.
  184.  
  185.       Up-to-date values of the CallBack Operation field are specified in
  186.       the most recent "Assigned Numbers" [2].  This document defines the
  187.       following values:
  188.  
  189.       0       Identification from the Authentication phase will be used
  190.               for a database lookup to determine the callback parame-
  191.               ters.  The Message field is not present.
  192.  
  193.               This method is required to be supported in all conformant
  194.               implementations.
  195.  
  196.       1       Dialing string, the format and contents of which assumes
  197.               configuration knowledge of the specific device that is
  198.               making the callback.
  199.  
  200.               A North American example might be: 10222,,,(800)555-1212.
  201.  
  202.               This method is commonly supported, but suffers from fre-
  203.               quent configuration error.
  204.  
  205.       2       Location identifier, which may or may not be human read-
  206.               able, used together with Authentication phase information
  207.               for a database lookup to determine the callback parame-
  208.               ters.
  209.  
  210.       3       E.164 number.  The implementation converts this to an
  211.               appropriate signalling sequence.
  212.  
  213.  
  214.  
  215.  
  216.  
  217. Simpson                   expires in six months                 [Page 3]
  218. DRAFT                         PPP CallBack                     July 1997
  219.  
  220.  
  221.       4       X.500 distinguished name, used together with Authentica-
  222.               tion phase information for a database lookup to determine
  223.               the callback parameters.
  224.  
  225.       5       E.165 number.  The implementation converts this to an
  226.               appropriate signalling sequence.
  227.  
  228.    Message
  229.  
  230.       The Message field is zero or more octets, and its general contents
  231.       are determined by the Operation field.  The actual format of the
  232.       information is site or application specific, and a robust imple-
  233.       mentation SHOULD support the field as undistinguished octets.  The
  234.       size is determined from the Length field.
  235.  
  236.       It is intended that only an authorized user will have correct site
  237.       specific information to make use of the CallBack.  The codifica-
  238.       tion of the range of allowed usage of this field is beyond the
  239.       scope of this specification.
  240.  
  241.  
  242. Security Considerations
  243.  
  244.    Unauthenticated and unrestricted use of CallBack could lead to a sig-
  245.    nificant denial of service, or excessive service charges.  Authenti-
  246.    cation is required to be supported.  In addition, it is recommended
  247.    that an implementation be capable of logging usage.
  248.  
  249.  
  250. Acknowledgements
  251.  
  252.    Special thanks to Ascend Communications for providing computing
  253.    resources and network access support for writing this specification.
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272. Simpson                   expires in six months                 [Page 4]
  273. DRAFT                         PPP CallBack                     July 1997
  274.  
  275.  
  276. References
  277.  
  278.    [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
  279.          STD-51, RFC-1661, December 1993.
  280.  
  281.    [2]   Reynolds, J.K., Postel, J.B., "Assigned Numbers", RFC-1700,
  282.          July 1992.
  283.  
  284.    [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
  285.          Levels", BCP 14, Harvard University, March 1997.
  286.  
  287.  
  288.  
  289. Contacts
  290.  
  291.    Comments about this document should be discussed on the
  292.    ietf-ppp@merit.edu mailing list.
  293.  
  294.    This document is a submission to the Point-to-Point Protocol Working
  295.    Group of the Internet Engineering Task Force (IETF).  The working
  296.    group can be contacted via the current chair:
  297.  
  298.       Karl Fox
  299.       Ascend Communications
  300.       3518 Riverside Drive  Suite 101
  301.       Columbus, Ohio  43221
  302.  
  303.           karl@MorningStar.com
  304.           karl@Ascend.com
  305.  
  306.    Questions about this document can also be directed to:
  307.  
  308.       William Allen Simpson
  309.       DayDreamer
  310.       Computer Systems Consulting Services
  311.       1384 Fontaine
  312.       Madison Heights, Michigan  48071
  313.  
  314.           wsimpson@UMich.edu
  315.           wsimpson@GreenDragon.com (preferred)
  316.           bsimpson@MorningStar.com
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327. Simpson                   expires in six months                 [Page 5]
  328.  
  329.  
  330.