ng a third one is, in my opinion,
entirely outside of the purview of OPSAWG.
There are a host of procedural problems with how the document was adopted. I
suggest that the document be withdrawn, and re-submitted as an individual draft.
Alan DeKok.
___
ly new standard protocol, which is in direct
competition to existing, and active, working groups. Worse, it's a protocol
which the vendor refused to document for 18 years.
Now that they're getting bit by interoperability issues, they're seeking the
IETF stamp of approval. It&#
On Feb 10, 2016, at 3:31 PM, Alan DeKok wrote:
> There are a host of procedural problems with how the document was adopted.
> I suggest that the document be withdrawn, and re-submitted as an individual
> draft.
To be clear:
1. the document never had a WG call for adoption as re
a new working group. "
8. This document is competes directly with two existing working groups, RADEXT
and DIME, to create a third AAA protocol.
9. As such, this document should be explicitly outside of the scope of the
OPSAWG.
> On Feb 10, 2016, at 3:51 PM, Alan DeKok wrote:
>
>
is to push
proprietary protocols behind the scenes, and then present them to the IETF as a
fait accompli.
It's really a slap in the face for everyone who followed the IETF process for
the last 20 years, and did work in RADIUS, AAA, DIME, and RADEXT.
Alan DeKok.
___
standardize TACACS+, we might
as well disband RADEXT and DIME, because there's no point in following a
standards process when people can do an end-run around it.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
te" item in WG queue. It is not too
> late, it is an active protocol, it is not standardised, lack of a standard is
> causing issues by itself. This last item I believe can and should be
> addressed.
That is entirely mischaracterizing my position.
The IETF consensus for the last 20 years has been that RADIUS was chosen over
TACACS+. There is no *technical* reason to re-visit that decision.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
AAA protocols.
I see no technical reason to re-visit that decision now.
> Regarding procedural matters, if we have missed any steps, that is my bad
> and I will consult with those more versed in procedure to rectify that.
The chairs and ADs are responsible for process
I think most people aren't aware of the history of AAA protocols in the iETF.
This message summarizes relevant documents in the area, and makes an appeal to
the WG to remove the document as a WG document.
RADIUS was standardized in 2000 in RFC 2058, after years of WG discussion.
The origi
ization, because the vendor refuses to standardize it in
RADIUS. Which they could have done any time in the last 20 years. They
refused.
Well... they refused. I fail to see how refusing to follow the standards
process means the we should reward them with an official standards track RFC.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
On Feb 11, 2016, at 1:14 AM, Mikael Abrahamsson wrote:
>
> On Wed, 10 Feb 2016, Alan DeKok wrote:
>
>> My point is that TACACS+ has a 100% overlap in functionality with the RADIUS
>> protocol.
>
> As an operator that has been running TACACS for 15+ years, my an
ly in wide spread use. In your view, how do we get that done?
Publish it was an informational document, via an individual submission and AD
sponsorship.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
, it's
time get a rubber stamp on the protocol.
I welcome publishing the document as an information draft. I see no reason
why it should be an IETF standard. And so far, I haven't seen a convincing
argument from anyone else. The arguments in favour amount to:
- just 'cause
- it's widely used
- it's not an AAA protocol, even though it's explicitly an AAA protocol
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
se.
Sure, IPX overlaps with IPv4, but heck... it's widely used, so let's make it
an IETF standard protocol.
If you find those reasons unconvincing, you should find the reasons for
TACACS+ adoption unconvincing, too.
Alan deKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
standardization process.
i.e. the contents of any device management authorization exchange are
entirely vendor specific, and due to the way TACACS+ is being used, *must*
remain vendor-specific.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
tandards track protocol, but TACACS+ gets one, because
"it's popular"?
That's an amazing interpretation of the IETF consensus, and IETF process.
Maybe I'm naive, but it looks a while lot to me like one WG has to follow the
rules to get a protocol standardized, and anot
On Feb 11, 2016, at 1:00 PM, Christopher Morrow
wrote:
>
> On Wed, Feb 10, 2016 at 10:37 PM, Alan DeKok
> wrote:
>> TACACS+ has 100% functionality overlap with RADIUS.
>
> you keep saying this, but I can't get a radius server to authorize my
> command on a
uot;obfuscation". The method described is not what would be described in the
crypto community as "encryption". IMHO, the packet encryption method should be
removed entirely, and TLS transport mandated.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ng it a WG document...
Why, exactly, are is the WG full-steam ahead in making it a standards track
document?
It looks like the IETF ideal of "individuals" is failing here. There are
large forces behind the scenes pushing for standardization, and that is winning
over petty things like in
r widespread use in the industry.
I've been explaining in detail.
> To me, it's like you would be saying that IS-IS shouldn't be in the IETF
> because it was originally an ISO protocol. It's equally absurd.
To me, it's like you're not even reading
do so.
Which pretty much misses the point of my argument.
There are many protocols used on the wider internet which have many more
deployments across more vendors than TACACS+. Those protocols are not
documented in RFCs.
So... why this
intended for "network operations" or
"network administration" is false, and has been documented publicly as being
false for two decades.
The "command authorization" is *explicitly* in scope for RADIUS, and has
*always* been in scope for
On Feb 12, 2016, at 9:07 AM, Mikael Abrahamsson wrote:
>
> On Fri, 12 Feb 2016, Alan DeKok wrote:
>
>> So it *is* a AAA protocol?
>
> I actually do not know what criteria you put in the AAA term. It might be
> different from what I use it for.
This is getting silly.
please read my messages. Including the one you just replied to.
I have *repeatedly* said that I'm OK with it being an informational RFC.
This whole conversation began with me requesting that the document be an
informational RFC.
Just.. enough, already. Please.
Alan DeKok.
__
oject". It's a serious effort
which requires more than a review by OPSAWG, which has many other priorities.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ough that (as you say) the authors have other things to
do... and don't have the time to document old work as different from new work.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
of the TACACS+ servers,
combined, world-wide.
Simple "it's popular" is no argument. I say this as the author of the most
popular RADIUS server on the planet.
Heck, it supports DHCP, BFD, and we're working on Diameter support.
Again.. so?
Alan DeKok.
the
> crypto issue in a backwards-compatible way.
I believe that would be a positive way forward.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
r them to use TACACS+. I'm happy to see the protocol documented
as an informational RFC.
I'm *not* happy with pretty much everything else around the subject.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
to that
use-case.
The thing which is amazing for me is that there is enormous push-back to my
request for consistently applying logic, the IETF process, and IETF consensus.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
On Feb 15, 2016, at 5:07 AM, heasley wrote:
>
> Seems that in the time bikeshedding, this could have already been in WGLC.
> Outstanding work!
Following process and achieving consensus is not "bike shedding". It's
entirely inappropriate to describe i
ck (as here) with comments that are, quite
frankly, irrelevant to the position I hold.
If the best counter-argument to me is a straw man, I have a nice torch handy.
It's called "reality".
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
session was held. The TACACS+ slides used
> during the session are at:
> https://www.ietf.org/proceedings/93/slides/slides-93-opsarea-2.pdf
>
> Minutes of the session are quite sparse. They note that the presentation
> occurred and that Alan DeKok objected to the proposal.
I don
protocol as it exists today? We don't know.
It would be good to get feedback from implementors as to whether or not the
document is correct on it's technical content. I see that information as
critical to have.
Alan DeKok.
___
OPSAWG mai
ter.
But defining a new (to the IETF and the world) network management protocol is
entirely outside of the scope of OPSAWG.
Or, if (as many people say) the protocol isn't new, then OPSAWG won't be
making any changes to TACACS+. It can't both be under IETF change control, and
at
I find such "arguments" entirely
unconvincing.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
we don't have WG consensus on the
document(s), but that the people *proposing* the document(s) can't even reach
consensus among themselves as to what they're proposing.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
s waited 20+ years for standardization, it's worth
waiting a few more months to be sure we get it right.
And since TACACS+ is largely used *within* the enterprise, the issue of
securing it is less relevant than (say) RADIUS, which is used across the wider
internet.
Alan DeKok.
ready.
In short, there is no practical way to onboard users securely via the method
of "connect to an SSID, and click through the prompts". The configuration MUST
be provided to the user signed, and/or via an out of band method.
Alan DeKok.
> On Apr 6, 2016, at 12:46 PM, Christopher Morrow
> wrote:
>
> (I hate to resurrect an old thread. but)
>
> On Mon, Feb 22, 2016 at 10:37 AM, Alan DeKok
> wrote:
> And since TACACS+ is largely used *within* the enterprise, the issue of
> securing it is less
... user
The username. It is encoded in [UTF-8]. It is optional in this
packet, depending upon the class of authentication.
What does it mean to be "optional"? Perhaps the "user_len" field is equal to
zero, which means that the "user" field does not e
too. The temptation for naive
implementors would be to encode an actual string "NULL".
There should be a separate "Security Considerations" section as Section 9.
It should explain all of the issues with the protocol, such as the use of
"encryption", etc.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
r-site deployment have on security?
As an implementor, I would have to guess at large portions of the protocol,
or I would have to read the source to existing implementations. The draft as
is stands today can get me ~90% of the way to implementing the protocol, but
critical portions are n
, makes the checks normative, and adds
a suggestion to close the TCP connection. After all, if they key is wrong and
packets can't be decrypted, there's no reason to keep the TCP connection open.
You can't decrypt any data in the connection, so it will all be garbage.
Alan De
On Jul 15, 2016, at 11:24 AM, Alan DeKok wrote:
> The Security Considerations section is in the middle of the document, where
> it's typically at the end. That's a minor nit. The larger one is that the
> Security Considerations section is pretty minimal. It should desc
Some comments. Mostly little nits and clarifications.
The major points for me are related to security. The "Security
Considerations" section is almost empty, and will certainly not pass a review
from the security area. They will in all likelihood block publication until
substantive comme
Continuing...
Summary: the spec is still fairly descriptive / philosophical instead of
prescriptive. Many optional parts of the protocol are described, "A and B are
allowed", but there is often no description of what to *do* when either A or B
is present. I've suggested descriptive text,
ch text, I'll withdraw all of my review
comments. But I predict that the document won't pass security area review.
And they'll make all of the same comments as I've made here, with a
recommendation that the document not be published until it's fixed.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
we don't need to document the protocol then put a huge
disclaimer at the top of the draft saying so.
Giving lip service to "document the protocol", while opposing attempts to do
so is unproductive.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
d should
not be used by anyone to implement anything. Please wait for the Standards
track document to get the actual TACACS+ specification that people can
implement".
It shouldn't be a contentious issue. Either document the protocol, or admit
we're not going to d
Continuing with 4.4.3
While the order of hosts in this packet indicates a preference, but
the client is not obliged to use that ordering.
* the use of "obliged" is unusual here. Perhaps "the order used by the client
is implementation specific, and does not have to follow the order s
Continuing with Section 8
... Privilege Levels are ordered values from 0 to 15
with each level representing a privilege level that is a superset of
the next lower value.
* nit: perhaps this could be "each level is defined to be a superset of the
next lower value", instead of "repres
My $0.02 on the contents of the Security Considerations section. I'm sure
I've missed things.
Please also comment if the suggestions here are wrong or unworkable.
9. Security Considerations
The protocol described in this document has been in widespread use
since specified in "The Dra
While I appreciate that the document is improving, blatant copying of my text
without attribution is entirely inappropriate.
What are the chairs recommendations?
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailma
ll be followed.
I would suggest that it's too early to have a WGLC, as the authors simply
haven't responded to reviews of the draft.
i.e. I have no idea what state the draft is in. After doing multiple
detailed reviews that largely get ignored,
do more.
>> It's up to the authors to demonstrate that the comments have been addressed.
>
> Authors have the next step to do at this time. Let's wait for the new
> revision first.
It's also possible to respond publicly to my review.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
On May 12, 2017, at 2:40 PM, Douglas Gash (dcmgash) wrote:
> 1) Regarding the use of uncredited text from Alan DeKok:
>
> It is certainly the case that Alan has spent time actively engaged in the
> process of critiquing this document to improve it, and provided numerous
> p
ensus, I suggest the chairs
replace you with authors who will.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
the existing
implementors haven't reviewed the document. So we have no idea whether or not
it describes the protocol they've implemented, or the choices they've made.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
o make here. The only
subjects you addressed were ones I hadn't raised.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
adopt this, and what status should it be.
Part of the problem is that it's hard to have an ongoing conversation around
my reviews. The comments are so numerous that discussing each one publicly
would require hundreds of messages.
Which for me is a sign that the draft is just nowhere n
On May 14, 2017, at 8:11 AM, Douglas Gash (dcmgash) wrote:
> We will work through this list, and reply with an item-by item response,
> (In place of previous mode of updating the doc to make v6) and then
> hopefully move towards a consensus for the content for version 7.
Thanks.
A
IETF works. I fail to see what else could be commented
> here.
I'm saying until I complained, that *was* largely the process being used in
this WG.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
task_id? Since values can be omitted, is it OK to have a
> zero-length task_id? or 1 octet?
>
> * are there recommendations for the content of task_id? e.g. incrementing
> numbers, strings, etc.
>
> * is task_id mandatory to occur in accounting packets?
> [task_id is best
to speak for everyone, I think the current approach in the draft will be fine.
They may ask for some sections to be removed (i.e. servers pushing keys to
clients). But everything else is pretty much fine.
The idea is that having a documented protocol, with warnings and caveats, i
o d). How much of UTF8 is allowed and where; it encompasses
> over 65k characters these day:-(
IMHO, the draft should just mention 18n, and run away screaming. :(
As in, "we know about it, we don't know how to fix it, we don't know what
mplementation defined, the range of T+ devices we
>>> see is so diverse and use cases are such that I would not like to
>>> constrain.]
>>
>> It would be good to have recommendations. e.g. "updates more than once
>> per second are NOT RECOMMEND, updates more t
he previous ad-hoc definitions.
> Boolean
>
> All boolean attributes are encoded with values "true" or "false".
Nit: encoded as US-ASCII strings with values...
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
for it.
>
> We believe this option will enable an effective encapsulated upgrade approach
> for implementors, and welcome feedback.
I think it's a good approach.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
k.
>
> Therefore, this kicks off a two-week CfA for
> https://datatracker.ietf.org/doc/draft-boucadair-opsawg-add-encrypted-dns/.
> Please comment on-list with support and/or discussion of the work.
I believe it should be adopted.
We can worry about R
ameter, and does not need to be mentioned in any RADIUS specification.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
On Sep 15, 2022, at 10:04 AM, Qin Wu wrote:
>
> Thank for clarification, so Diameter protocol doesn't need to define any new
> attributes with similar functionality as Radius attributes, right?
That is what I said.
Alan DeKok.
is copied to DHCPv6
option BAR". There should probably either be an explicit mapping table given,
or each attribute definition should be extended with "this attribute is copied
to DHCPv6 attribute BAR"
Without such direction, an implementor has to gue
-Lite-Tunnel-Name RADIUS attribute is a string
> with opaque encapsulation, according to Section 5 of [RFC2865].
That appears to be an error. I'll file an errata with IANA.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
le documents, and then "read between the
lines" to see what's implied. This is hard.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
On Oct 6, 2022, at 9:32 AM,
wrote:
> I added an appendix for this as you can see at:
> https://tinyurl.com/opsawg-add-latest.
I missed that, sorry.
> Do we need to sway more?
No, I think this looks good.
Alan DeKok.
___
OPSAW
ts only for "top level" attributes, and cannot
be used here.
Further, RADIUS packets are generally limited to 4K octets total. So even if
the limits on this attribute are removed, then there's still a practical limit
of around 4000 octets.
Alan DeKok.
_
014 i.e. DHCPv4 carries RADIUS
attributes. So there's reasonable precedent.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
th. Each child attribute can then carry a full 253
octets of data. And there are no limits on the number of child attributes
which ca be carried.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ns could suggest that
implementations SHOULD support 64K RADIUS packets.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
are happy to accept
longer packets.
i.e. it's 2022, I think that software can easily handle 64K buffers for
network protocols.
There's also RFC 7499 which supports fragmentation of CoA packets. Perhaps a
similar method could be used here, if required?
Alan DeKok.
_
iguration, the RADIUS server SHOULD expose the DHCP options and allow
administrators to configure them, instead of requiring them to be entered as
opaque data".
That gets the best of both worlds.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
S attribute, and
separately in a DHCPv6-Options attribute. They can all be added to the packets.
i.e. if the administrator of the system configures something weird, the
systems should just do what's asked.
Anything past basic filtering is complex to define, and complex to
Having been just added as co-author, No, I'm not aware of any IPR that
applies to this draft"
> On Oct 12, 2022, at 12:46 PM, Joe Clarke (jclarke) wrote:
>
> Authors and contributors, please respond on-list as to whether or not you are
> aware of any IPR that pertains to this work.
>
> Ple
lob/v3.2.x/raddb/mods-available/eap#L177
It's for EAP-TLS, but the requirements for TACACS+ with TLS would be similar.
There are a large number of options for configuring certificates, validation
methods, CAs, PSKs, etc. Nearly all of these would be required when TACACS+ is
used wi
> IANA is requested to create a new sub-registry entitled "DHCPv6
> Options Permitted in the RADIUS DHCPv6-Options Attribute" in the
> "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry
> [DHCP
; [Rob Wilton (rwilton)]
>
> Okay. If this will be obvious to everyone implementing/deploying RADIUS then
> fine, otherwise it might be worth including an informative reference to the
> RFC that increases the limit to 64K.
This is RFC 7930. Packet size limitations w
nly be extended by implementing the negotiation discussed
in the other specifications.
So we would like to suggest 64K packets here, but we can't mandate them,
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
it should automatically create correctly-formed attributes.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
be secured by RADIUS, and used in environments where
RADIUS is (allegedly) secure. This means IPSec / TLS / management networks.
If RADIUS administrators want to send insecure UDP packets over the wider
Internet, then there's a lot more information than this which will get le
TACACS+.
As a result, it is useful to have a configuration which can say "allow
network FOO, forbid network BAR". This would be in addition to any TLS layer
filtering.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
a need for that, or would
> this rather be an convenience option? A specific port number limits the
> attack surface to a single port, and I don't see any need for that.
I think a dedicated port for TACACS+TLS would be good.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
or anyone interested in the underlying reasons, there is a long discussion
of this topic in
https://datatracker.ietf.org/doc/html/draft-dekok-radext-deprecating-radius-03#section-7.3
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
draft-dekok-radext-deprecating-radius) rather than duplicating the reco in
> the doc.
Sure. That reference should informative, as the deprecation doc may take a
while to be published. That way it doesn't block your document.
Alan DeKok.
___
. I'd suggest reading the RADEXT TLS-PSK and ALPN documents linked
above. They go into exhaustive detail about how every little bit is supposed
to work. I've found that documenting the protocol in such detail greatly
improves the quality of the implementations, and is more likely to result in
interoperation between the implementations.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
o
> that mis-configured clients can be fixed?
Not really.
If the authors believe that there is significant operational benefit to
re-using the port, then the document should explain that in detail.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG
rrently permitted to define an attribute which has a
zero-length value.
As such, "hold for document update" is the reasonable conclusion.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
P address filtering? If the client has
correct TLS credentials, does it really matter what IP it comes from?
i.e. will the move to TLS still have servers identify clients by IP address?
Servers could also be configured to limit connections by source IP, as an
additional layer of security.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
e draft, and the lack of experience with
implementations, I'd suggest that "Experimental" is more appropriate.
Alan DeKok.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
might be late 2024
before this work starts.
Alan DeKok.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
1 - 100 of 158 matches
Mail list logo
