home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-radius-tunnel-auth-02.txt < prev    next >
Text File  |  1997-08-05  |  20KB  |  563 lines
  1.  
  2.  
  3.  
  4.  
  5. Network Working Group                                            G. Zorn
  6. Internet-Draft                                     Microsoft Corporation
  7. Updates: RFC 2058, RFC 2059                                    D. Leifer
  8. Category: Standards Track                          Ascend Communications
  9. <draft-ietf-radius-tunnel-auth-02.txt>                      John Shriver
  10.                                                        Shiva Corporation
  11.                                                                July 1997
  12.  
  13.  
  14.  
  15.  
  16.              RADIUS Attributes for Tunnel Protocol Support
  17.  
  18.  
  19.  
  20. 11..  Status of this Memo
  21.  
  22. This  document  is an Internet-Draft.  Internet-Drafts are working docu-
  23. ments of the Internet Engineering Task Force (IETF), its areas, and  its
  24. working groups.  Note that other groups may also distribute working doc-
  25. uments as Internet-Drafts.
  26.  
  27. Internet-Drafts are draft documents valid for a maximum  of  six  months
  28. and  may  be  updated,  replaced, or obsoleted by other documents at any
  29. time.  It is inappropriate to use Internet-Drafts as reference  material
  30. or to cite them other than as work in progress.''
  31.  
  32. To  learn  the  current  status  of any Internet-Draft, please check the
  33. ``1id-abstracts.txt'' listing contained in  the  Internet-Drafts  Shadow
  34. Directories  on ds.internic.net (US East Coast), nic.nordu.net (Europe),
  35. ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  36.  
  37. The distribution of this memo is unlimited.  It is filed as <draft-ietf-
  38. radius-tunnel-auth-02.txt>,  and  expires February 1, 1997.  Please send
  39. comments to the RADIUS  Working  Group  mailing  list  (ietf-radius@liv-
  40. ingston.com)  or  to  the  authors  (liefer@del.com,  jas@shiva.com  and
  41. glennz@microsoft.com).
  42.  
  43.  
  44. 22..  Abstract
  45.  
  46. This document defines a set of RADIUS attributes designed to support the
  47. provision   of   compulsory   tunneling  in  dial-up  networks.   RADIUS
  48. attributes for both authorization and accounting are specified.
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56. Zorn, Leifer & Shriver                                          [Page 1]
  57.  
  58. INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997
  59.  
  60.  
  61. 33..  Motivation
  62.  
  63. Many applications of tunneling protocols such as PPTP and  L2TP  involve
  64. dial-up network access.  Some, such as the provision of secure access to
  65. corporate intranets via the Internet,  are  characterized  by  voluntary
  66. tunneling:  the  tunnel is created at the request of the user for a spe-
  67. cific purpose.  Other applications  involve  compulsory  tunneling:  the
  68. tunnel  is created without any action from the user and without allowing
  69. the user any choice in the matter.  Examples of applications that  might
  70. be  implemented  using  compulsory tunnels are Internet software upgrade
  71. servers, software registration servers and banking services.  These  are
  72. all services which, without compulsory tunneling, would probably be pro-
  73. vided using dedicated networks or  at  least  dedicated  network  access
  74. servers  (NAS),  since  they are characterized by the need to limit user
  75. access to specific hosts.  Given the existence of widespread support for
  76. compulsory tunneling, however, these types of services could be accessed
  77. via any Internet service provider (ISP).   The  most  popular  means  of
  78. authorizing dial-up network users today is through the RADIUS  protocol.
  79. The use of RADIUS allows the dial-up users' authorization and  authenti-
  80. cation  data to be maintained in a central location, rather than on each
  81. NAS.  It makes sense to use RADIUS to  centrally  administer  compulsory
  82. tunneling,  since  RADIUS  is  widely deployed and was designed to carry
  83. this type of information.  In order to provide this  functionality,  new
  84. RADIUS attributes are needed to carry the tunneling information from the
  85. RADIUS server to the NAS and to transfer accounting data from the NAS to
  86. the  RADIUS  accounting  server; this document defines those attributes.
  87. Specific recommendations for, and examples of, the application of  these
  88. attributes  for  the L2TP and PPTP protocols can be found in draft-ietf-
  89. radius-tunnel-imp-XX.txt.
  90.  
  91.  
  92.  
  93.  
  94. 44..  Specification of Requirements
  95.  
  96. In this document, several words are used to signify the requirements  of
  97. the specification.  These words are often capitalized.
  98.  
  99.    MUST      This word, or the adjective "required", means that the
  100.              definition is an absolute requirement of the specification.
  101.  
  102.    MUST NOT  This phrase means that the definition is an absolute
  103.              prohibition of the specification.
  104.  
  105.    SHOULD    This word, or the adjective "recommended", means that there
  106.              may exist valid reasons in particular circumstances to
  107.              ignore this item, but the full implications must be
  108.              understood and carefully weighed before choosing a
  109.  
  110.  
  111.  
  112. Zorn, Leifer & Shriver                                          [Page 2]
  113.  
  114. INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997
  115.  
  116.  
  117.              different course.
  118.  
  119.    SHOULD NOT
  120.              This phrase means that there may exist valid reasons in par-
  121.              ticular circumstances when the particular behavior is
  122.              acceptable or even useful, but the full implications should
  123.              be understood and the case carefully weighed before imple-
  124.              menting any behavior described with this label.
  125.  
  126.    MAY       This word, or the adjective "optional", means that this
  127.              item is one of an allowed set of alternatives.  An
  128.              implementation which does not include this option MUST be
  129.              prepared to interoperate with another implementation which
  130.              does include the option.
  131.  
  132.  
  133. 55..  Attributes
  134.  
  135. Multiple  instances  of  each  of  the  attributes  defined below may be
  136. included in a single RADIUS packet.  In this case, the attributes to  be
  137. applied  to  any given tunnel SHOULD all contain the same value in their
  138. respective Tag fields.
  139.  
  140.  
  141. 55..11..  Tunnel-Type
  142.  
  143.    Description
  144.  
  145.       This Attribute indicates the tunneling protocol(s) to be used.  It
  146.       MAY  be  included in Access-Request, Access-Accept and Accounting-
  147.       Request packets.  If the Tunnel-Type Attribute is  present  in  an
  148.       Access-Request  packet, it SHOULD be taken as a hint to the RADIUS
  149.       server as to the tunnelling protocols supported by  the  NAS;  the
  150.       RADIUS server MAY ignore the hint, however.  A NAS is not required
  151.       to implement any of these tunnel  types;  if  a  NAS  receives  an
  152.       Access-Accept  packet  which  contains only unknown or unsupported
  153.       Tunnel-Types, the NAS MUST behave as though an  Access-Reject  had
  154.       been received instead.
  155.  
  156.    A  summary  of  the Tunnel-Type Attribute format is shown below.  The
  157.    fields are transmitted from left to right.
  158.  
  159.     0                   1                   2                   3
  160.     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
  161.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  162.    |     Type      |    Length     |     Tag       |     Value
  163.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  164.               Value (cont)         |
  165.  
  166.  
  167.  
  168. Zorn, Leifer & Shriver                                          [Page 3]
  169.  
  170. INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997
  171.  
  172.  
  173.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  174.  
  175.    Type
  176.  
  177.       64 for Tunnel-Type
  178.  
  179.    Length
  180.  
  181.       Always 6.
  182.  
  183.    Tag
  184.  
  185.       The Tag field is one octet in length and is intended to provide  a
  186.       means of grouping attributes in the same packet which refer to the
  187.       same tunnel.  If the Tag field is unused, it MUST be zero.
  188.  
  189.    Value
  190.  
  191.       The Value field is three octets and contains one of the  following
  192.       values, indicating the type of tunnel to be started.
  193.  
  194.        1      Point-to-Point Tunneling Protocol (PPTP)
  195.        2      Layer Two Forwarding (L2F)
  196.        3      Layer Two Tunneling Protocol (L2TP)
  197.        4      Ascend Tunnel Management Protocol (ATMP)
  198.        5      Virtual Tunneling Protocol (VTP)
  199.        6      IP Authentication Header in the Tunnel-mode (AH)
  200.        7      IP-in-IP Encapsulation (IP-IP)
  201.        8      Minimal IP-in-IP Encapsulation (MIN-IP-IP)
  202.        9      IP Encapsulating Security Payload in the Tunnel-mode (ESP)
  203.        10     Generic Route Encapsulation (GRE)
  204.        11     Bay Dial Virtual Services (DVS)
  205.  
  206.  
  207. 55..22..  Tunnel-Medium-Type
  208.  
  209.    Description
  210.  
  211.       The  Tunnel-Medium-Type Attribute indicates which transport medium
  212.       to use when creating a tunnel for those protocols (such  as  L2TP)
  213.       that  can operate over multiple transports.  It MAY be included in
  214.       both Access-Request and Access-Accept packets; if it is present in
  215.       an  Access-Request  packet,  it  SHOULD  be taken as a hint to the
  216.       RADIUS server as to the tunnel mediums supported by the NAS.   The
  217.       RADIUS server MAY ignore the hint, however.
  218.  
  219.    A  summary of the Tunnel-Medium-Type Attribute format is given below.
  220.    The fields are transmitted left to right.
  221.  
  222.  
  223.  
  224. Zorn, Leifer & Shriver                                          [Page 4]
  225.  
  226. INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997
  227.  
  228.  
  229.     0                   1                   2                   3
  230.     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
  231.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  232.    |     Type      |    Length     |      Tag      |    Value      |
  233.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  234.               Value (cont)         |
  235.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  236.  
  237.    Type
  238.  
  239.       65 for Tunnel-Medium-Type
  240.  
  241.    Length
  242.  
  243.       6
  244.  
  245.    Tag
  246.  
  247.       The Tag field is one octet in length and is intended to provide  a
  248.       means of grouping attributes in the same packet which refer to the
  249.       same tunnel.  If  the  Tag  field  is  unused,  it  MUST  be  zero
  250.       (0x0000).
  251.  
  252.    Value
  253.  
  254.       The  Value  field is three octets nd contains one of the following
  255.       values:
  256.  
  257.        1      IP
  258.        2      X.25
  259.        3      ATM
  260.        4      Frame Relay
  261.  
  262.  
  263. 55..33..  Acct-Tunnel-Client-Endpoint
  264.  
  265.    Description
  266.  
  267.       This Attribute contains the address of the NAS end of the  tunnel.
  268.       It  SHOULD be included in Accounting-Request packets which contain
  269.       Acct-Status-Type attributes with values of either Start  or  Stop.
  270.       This  Attribute,  along  with the Tunnel-Server-Endpoint and Acct-
  271.       Tunnel-Connection-ID attributes, may be used to provide a globally
  272.       unique means to identify a tunnel for accounting and auditing pur-
  273.       poses.
  274.  
  275.    A summary of  the  Acct-Tunnel-Client-Endpoint  Attribute  format  is
  276.    shown below.  The fields are transmitted from left to right.
  277.  
  278.  
  279.  
  280. Zorn, Leifer & Shriver                                          [Page 5]
  281.  
  282. INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997
  283.  
  284.  
  285.     0                   1                   2                   3
  286.     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
  287.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  288.    |     Type      |    Length     |           String ...
  289.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  290.  
  291.    Type
  292.  
  293.       66 for Acct-Tunnel-Client-Endpoint.
  294.  
  295.    Length
  296.  
  297.       >= 2
  298.  
  299.    String
  300.       The  format of the address represented by the String field depends
  301.       upon the value of the Tunnel-Medium-Type attribute.
  302.  
  303.       If Tunnel-Medium-Type is IP (1), then this string  is  either  the
  304.       fully  qualified  domain  name,  or  it  is  a "dotted-decimal" IP
  305.       address.
  306.  
  307.       If Tunnel-Medium-Type is X.25 (2), ATM (3), or  Frame  Relay  (4),
  308.       this  string is a tag referring to configuration data local to the
  309.       RADIUS client that describes  the  interface  and  medium-specific
  310.       address to use.
  311.  
  312.  
  313. 55..44..  Tunnel-Server-Endpoint
  314.  
  315.    Description
  316.  
  317.       This Attribute indicates the address of the server end of the tun-
  318.       nel.  The Tunnel-Server-Endpoint Attribute MAY be included  (as  a
  319.       hint  to  the RADIUS server) in the Access-Request packet and MUST
  320.       be included in the Access-Accept packet if  the  initiation  of  a
  321.       tunnel  is  desired.   It SHOULD be included in Accounting-Request
  322.       packets which contain Acct-Status-Type attributes with  values  of
  323.       either  Start  or  Stop  and  which pertain to a tunneled session.
  324.       This Attribute,  along  with  the  Acc-Tunnel-Client-Endpoint  and
  325.       Acct-Tunnel-Connection-ID  attributes,  may  be  used to provide a
  326.       globally unique means to identify  a  tunnel  for  accounting  and
  327.       auditing purposes.
  328.  
  329.    A  summary  of  the  Tunnel-Server-Endpoint Attribute format is shown
  330.    below.  The fields are transmitted from left to right.
  331.  
  332.     0                   1                   2                   3
  333.  
  334.  
  335.  
  336. Zorn, Leifer & Shriver                                          [Page 6]
  337.  
  338. INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997
  339.  
  340.  
  341.     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
  342.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  343.    |     Type      |    Length     |     Tag       |   String ...
  344.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  345.  
  346.    Type
  347.  
  348.       67 for Tunnel-Server-Endpoint.
  349.  
  350.    Length
  351.  
  352.       >= 3
  353.  
  354.    Tag
  355.  
  356.       The Tag field is one octet in length and is intended to provide  a
  357.       means of grouping attributes in the same packet which refer to the
  358.       same tunnel.  If  the  Tag  field  is  unused,  it  MUST  be  zero
  359.       (0x0000).
  360.  
  361.    String
  362.       The  format of the address represented by the String field depends
  363.       upon the value of the Tunnel-Medium-Type attribute.
  364.  
  365.       If Tunnel-Medium-Type is IP (1), then this string  is  either  the
  366.       fully  qualified  domain  name,  or  it  is  a "dotted-decimal" IP
  367.       address.
  368.  
  369.       If Tunnel-Medium-Type is X.25 (2), ATM (3), or  Frame  Relay  (4),
  370.       this  string is a tag referring to configuration data local to the
  371.       RADIUS client that describes  the  interface  and  medium-specific
  372.       address to use.
  373.  
  374.  
  375. 55..55..  Acct-Tunnel-Connection
  376.  
  377.    Description
  378.  
  379.       This  Attribute indicates the identifier assigned to the call.  It
  380.       SHOULD be included in  Accounting-Request  packets  which  contain
  381.       Acct-Status-Type  attributes  with values of either Start or Stop.
  382.       This attribute, along  with  the  Acct-Tunnel-Client-Endpoint  and
  383.       Tunnel-Server-Endpoint  attributes, may be used to provide a glob-
  384.       ally unique means to identify a call for accounting  and  auditing
  385.       purposes.
  386.  
  387.    A  summary  of  the  Acct-Tunnel-Connection Attribute format is shown
  388.    below.  The fields are transmitted from left to right.
  389.  
  390.  
  391.  
  392. Zorn, Leifer & Shriver                                          [Page 7]
  393.  
  394. INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997
  395.  
  396.  
  397.     0                   1                   2                   3
  398.     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
  399.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  400.    |     Type      |    Length     |            String ...
  401.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  402.  
  403.    Type
  404.  
  405.       68 for Acct-Tunnel-Connection
  406.  
  407.    Length
  408.  
  409.       >= 2
  410.  
  411.    String
  412.       The format of the  identifier  represented  by  the  String  field
  413.       depends upon the value of the Tunnel-Type attribute.
  414.  
  415.  
  416. 55..66..  Tunnel-Private-Group-ID
  417.  
  418.    Description
  419.  
  420.       This  Attribute  indicates  the group ID for a particular tunneled
  421.       session.  The Tunnel-Private-Group-ID Attribute MAY be included in
  422.       the  Access-Request  packet if the NAS can pre-determine the group
  423.       resulting from a particular connection and SHOULD be  included  in
  424.       the Access-Reply packet if this tunnel session is to be treated as
  425.       belonging to a particular private group.  Private  groups  may  be
  426.       used  to  associate  a tunneled session with a particular group of
  427.       users.  For example, it may  be  used  to  facilitate  routing  of
  428.       unregistered  IP  addresses  through  a  particular interface.  It
  429.       SHOULD be included in  Accounting-Request  packets  which  contain
  430.       Acct-Status-Type  attributes  with  values of either Start or Stop
  431.       and which pertain to a tunneled session.
  432.  
  433.  
  434.    A summary of the Tunnel-Private-Group-ID Attribute  format  is  shown
  435.    below.  The fields are transmitted from left to right.
  436.  
  437.     0                   1                   2                   3
  438.     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
  439.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  440.    |     Type      |    Length     |     Tag       |   String ...
  441.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  442.  
  443.    Type
  444.  
  445.  
  446.  
  447.  
  448. Zorn, Leifer & Shriver                                          [Page 8]
  449.  
  450. INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997
  451.  
  452.  
  453.       ?? for Tunnel-Private-Group-ID.
  454.  
  455.    Length
  456.  
  457.       >= 3
  458.  
  459.    Tag
  460.  
  461.       The  Tag field is one octet in length and is intended to provide a
  462.       means of grouping attributes in the same packet which refer to the
  463.       same  tunnel.   If  the  Tag  field  is  unused,  it  MUST be zero
  464.       (0x0000).
  465.  
  466.    String
  467.       This field must be present.   The  group  is  represented  by  the
  468.       String field.  There is no restriction on the format of group IDs.
  469.  
  470.  
  471. 66..  Table of Attributes
  472.  
  473. The following table provides a guide to which of  the  above  attributes
  474. may be found in which kinds of packets, and in what quantity.
  475.  
  476.    Request Accept Reject Challenge Acct-Request #  Attribute
  477.    0+      0+     0      0         0-1          64 Tunnel-Type
  478.    0+      0+     0      0         0-1          65 Tunnel-Medium-Type
  479.    0       0      0      0         0-1          66 Acct-Tunnel-Client-Endpoint
  480.    0+      0+     0      0         0-1          67 Tunnel-Server-Endpoint
  481.    0       0      0      0         0-1          68 Acct-Tunnel-Connection
  482.    0+      0+     0      0         0-1          ?? Tunnel-Private-Group-ID
  483.  
  484. The following table defines the meaning of the above table entries.
  485.  
  486.    0     This attribute MUST NOT be present in packet.
  487.    0+    Zero or more instances of this attribute MAY be present in packet.
  488.    0-1   Zero or one instance of this attribute MAY be present in packet.
  489.  
  490.  
  491. 77..  Security Considerations
  492.  
  493. None (submissions welcome).
  494.  
  495.  
  496. 88..  Acknowledgements
  497.  
  498. Thanks  (in  no  particular  order)  to  Kory  Hamzeh (kory@ascend.com),
  499. Bertrand Buclin (Bertrand.Buclin@att.ch), Dave  Mitton  (dmitton@baynet-
  500. works.com),    Andy    Valencia   (vandys@cisco.com),   Bill   Westfield
  501.  
  502.  
  503.  
  504. Zorn, Leifer & Shriver                                          [Page 9]
  505.  
  506. INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997
  507.  
  508.  
  509. (billw@cisco.com), Kris Michielsen (kmichiel@cisco.com),  Gurdeep  Singh
  510. Pall  (gurdeep@microsoft.com),  Ran  Atkinson (rja@home.net) and Bernard
  511. Aboba (aboba@internaut.com) for salient input and review.
  512.  
  513.  
  514. 99..  Chair's Address
  515.  
  516. The RAQDIUS Working Group can be contacted via the current chair:
  517.  
  518.    Carl Rigney
  519.    Livingston Enterprises
  520.    6920 Koll Center Parkway, Suite 220
  521.    Pleasanton, California  94566
  522.  
  523.    Phone: +1 510 426 0770
  524.    E-Mail: cdr@livingston.com
  525.  
  526.  
  527. 1100..  Author's Address
  528.  
  529. Questions about this memo can also be directed to:
  530.  
  531.    Glen Zorn
  532.    Microsoft Corporation
  533.    One Microsoft Way
  534.    Redmond, Washington 98052
  535.  
  536.    Phone:  +1 206 703 1559
  537.    E-Mail: glennz@microsoft.com
  538.  
  539.  
  540.    Dory Leifer
  541.    Ascend Communications
  542.    1678 Broadway
  543.    Ann Arbor, MI 48105
  544.  
  545.    Phone:  +1 313 747 6152
  546.    E-Mail: leifer@ascend.com
  547.  
  548.  
  549.   John Shriver
  550.   Shiva Corporation
  551.   28 Crosby Drive
  552.   Bedford, MA  01730
  553.  
  554.   Phone:  +1 617 270 8329
  555.   E-Mail: jas@shiva.com
  556.  
  557.  
  558.  
  559.  
  560. Zorn, Leifer & Shriver                                         [Page 10]
  561.  
  562.  
  563.