Re: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications

> On 11 Apr 2022, at 17:57, Mark Andrews <marka@isc.org> wrote:
> 
> I don’t see why APL (RFC 3123) can’t be used for CRC give you need to construct an
> owner name anyway and have well known label to seperate the components of the name.
> I see no reason to re-invent the wheel here.
> 
> ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24
> 
> would be
> 
> ftp.foo.com._21._crc.bar.com APL 1:195.13.35.0/24 1:91.220.43.0/24

Additionally text is a really bad way to transmit IP address and prefixes
in the DNS.  DNS RRsets are resource constrained (maximum < 64k).  DNS caches
are resource constrained.  10-16 octets of text for an IPv4/24 vs 7 octets for APL.
An IPv4/8 is 9-11 vs 5 octets.  The :: improves this a little bit for IPv6 but in
general you will be dealing with /48’s or longer xxxx:xxxx:xxxx::/48 (19 octets)
vs 10 for APL.

>> On 5 Apr 2022, at 20:52, Eugène Adell <eugene.adell@gmail.com> wrote:
>> 
>> Hello,
>> 
>> I've been working on two new RRTypes described by a Draft, and as
>> suggested by our magnificent, incredibly brilliant and handsome AD
>> Warren "ACE" Kumari, I am posting here this idea and the material I
>> have written so far (the draft itself, and RFC 6895 components).
>> 
>> Briefly, one RRType (CRC : Client Roaming Control) contains a
>> whitelist of networks allowing a company employees to connect to a
>> specific application. The second RRType (CRS : Client Roaming Support)
>> is on the application side and informs what kind of restrictions are
>> applied (by saying if CRC is mandatory, optional or ignored).
>> This is not expected to be deployed broadly and everywhere as it is
>> designed to secure Business-To-Business applications.
>> 
>> The material (text XML2RFC draft + RFC 6895 components) written is
>> both incorporated below to this email and attached, for practical
>> reasons.
>> 
>> 
>> Regards
>> E.A.
>> 
>> 
>> 
>> 
>> 
>> Internet Engineering Task Force                                 E. Adell
>> Internet-Draft                                              5 April 2022
>> Intended status: Informational
>> Expires: 7 October 2022
>> 
>> 
>>                        Client Roaming Control
>>                    draft-adell-client-roaming-00
>> 
>> Abstract
>> 
>>  This document specifies the Client Roaming Control (CRC) DNS Resource
>>  Record allowing an organization to better control the access to
>>  third-party applications over Internet.  The applications
>>  implementing an authorization mechanism to honor the CRC, publish on
>>  their side the Client Roaming Support (CRS) Resource Record to inform
>>  of this support.
>> 
>> Status of This Memo
>> 
>>  This Internet-Draft is submitted in full conformance with the
>>  provisions of BCP 78 and BCP 79.
>> 
>>  Internet-Drafts are working documents of the Internet Engineering
>>  Task Force (IETF).  Note that other groups may also distribute
>>  working documents as Internet-Drafts.  The list of current Internet-
>>  Drafts is at https://datatracker.ietf.org/drafts/current/.
>> 
>>  Internet-Drafts are draft documents valid for a maximum of six months
>>  and may be updated, replaced, or obsoleted by other documents at any
>>  time.  It is inappropriate to use Internet-Drafts as reference
>>  material or to cite them other than as "work in progress."
>> 
>>  This Internet-Draft will expire on 7 October 2022.
>> 
>> Copyright Notice
>> 
>>  Copyright (c) 2022 IETF Trust and the persons identified as the
>>  document authors.  All rights reserved.
>> 
>>  This document is subject to BCP 78 and the IETF Trust's Legal
>>  Provisions Relating to IETF Documents (https://trustee.ietf.org/
>>  license-info) in effect on the date of publication of this document.
>>  Please review these documents carefully, as they describe your rights
>>  and restrictions with respect to this document.  Code Components
>>  extracted from this document must include Revised BSD License text as
>>  described in Section 4.e of the Trust Legal Provisions and are
>>  provided without warranty as described in the Revised BSD License.
>> 
>> 
>> 
>> Adell                    Expires 7 October 2022                 [Page 1]
>> 
>> Internet-Draft           Client Roaming Control               April 2022
>> 
>> 
>> Table of Contents
>> 
>>  1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
>>  2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
>>  3.  The CRC Resource Record . . . . . . . . . . . . . . . . . . .   4
>>    3.1.  RR name field . . . . . . . . . . . . . . . . . . . . . .   4
>>    3.2.  CRC RDATA Wire Format . . . . . . . . . . . . . . . . . .   4
>>    3.3.  CRC Presentation Format . . . . . . . . . . . . . . . . .   4
>>  4.  The CRS Resource Record . . . . . . . . . . . . . . . . . . .   5
>>    4.1.  CRS RDATA Wire Format . . . . . . . . . . . . . . . . . .   5
>>    4.2.  CRS Presentation Format . . . . . . . . . . . . . . . . .   5
>>  5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
>>    5.1.  Restricted Application  . . . . . . . . . . . . . . . . .   6
>>    5.2.  Controlled Application  . . . . . . . . . . . . . . . . .   7
>>    5.3.  Opened Application  . . . . . . . . . . . . . . . . . . .   8
>>  6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
>>  7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
>>    7.1.  DNS misconfiguration  . . . . . . . . . . . . . . . . . .   9
>>    7.2.  DNS Security  . . . . . . . . . . . . . . . . . . . . . .  10
>>    7.3.  Application Security  . . . . . . . . . . . . . . . . . .  10
>>  8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
>>    8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
>>    8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
>>  Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11
>> 
>> 1.  Introduction
>> 
>>  Illegitimate access to professional restricted applications over
>>  Internet is a permanent threat for organizations and their staff.
>>  Different methods can be used to impersonate a user access, and in
>>  some cases an organization also wants to better prevent its own staff
>>  to access a third-party application from a network which is not under
>>  its control.  On the contrary, an organization maybe wants to allow
>>  roaming then its users can access from different known places.
>> 
>>  The Client Roaming Control (CRC) DNS Resource Record (RR) acts as a
>>  White-List and informs a compatible application from which networks
>>  its users are allowed to connect, be it a limited list of networks or
>>  broadly without any restriction.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Adell                    Expires 7 October 2022                 [Page 2]
>> 
>> Internet-Draft           Client Roaming Control               April 2022
>> 
>> 
>>  At the application level, the identification of the user's
>>  organization domain can be based on an information carried during the
>>  authentication process, or a lookup on an information already known
>>  by the application.  In both cases this information lets the
>>  application relate the user to its organization unequivocally.
>>  Finally, the corresponding user's domain DNS will be requested with
>>  the application's FQDN and port, and the application will know
>>  whether an authorization is expected or not.  Some examples will be
>>  given in this document.
>> 
>>  The applications implementing this authorization control let the
>>  client organizations know this feature is available by using the
>>  Client Roaming Support (CRS) RR.  The data associated with this
>>  record indicates if the client's organization expected support of the
>>  CRC is mandatory, optional, or ignored.  This information stored in
>>  the CRS can be confirmed at the application level by a redundant
>>  data.  The way the application handles the authorization mechanism,
>>  by consulting the associated CRS record or not, is left to the
>>  implementor.
>> 
>>  Although this mechanism is designed for improving the security
>>  between different organizations, there is no objection to use it for
>>  a same organization playing both roles of client and application , as
>>  an alternative or additional layer to a solution already in place,
>>  such as a firewall for example.
>> 
>> 2.  Conventions Used in This Document
>> 
>>  This specification uses definitions from Domain Name System
>>  [RFC1035], and readers unfamiliar with it can also check DNS
>>  Terminology [RFC8499].  The syntax specification uses the Augmented
>>  Backus-Naur Form (ABNF) notation as specified in [RFC5234], with some
>>  expressions being defined in "Uniform Resource Identifier (URI):
>>  Generic Syntax" [RFC3986] and "IP Version 6 Addressing Architecture"
>>  [RFC4291].
>> 
>>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>  "OPTIONAL" in this document are to be interpreted as described in BCP
>>  14 [RFC2119] [RFC8174] when, and only when, they appear in all
>>  capitals, as shown here.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Adell                    Expires 7 October 2022                 [Page 3]
>> 
>> Internet-Draft           Client Roaming Control               April 2022
>> 
>> 
>> 3.  The CRC Resource Record
>> 
>>  The CRC RR purpose is to provide a list of IP ranges authorized to
>>  use a particular application.  Each RR contains a list of either IPv4
>>  or IPv6 network address ranges.  These ranges MUST follow the CIDR
>>  notation.  A single CRC RR MAY contain ranges for different IP
>>  versions, but in the case of many ranges this can be difficult to
>>  read or maintain, so dedicating a record to each IP version or not is
>>  left to the administrator.  Multiple RRs MAY be defined for a given
>>  IP version.
>> 
>> 3.1.  RR name field
>> 
>>  The CRC RR name field is composed of the third-party application
>>  domain, its port, followed by the fully qualified name inherent in
>>  this zone.  These three components are separated by the underscore
>>  character.
>> 
>> 3.2.  CRC RDATA Wire Format
>> 
>>  The CRC RDATA wire format is encoded as follows:
>> 
>>      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>>      /                     CRC                       /
>>      /                                               /
>>      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>> 
>>  The CRC field contains a list of either IPv4 or IPv6 ranges separated
>>  by the comma character.
>> 
>> 3.3.  CRC Presentation Format
>> 
>>  The presentation format of the CRC record is:
>> 
>>  CRC (ip4netlist [,ip6netlist]) / ([ip4netlist,] ip6netlist)
>> 
>>  ip4netlist = ip4net *(,ip4net)
>> 
>>  ip4net = IPv4address "/" ip4range
>> 
>>  ip4range = DIGIT / "1" DIGIT / "2" DIGIT / "3" DIGIT %x30-32
>> 
>>  ip6netlist = ip6net *(,ip6net)
>> 
>>  ip6net = (ipv6-address "/" prefix-length)
>> 
>> 
>> 
>> 
>> 
>> 
>> Adell                    Expires 7 October 2022                 [Page 4]
>> 
>> Internet-Draft           Client Roaming Control               April 2022
>> 
>> 
>> 4.  The CRS Resource Record
>> 
>>  The CRS RR indicates which control is done on the client
>>  organizations, and thus which ones are authorized.  A requirement
>>  field is used for this purpose, it has one of the following values
>>  meaning when the checking is performed :
>> 
>>  *  "N" : Never, all organizations are authorized
>> 
>>  *  "A" : Always, only organizations with a CRC are authorized
>> 
>>  *  "O" : Optional, any organization CRC is honored, other
>>     organizations are authorized
>> 
>>  In addition to this value, an optional list of ports can be given.
>>  Indeed, multiple applications can be hosted on different ports under
>>  the same domain name, and an equivalent support was described for the
>>  CRC RR.  In case of different requirement values, it is RECOMMENDED
>>  to have one dedicated RR for each although one single RR with all the
>>  information is supported.  One particular port MUST NOT appear in
>>  more than one RR.  When no port is mentioned, only one RR MAY be
>>  declared and its requirement value covers all applications for this
>>  domain name.
>> 
>>  In the absence of such record, no roaming control is to be expected
>>  by the client, any of its CRC RRs will be ignored.  It is equivalent
>>  to a CRS requirement value indicating no control is performed.
>> 
>> 4.1.  CRS RDATA Wire Format
>> 
>>  The CRS RDATA wire format is encoded as follows:
>> 
>>      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>>      /                     CRS                       /
>>      /                                               /
>>      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>> 
>>  The CRS field contains a list of requirements followed by their
>>  respective optional ports.
>> 
>> 4.2.  CRS Presentation Format
>> 
>>  The presentation format of the CRS record is:
>> 
>>  CRS (single-rule / multiple-rules)
>> 
>>  single-rule = "R=" ("N" / "A" / "O") *(,port)
>> 
>> 
>> 
>> 
>> Adell                    Expires 7 October 2022                 [Page 5]
>> 
>> Internet-Draft           Client Roaming Control               April 2022
>> 
>> 
>>  multiple-rules = unit-rule 1*2(;unit-rule)
>> 
>>  unit-rule = "R=" ("N" / "A" / "O") 1*(,port)
>> 
>>  port = [1-9] *([DIGIT])
>> 
>> 5.  Examples
>> 
>>  The following examples show some typical uses expected from this
>>  documentation.  Particularly, the intended behaviors for different
>>  CRC and CRS values are explained, while the user identification is
>>  done directly through carried data or a deduction process.
>> 
>> 5.1.  Restricted Application
>> 
>>  In this example, an application is only opened to organizations
>>  publishing their respective allowed networks.  The requirement value
>>  of the CRS record equals "A", and any organization with an empty or
>>  missing CRC for this application will be denied access.
>> 
>>  The ftp.foo.com domain is dedicated to hosting an FTP application,
>>  which extracts the client's domain from the username used during the
>>  authentication process.  This information is then used for requesting
>>  the client CRC record and finally comparing its content with the
>>  client's IP.  The client organization bar.com allows its users from
>>  its own network 195.13.35.0/24 and from a cloud service located at
>>  91.220.43.0/24.  A second organization baz.com has no CRC record and
>>  its users are rejected.
>> 
>>  Application FQDN : ftp.foo.com
>>  Application CRS record : CRS R=A,21
>> 
>>  Client FQDN : bar.com
>>  Client organization CRC record : CRC
>>  ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24
>> 
>>  Client FQDN : baz.com
>>  No client organization CRC record
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Adell                    Expires 7 October 2022                 [Page 6]
>> 
>> Internet-Draft           Client Roaming Control               April 2022
>> 
>> 
>>  Client DNS  Client FTP                Server FTP
>> 
>>                    FTP USER me@bar.com
>>              ----------------------------->
>>                           ...
>>                    FTP PASS ********
>>              ----------------------------->
>>         Query : CRC ftp.foo.com_21_bar.com
>>       <------------------------------------
>>         Answer : CRC ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24
>>       ------------------------------------>
>>                    FTP 230
>>             <------------------------------
>> 
>> 
>>                    FTP USER me@baz.com
>>              ----------------------------->
>>                           ...
>>                    FTP PASS ********
>>              ----------------------------->
>>         Query : CRC ftp.foo.com_21_baz.com
>>       <------------------------------------
>>         Answer : No such name (3)
>>       ------------------------------------>
>>                    FTP 430
>>             <------------------------------
>> 
>> 5.2.  Controlled Application
>> 
>>  The foo.com domain hosts a Web application on port 443 using client
>>  certificates for authenticating its users.  The application extracts
>>  the client domains from the certificates, which are used to retrieve
>>  their CRC records.  Users from the bar.com organization are allowed
>>  only if they connect from an authorized network listed in the CRC
>>  record, while users from baz.com are always granted access since this
>>  one has no CRC declared.
>> 
>>  Application FQDN : foo.com
>>  Application CRS record : CRS R=A,443
>> 
>>  Client FQDN : bar.com
>>  Client organization CRC record : CRC
>>  ftp.foo.com_443_bar.com,195.13.35.0/24,91.220.43.0/24
>> 
>>  Client FQDN : baz.com
>>  No client organization CRC record
>> 
>> 
>> 
>> 
>> 
>> Adell                    Expires 7 October 2022                 [Page 7]
>> 
>> Internet-Draft           Client Roaming Control               April 2022
>> 
>> 
>>  Client DNS  Client browser                Web application
>> 
>> 
>>                            .....
>>                Client certificate me@bar.com
>>              ----------------------------------->
>>         Query : CRC foo.com_443_bar.com
>>       <------------------------------------------
>>         Answer : CRC foo.com_443_bar.com,195.13.35.0/24,91.220.43.0/24
>>       ------------------------------------------>
>>                            .....
>>                    200 OK
>>              <-----------------------------------
>> 
>> 
>>                            .....
>>                Client certificate me@baz.com
>>              ----------------------------------->
>>         Query : CRC foo.com_443_baz.com
>>       <------------------------------------------
>>         Answer : No such name (3)
>>       ------------------------------------------>
>>                            .....
>>                    200 OK
>>              <-----------------------------------
>> 
>> 5.3.  Opened Application
>> 
>>  A company is testing the CRC and CRS behaviors before opening a new
>>  service to its customers.  Its first test described below consists in
>>  configuring both sides to be completely opened, likely before
>>  hardening the CRS, then the CRC, and testing again.
>> 
>>  The application.foo.com domain hosts a Web application on port 443
>>  where users are logged in by sending a numerical identifier and a
>>  password.  The application uses a dictionary data type to identify
>>  the user's domain.  The client.foo.com domain is temporarily using 2
>>  CRC records indicating a free access from anywhere.
>> 
>>  Application FQDN : application.foo.com
>>  Application CRS record : CRS R=N,443
>> 
>>  Client FQDN : client.foo.com
>>  Client organization CRC records : CRC
>>  application.foo.com_443_foo.com,0.0.0.0/24; CRC
>>  application.foo.com_443_foo.com,fe80::/10
>> 
>> 
>> 
>> 
>> 
>> Adell                    Expires 7 October 2022                 [Page 8]
>> 
>> Internet-Draft           Client Roaming Control               April 2022
>> 
>> 
>>  Client DNS  Client browser                Web application
>> 
>> 
>>                            .....
>>                HTTP POST 123456/******
>>              ----------------------------------->
>>                    200 OK
>>              <-----------------------------------
>> 
>> 6.  IANA Considerations
>> 
>>  According to Guidelines for Writing an IANA Considerations Section in
>>  RFCs [RFC8126] it is asked to IANA to add into the Resource Record
>>  (RR) TYPEs registry located at https://www.iana.org/assignments/dns-
>>  parameters/dns-parameters.xhtml#dns-parameters-4 the two entries CRC
>>  and CRS.
>> 
>>          +------+-------+------------------------+-----------+
>>          | TYPE | Value | Description            | Reference |
>>          +------+-------+------------------------+-----------+
>>          | CRC  | TBD1  | Client Roaming Control | this RFC  |
>>          +------+-------+------------------------+-----------+
>>          | CRS  | TBD2  | Client Roaming Support | this RFC  |
>>          +------+-------+------------------------+-----------+
>> 
>>                                 Table 1
>> 
>> 7.  Security Considerations
>> 
>>  This section is meant to inform developers and users of the security
>>  implications of the CRC/CRS mechanism described by this document.
>>  While the CRS RR mostly plays an informative role, the CRC RR
>>  delivers important data which requires attention from the developers
>>  and administrators.  Some particular points are discussed here.
>> 
>> 7.1.  DNS misconfiguration
>> 
>>  Any DNS CRS misconfiguration such as multiple records with different
>>  requirement values but with the same port value can get a client
>>  confused.  In this case the client does not know without testing the
>>  actual configuration, if its organization is protected against
>>  roaming, and contacting the application administrator to fix the
>>  situation is a possibility.
>> 
>>  While CRC misconfigurations are more or less leading to serious
>>  security problems, administrators need to pay attention when dealing
>>  with multiple networks or records.  Particularly, multiple records
>>  for the same network range or overlapping networks should be avoided.
>> 
>> 
>> 
>> Adell                    Expires 7 October 2022                 [Page 9]
>> 
>> Internet-Draft           Client Roaming Control               April 2022
>> 
>> 
>> 7.2.  DNS Security
>> 
>>  Client and application administrators need to pay as much attention
>>  as they usually do when dealing with DNS management.  As the CRC
>>  records are supposed to be requested during an application
>>  authentication process, reflection attacks could be built to target a
>>  client organization, even one not hosting any CRC record at all.
>>  In a general manner, administrators may consider an adequate TTL
>>  setting to not overload client organizations, enable TCP as the
>>  preferred transport, or rely on DNSSEC to warrant data authenticity
>>  and integrity.
>> 
>> 7.3.  Application Security
>> 
>>  The following points are of concern to developers:
>> 
>>  Encryption:
>>  Whenever possible, the application protocol should be encrypted to
>>  prevent eavesdropping and man-in-the-middle attacks.  It is a
>>  critical point for applications maintaining a user session with
>>  anything like a token or cookie, as it can lead to session hijacking
>>  as discussed below.
>> 
>>  Timing attack:
>>  All authentication systems need to be careful to not deliver any
>>  information derived from the computing time to a denied user, even
>>  the ones involving multiple factors or steps like the one described
>>  in this document.  In particular, the order in which these steps are
>>  executed and their respective implementations, need to defeat
>>  statistical hypotheses.
>> 
>>  Intermediate systems:
>>  Some applications are not directly Internet facing and cannot access
>>  to the real client's IP address without involving a mechanism to
>>  forward this IP at the application layer.  For example with HTTP, the
>>  common practice based on the non-standard X-Forwarded-For header, or
>>  its alternative standard Forwarded [RFC7239], are playing this role.
>>  Such practice requires a correct sanitizing of user data to avoid
>>  false injected IPs.
>> 
>>  Session hijacking:
>>  A well-known attack called Session Hijacking is not meant to be
>>  defeated by this document alone.  Application developers must ensure
>>  that any receveid session token, such as an HTTP Cookie, belongs to
>>  the same IP address than the one which started this session.
>> 
>> 8.  References
>> 
>> 
>> 
>> 
>> Adell                    Expires 7 October 2022                [Page 10]
>> 
>> Internet-Draft           Client Roaming Control               April 2022
>> 
>> 
>> 8.1.  Normative References
>> 
>>  [RFC1035]  Mockapetris, P., "Domain names - implementation and
>>             specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
>>             November 1987, <https://www.rfc-editor.org/info/rfc1035>.
>> 
>>  [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>>             Requirement Levels", BCP 14, RFC 2119,
>>             DOI 10.17487/RFC2119, March 1997,
>>             <https://www.rfc-editor.org/info/rfc2119>.
>> 
>>  [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
>>             Resource Identifier (URI): Generic Syntax", STD 66,
>>             RFC 3986, DOI 10.17487/RFC3986, January 2005,
>>             <https://www.rfc-editor.org/info/rfc3986>.
>> 
>>  [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
>>             Architecture", RFC 4291, DOI 10.17487/RFC4291, February
>>             2006, <https://www.rfc-editor.org/info/rfc4291>.
>> 
>>  [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
>>             Specifications: ABNF", STD 68, RFC 5234,
>>             DOI 10.17487/RFC5234, January 2008,
>>             <https://www.rfc-editor.org/info/rfc5234>.
>> 
>>  [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
>>             2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
>>             May 2017, <https://www.rfc-editor.org/info/rfc8174>.
>> 
>> 8.2.  Informative References
>> 
>>  [RFC7239]  Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
>>             RFC 7239, DOI 10.17487/RFC7239, June 2014,
>>             <https://www.rfc-editor.org/info/rfc7239>.
>> 
>>  [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
>>             Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
>>             January 2019, <https://www.rfc-editor.org/info/rfc8499>.
>> 
>> Author's Address
>> 
>>  Eugene Adell
>>  Email: eugene.adell@gmail.com
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Adell                    Expires 7 October 2022                [Page 11]
>> 
>> 
>> RFC 6895 :
>> A. Submission Date:2002/04/05
>> B.1 Submission Type:  [X] New RRTYPE  [ ] Modification to RRTYPE
>> B.2 Kind of RR:  [X] Data RR  [ ] Meta-RR
>> C. Contact Information for submitter :
>>  Name: Eugene Adell               Email Address: eugene.adell@gmail.com
>>  International telephone number: +33699056914
>>  Other contact handles:
>> D. Motivation for the new RRTYPE application.
>>  Introduce a couple of RR types working together in order to better
>> secure remote access to partner applications
>> E. Description of the proposed RR type.
>>  CRC contains a limited list of authorized networks for a particular
>> application
>> F. What existing RRTYPE or RRTYPEs come closest to filling that need
>> and why are they unsatisfactory?
>>  TXT RRTYPE allows the storage of any text data but in practice is
>> usually associated with more or less fixed name or data which is not
>> what is needed here. A dedicated RRTYPE is easier to identify and
>> manage by a security team other than the usual DNS operator team.
>> G. What mnemonic is requested for the new RRTYPE (optional)?
>>  CRC
>> H. Does the requested RRTYPE make use of any existing IANA registry or
>> require the creation of a new IANA subregistry in DNS Parameters?
>>  It uses the existing Resource Record (RR) TYPEs registry
>> I. Does the proposal require/expect any changes in DNS
>> servers/resolvers that prevent the new type from being processed as an
>> unknown RRTYPE (see [RFC3597])?
>>  No
>> J. Comments:
>>  None
>> 
>> 
>> A. Submission Date:2002/04/05
>> B.1 Submission Type:  [X] New RRTYPE  [ ] Modification to RRTYPE
>> B.2 Kind of RR:  [X] Data RR  [ ] Meta-RR
>> C. Contact Information for submitter :
>>  Name: Eugene Adell               Email Address: eugene.adell@gmail.com
>>  International telephone number: +33699056914
>>  Other contact handles:
>> D. Motivation for the new RRTYPE application.
>>  Introduce a couple of RR types working together in order to better
>> secure remote access to partner applications
>> E. Description of the proposed RR type.
>>  CRS contains a requirement value and a list of ports indicating
>> what kind of authorization check is done during the application
>> authentication process
>> F. What existing RRTYPE or RRTYPEs come closest to filling that need
>> and why are they unsatisfactory?
>>  TXT RRTYPE allows the storage of any text data but in practice is
>> usually associated with more or less fixed name or data which is not
>> what is needed here. A dedicated RRTYPE is easier to identify and
>> manage by a security team other than the usual DNS operator team.
>> G. What mnemonic is requested for the new RRTYPE (optional)?
>>  CRS
>> H. Does the requested RRTYPE make use of any existing IANA registry or
>> require the creation of a new IANA subregistry in DNS Parameters?
>>  It uses the existing Resource Record (RR) TYPEs registry
>> I. Does the proposal require/expect any changes in DNS
>> servers/resolvers that prevent the new type from being processed as an
>> unknown RRTYPE (see [RFC3597])?
>>  No
>> J. Comments:
>>  None
>> <draft-adell-client-roaming-00.txt><RFC 6895 material.txt>_______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org