Dear Alan and OPSAWG,
Many thanks for taking the time to take a scan on the T+ Document.
Apologies for the delay in responding; this document is a collaboration between
multiple authors and we’re getting our internal issue tracking process going.
To this end, we have split your comments into 4 main issues, and I’ll be making
a response (your other points will be responded to shortly by the other
authors.) to the following points from your mail
“ Section 4 concerns me. This is not just adding TLS to TACACS+, it's adding
an entirely new flow: TACACS+ proxying. This is a major change to TACACS+, and
I would strongly suggest moving it to another document.
I would also recommend not defining a new packet type which extends the
horrific TACACS+ packet format. We've come a long way in protocol design since
the mid 1990s. The packet format is awkward, at best. It is difficult to
create and/or parse correctly.
Plus, what if the proxy wishes to forward information about the client
certificate, or server certificate which was used? The current format makes
this impossible.
My recommendation would be to take a page from DHCPv6, and just add an
encapsulation layer. e.g. a TACACS+ header with minor version 2, and a new
type signifying "proxied packet". That packet could simply be a container for
encapsulating the original packet.
i.e. instead of re-encoding the entire packet (with all of the issues and
errors that entails), just take the original packet, add a proxy header, and
send that essentially verbatim. This is much simpler, and has much less room
for errors.
i.e. a proxied packet could look like:
TACACS+ header (minor = 2, type = proxied)
proxy header {
length of proxy header
flag for is next header a proxied packet.
original src / dst ip / port
... potentially other data ..
}
length of original packet
verbatim copy of original packet
That format is simpler to encode/decode, simpler to understand, and is easily
extensible to add new fields. It also allows for multiple layers of proxying,
which the current draft doesn't.
“
The purpose of Section 4 is to introduce arguments handling into Authentication
phase of the T+ protocol, to align it with the with the authorization and
accounting phases. To recap: authorization and accounting phases have
extensible arguments handling, authentication does not. Section 4 intends to
bring the same patterns we have in authorization and accounting into
authentication.
Just like the flexibility that arguments give authorization and accounting; we
believe that adding this same pattern in authentication provides flexibility to
support flows such as SSH key distribution (another enhancement elsewhere in
the doc).
But we can see from your comment that the document confuses the technical
definition of the alignment, with the application of that alignment (such as
the Proxy attribute). Certainly, we need to make this distinction clearer, so
to do this we will completely remove the mention of proxy flow from section 4.
Proxy will be discussed more below.
In terms of the protocol format: we favored consistency: using the same pattern
for authentication for the argument-type data that was already defined in
authorization and accounting we thought would be more helpful to implementors
than introducing a new format. The Arguments pattern in authorization and
accounting phases is pretty simple and robust, if a little dated, and keeping
the same pattern would at least allow the same parsing approach to be used.
If we picked a different format for the argument data for authentication, we
will guarantee inconsistency between authentication and authorization and
accounting. Eventually, the new style we pick is itself likely to be obsoleted,
in which case we will have both an obsoleted and inconsistent choice.
That said, if the group favors a different approach for adding arguments to
authentication, over consistency of the same idiom for what is already in the
protocol, we will take this back and update the doc.
Regarding the Proxy Flow specifically: in the experience of the authors this is
not a new flow for T+: it is an established practice in the field. However,
there is a weak point for T+ in the proxy case: the authentication packets do
not contain the original client. T+ servers tend to deduce the client from the
other end of the TCP connection. This limitation means the final T+ server will
only be able to deduce the proxy, and not the original client. But, policy
normally needs to be evaluated according to what the original client is, NOT
the proxy server. So, the intent here is merely to allow a flow that is already
used in the field work better.
As discussed above, our first thought is to take the proxy out from section 4
and move it to a new section in the document. If it is still regarded by the
group that adding this enhancement for proxy support is outside the useful
remit of the document, then rather than just moving the definition of the proxy
attribute to its own section, we can remove it altogether.
If there are any issues with how this mail is formatted or the subject line
please let me know.
With Kind Regards.
From: OPSAWG <opsawg-boun...@ietf.org> on behalf of opsawg-requ...@ietf.org
<opsawg-requ...@ietf.org>
Date: Wednesday, 6 April 2022 at 20:01
To: opsawg@ietf.org <opsawg@ietf.org>
Subject: OPSAWG Digest, Vol 179, Issue 2
Send OPSAWG mailing list submissions to
opsawg@ietf.org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/opsawg
or, via email, send a message with subject or body 'help' to
opsawg-requ...@ietf.org
You can reach the person managing the list at
opsawg-ow...@ietf.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OPSAWG digest..."
Today's Topics:
1. Re: [internet-dra...@ietf.org: I-D Action:
draft-dahm-tacacs-security-00.txt] (Alan DeKok)
2. Re: WG LC: A YANG Model for Network and VPN Service
Performance Monitoring (Joe Clarke (jclarke))
----------------------------------------------------------------------
Message: 1
Date: Tue, 5 Apr 2022 17:15:21 -0400
From: Alan DeKok <al...@deployingradius.com>
To: heasley <h...@shrubbery.net>
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] [internet-dra...@ietf.org: I-D Action:
draft-dahm-tacacs-security-00.txt]
Message-ID: <2b0c4405-db4e-4afc-aea5-526deeb9e...@deployingradius.com>
Content-Type: text/plain; charset=us-ascii
This is a quick review based on first impressions.
It may be good to have a note that the existing TACACS+ port can be used for
TLS, if both ends are configured to require TLS. That means systems can use
existing firewall rules, etc. for TACACS+TLS.
Section 3.2 says:
the resumption ticket_lifetime SHOULD be configurable, including a zero seconds
lifetime.
I'm not sure what a "zero-seconds lifetime" would mean. It may be better to
just omit the ticket in that case.
It would be good to mention that TLS Server Name Indication (SNI) SHOULD be
supported (https://datatracker.ietf.org/doc/html/rfc6066#section-3). That way
one server can act as the TACACS+ host for multiple domains, and switch between
them using SNI.
Section 4 concerns me. This is not just adding TLS to TACACS+, it's adding
an entirely new flow: TACACS+ proxying. This is a major change to TACACS+, and
I would strongly suggest moving it to another document.
I would also recommend not defining a new packet type which extends the
horrific TACACS+ packet format. We've come a long way in protocol design since
the mid 1990s. The packet format is awkward, at best. It is difficult to
create and/or parse correctly.
Plus, what if the proxy wishes to forward information about the client
certificate, or server certificate which was used? The current format makes
this impossible.
My recommendation would be to take a page from DHCPv6, and just add an
encapsulation layer. e.g. a TACACS+ header with minor version 2, and a new
type signifying "proxied packet". That packet could simply be a container for
encapsulating the original packet.
i.e. instead of re-encoding the entire packet (with all of the issues and
errors that entails), just take the original packet, add a proxy header, and
send that essentially verbatim. This is much simpler, and has much less room
for errors.
i.e. a proxied packet could look like:
TACACS+ header (minor = 2, type = proxied)
proxy header {
length of proxy header
flag for is next header a proxied packet.
original src / dst ip / port
... potentially other data ..
}
length of original packet
verbatim copy of original packet
That format is simpler to encode/decode, simpler to understand, and is easily
extensible to add new fields. It also allows for multiple layers of proxying,
which the current draft doesn't.
Alan DeKok.
------------------------------
Message: 2
Date: Wed, 6 Apr 2022 14:16:33 +0000
From: "Joe Clarke (jclarke)" <jcla...@cisco.com>
To: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: [OPSAWG] WG LC: A YANG Model for Network and VPN Service
Performance Monitoring
Message-ID:
<bn9pr11mb5371559fe7731c04bd209473b8...@bn9pr11mb5371.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
The WG LC is now closed. Tom has provided additional comments, and I
still have some outstanding reviews, so I will mark this as pending a
revised I-D. I noted no strong opposition to this work during the process.
We are in need of a shepherd for this work. Who is interested?
An IPR poll went out with authors responding that there is no known
IPR. I have confirmed none has been submitted in Data Tracker. If
there is any known IPR, it must be disclosed.
Joe
On 3/28/22 09:52, Joe Clarke (jclarke) wrote:
> In preparing for IETF 113, I let the close of this slip, but that turns
> out to be a good thing.
>
> During her presentation, Bo called out the authors made a substantive
> change in the latest revision to introduce a choice for vpn-pm-type.
> Therefore, we are extending LC for another week to close on Monday,
> April 4, 2022.
>
> Joe
>
> On 2/28/22 18:05, Joe Clarke (jclarke) wrote:
>> Ahead of IETF 113, we'd like to get working group consensus on
>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/. We
>> are therefore conducting a two-week WG LC on this work. I have also
>> requested reviews from Yang Docs, Ops, and Routing DIRs.
>>
>> Please share you comments and reviews on list.
>>
>> WG LC will end on March 14, 2022.
>>
>> Thanks.
>>
>> Joe
>>
>
------------------------------
Subject: Digest Footer
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
------------------------------
End of OPSAWG Digest, Vol 179, Issue 2
**************************************
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
