►
From YouTube: Istio WG Meeting 2022 08 31
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
So
the
first
item
on
the
agenda
I
believe
I
actually
added,
so
we
find
out
this
particular
environment
variable
we
have
users
using
them,
so
we
actually
been
having
some
offline
discussion
with
Rama
and
I.
Don't
believe
there
is
a
way
to
handle
this
without
this
function
restored
or
have
it
in
a
proper
API.
So
what
we
are
thinking
is
revert
this
adding
back
this
particular
environment,
variable
and
also
working
with
the
community
to
maybe
have
a
design
dog
to
think
out.
A
What's
the
right
API
for
this
type
of
scenario,
so
I
think
Brad,
you
already
opened
a
PR
about
adding
this
back.
I
just
want
to
mentions
to
community
in
case
anybody
have
any
concerns.
A
Yeah
so
Carson
and
you
were
asking
which
environment
variable
yeah,
so
this
particular
piaz
37374.
If
you
click
on
that
link,
it
actually
removed
two
of
the
environment
variables
and,
interestingly
enough,
on
the
very
next
day,
one
of
the
environmental
variable
was
already
being
restored
because
somebody
needs
it.
What
we
are
discussing
is
the
second
environmental
variable
that's
been
removed
by
this
Pi,
which
is
pilot,
enabled
kubernetes,
selector
workload,
entries.
A
What
was
the
purpose
yeah
so
I
think
the
purpose,
if
I
understood
correctly
was
he
was
creating
service
entry
which
selects
both
kubernetes
service
and
also
a
workout
entry
that
corresponding
to
a
remote
service,
maybe
could
be
from
another
kubernetes
cluster,
and
then
he
wants
to
kind
of
refer
to
that
particular
service.
Using
the
hostname
defined
endless
service
entry
was
the
particular
kubernetes
assignments.
C
Reverting
it
for
now,
because
we
have
customers
depending
on
it,
but
there's
some
behavior
in
service
entries
that
are
particularly
confusing,
bad
and,
and
you
know
where
you
know,
the
technical
debts
keeps
accumulating,
especially
you
know,
since
the
Gateway
apis
kind
of
using
services
or
subset,
it's
becoming
very
confusing
between
you
know
the
service
center
or
egress
service
entry
for
for
defining,
for
example,
for
service,
basically
and
all
kind
of
Arcane
uses
of
service
entries.
C
C
Mean
if
we
have
customers,
we
need
to
understand,
I
mean
we
cannot
break
them,
but
at
some
points
we
need
to
do
a
clean
up.
I,
don't
know
how.
A
Yeah
so
so
custom,
so
maybe
it
would
be
good
when
you
have
your
dog
ready.
It
would
be
good
to
share
with
us
and
yeah
and
Rob
I
I.
Think
you
made
an
interesting
comment
on
Define
the
user
case
and
desire
Behavior,
so
we
probably
should
be
doing
that.
So
we
can,
you
know,
make
sure
people
understand
the
scenarios.
C
My
proposal
is
boils
down
to
to
stop
using
service
entry
for
defining
internal
object.
I
mean
the
internal
mention
all
the
other
stuff.
We
have
one
local
entry,
keep
service
center
for
egress
only
and
use
Service
Plus
workload,
entry
for
foreign.
F
Yeah
I
was
just
gonna
respond
on,
like
the
general
issue,
I
think
like
as
a
one-off,
that's
fine.
We
can
revert
this
PR,
but
this
is
kind
of
a
sign
of
a
process.
Failure
like
as
maintainers
of
istio.
F
You
could
not
be
depending
on
flags
which
are
explicitly
marked
as
temporary.
If
you
do
depend
on
the
features
we
should
have
figured
this
out
a
year
ago
when
we've
introduced
them
that,
like
hey
I,
need
this
thing,
that's
temporary!
How
do
we
make
it
permanent?
What's
the
proper
API,
you
know.
How
do
we
clean
up
the
tech
debt
around
here?
F
If
we
do
depend
on
it
that
type
of
thing
so
I
I
find
as
like
a
one-off
thing
here,
but
this
is
definitely
a
sign
that
something
went
wrong
here
if
you're,
depending
on
feature
Flags
long
term
speak
now,
because
you
will
be
broken.
A
C
The
environment
variables
that
are
used
because
no
environment
variable
is
effectively
an
idea.
We
agreed
that
you
know
and
it's
a
way
to
introduce
temporary
stuff.
It's
definitely
not
something
that
it's
a30
doesn't
API
servers
that
we
guarantee
support
and
long-term
maintenance.
C
We
need
to
stop
users
from
using
experimental
internal
Flags
or
things
that
are
not
supposed
to
be
part
of
the
API
surface,
because
this
photon
is
this
one.
There
are
hundreds
of
others
problematic.
A
Yeah
so
I
agree
with
the
concerns
here.
I
I
think.
If
this
function
is
important,
someone
needs
to
take
it
forward
with
the
proper
design,
doc
and
proper
documentation
of
the
user
case
and
scenarios
and
also
find
a
proper
home
I
think.
The
consensus
here
is
also
restore
this
function
for
SEO,
114
and
master.
Before
we
find
a
good
solution
and
Rob
did
you
want
to
mention
something.
You've
been
pretty
active
in
the
chat
which
I
agree
with
all
your
comments.
G
I
no
I
I
mean
sure
well,
I,
guess
I'm
talking
now
so
sure,
I
just
think
process,
wise
I
think
it's
fine
to
delete
this
stuff,
and
it's
it's
you
know
marked
as
experimental
or
whatever,
but
I
think
it's
also
good
to
give
users
a
heads
up
like
Hey
we're
going
to
be
deleting
this
in
the
next
release.
G
So
you've
got
you
know
some
time
to
make
accommodations
and
yet
I
understand
what
you're
saying
koston
about
deprecating
things
that
might
be
internal
or
experimental,
but
at
least,
if
they're
put
on
a
plan
like
hey
these
are
going
away.
Then
users
at
least
have
a
couple
months
to
be
like
okay,
I
need
to
clean
up
my
act
and
figure
out
a
way
around
it
because
right
it
cuts
kind
of
both
ways.
Right,
it's
experimental,
you
use
it
at
your
own
risk.
It
might
disappear
anyway.
G
If
it's
internal
you're,
you
know
I
I
kind
of
awesome
like
we
don't
it's
internal
sorry,
you're
you're
at
risk
of
being
broken
if
you're
relying
on
internal
features,
but
it's
hard
to
document
and
know
for
some
of
this
stuff
and
people
are
trying
to
implement.
Use
cases
in
ways
that
might
not
be
but
I
think
at
least
for
experimental
things
we
can
get
folks
a
heads
up.
That's.
C
B
C
It
up,
but
what
I
was
trying
to
do
to
get
at
is
at
some
point.
We
need
some
to
draw
a
line
and
to
provide
a
flag
or
some
some
way
for
people
to
opt
in
to
Safe,
Behavior
or
long-term
supported
and
maybe
combine
multiple
changes
together.
So
they
have
one
migration
instead
of
heading
to
every
release,
to
to
get
some
some
variables
off.
So
if
we
introduce
a
SEO
safe
is
to
production
is
to
whatever,
then
we
can
combine
in
that
it
could
be.
A
Supported
yeah
and
I
think
Rob's
common.
Is
your
value
right?
Give
people
a
window
to
respond,
so
we
can
get
feedback
the
you
know
we
can
get
the
feedback
properly
when
we
are
removing
the
experimental
feature,
because
the
point
of
experimental
is
to
put
out
there
to
get
feedback
right.
So
we
just
remove
them
without
getting
sufficient
feedback.
A
Well,
there's
two
hands:
I
want
to
have
Mitch
I,
don't
know
who
actually,
let
me
open
the
queue
Rob
go
ahead.
G
E
G
Hopefully,
they'll
you
know
incorporate
that,
but
you
know:
maintainers
are
balancing
user
features
that
may
be
experimental
with
other
aspects
of
the
project.
So
just
because
I,
you
know,
I
think
the
challenge
there
is
like
just
because
a
bunch
of
people
come
and
say:
hey.
We
were
relying
on
this.
You
should
keep
it.
You
know.
Maybe
that's
a
sign
that
hey
this,
the
the
experiment
was
a
success,
but
you
know
it's
not
working
for
us
long
term.
G
So
let's
take
those
use
cases
and
find
a
you
know
long-term
way
to
support
those
use
cases
so
like
as
as
custom
was
mentioning
earlier.
For
that
you
know
to
give
a
concrete
example
right
for
this
case.
Is
you
know,
instead
of
using
service
entries
plus,
you
know
pod
and
workload,
selectors
use
kubernetes
service
and
how
to
use
the
workload
resources
to
opt
those
external
workloads
into
local
Services
which
to
me
it
at
least
for
this
case-
seems
very
reasonable.
B
Think
there
are
two
processes
that
could
have
helped
us
in
this
particular
case.
The
first
is
that
pull
requests
like
this
really
ought
to
include
release
notes.
This
particular
poll
request
was
labeled
with
release
notes,
one
or
none
sorry,
so,
just
as
a
note,
if
you're
reviewing
PR's
error
on
the
side
of
asking
submitters
to
include
release,
notes
and
removing
that
label,
so
that
that
way,
users
who
are
upgrading
to
114
could
at
least
see
this
in
advance
before
they
install
114
and
find
that
it's
no
longer
effective.
B
B
That
would
raise
the
visibility
of
something
like
this
I'm,
not
sure
that
all
users
who
make
use
of
this
are
necessarily
going
to
be
aware
of
the
risk
that
they're
taking
on
by
adopting
something.
Of
course,
we
all
know
that
it's
experimental.
We
all
know
that
environment
variables
are
not
meant
to
be
supported
long
term,
but
that
may
not
be
visible
to
the
users.
So
we've
had
in
the
ux
group
designed
for
this
for
a
while,
it's
just
been
unstaffed.
B
So
if
there's
interest
in
pursuing
this
and
Staffing
to
to
support
it,
giving
the
users
sort
of
like
a
pre-check
command,
that
could
say
here
are
all
the
alpha
or
experimental
features.
You're
using
that
are
not
guaranteed
to
work
after
upgrade
could
be
valuable.
A
C
So
if
you
create
a
service
with
with
the
you
know,
selector,
it
should
work
the
same
way.
I
mean
the
same
thing
with
with
the
electoralism
service
selector
or
should
be.
C
That
that's
the
problem
with
I
mean
what
I
was
trying
to
solve
this
application.
That
problem
is
that,
in
in
service
entry,
you
can
create
both
external
names
and
internal
names.
If
you
want
an
external-
and
you
are
more
or
less
in
the
case
of
an
egress
I
mean
it
should
be
an
indirect
situation.
If
you
have
an
example.com,
it's
not
really
an
eternal
certificate.
C
This
is
our
cluster
local
and
we
have
this
confusion
between
you
know,
example.com,
being
so-called
internal
service,
with
just
that
we're
creating
DMS
for
just
to
help
it
in
the
real
internet
service.
A
Well,
it's
a
so
for
for
one
thing:
what
I've
heard
is
what,
if
I
want
to
call
that
Services,
regardless,
where
I
am
so,
if
I'm
outside
of
kubernetes,
if
I'm
inside
of
the
kubernetes
I,
don't
have
to
change
my
code
to
call
that
particular
service
right,
so
I
can
always
use
in
this
particular
service
name,
whatever
I
mean
we'll
just
give
me
example.com,
but
whatever
name
you
know
the
company
or
the
customer
prefers.
A
Instead
of
you
know,
reviews
that
deforge.service.local.
You
know,
which
is
the
only
specific
queue
the
kubernetes
cluster.
So
if
I'm
running
outside
of
that,
cluster
I
would
have
to
change
my
code
or
maybe
an
environment
variable
or
my
configuration
that
that
may
not
be
desired.
Yeah.
C
A
C
C
C
C
F
Think,
okay,
that's
google.com,
that's
obviously
external,
but
if
you
actually
want
to
do
that
in
code,
it's
quite
a
bit
trickier!
G
Post
name,
that's
you
know,
Global
to
my
domain
or
whatever
that
I'm
routing
for
and
I
don't
want
to
have
the
extra
hop
of
coming
to
an
Ingress
Gateway
for
that
hostname
and
I
just
want.
If
it's
external,
it
goes
to
the
external
workload.
If
it's
coming
from
the
cluster,
it
goes
to
either
a
local
service
or
the
external
workload.
G
B
G
C
A
Okay,
yeah:
let's
do
that?
Let's
follow
up
with
that.
Rob
I'll
put
the
comments
you
made,
or
maybe,
as
a
study
employees
making
sure
you
know
we
have
that
and
costing.
A
If
you
have
any
thoughts
on
service
entry
limitations,
please
do
share
with
with
me
and
other
people
in
the
community
who
are
interested
and
then,
in
the
meantime,
I
think
everyone
agrees
to
restore
this
as
we
iterate
the
users
can
use
a
scenario
and
potential
design
for
this
with
that
I
think
with
spending
enough
time
on
this
topic,
I
would
like
to
change
over
to
the
next
topic,
which
is
all
C
policy
on
TCP
ports.
A
H
So
for
this
topic,
we're
going
to
discuss
about
a
behavior
of
oxy
deny
policy
which
we
think
is
not
correct.
So
to
give
you
a
background
on
this,
so
when
we
create
Aussie
policy,
we
create
a
network,
filter
and
HTTP
filter
and
all
our
like
TCA
ports.
They
rely
on
tcv
filters,
the
config
generated
from
the
DC
Builder.
H
So
the
problem
is
when
we
apply
any
L7
when
we
apply
any
Deni
or
Z
policy,
which
has
just
a
pure
L7
tools,
which
means
does
the
HTTP
Fields
example
like
path,
host
or
method?
In
that
case,
any
TCP
Port,
which
lies
under
the
scope
of
that
policy.
All
the
traffic
to
that
Port
will
be
rejected.
H
So
if
you
see
this
example,
so
in
this
example,
we
are
applying
this
policy
in
the
name
Chris,
who
insta
deny
policy
and
in
the
rule
we
have
the
request
principle
and
the
method,
so
it
is
so
both
of
both
the
fields
in
the
source
and
operation
are
HTTP
field.
So
that
means
when
we
apply
this
policy,
the
config
generated
by
the
TCP
filter
will
look
something
like
this.
So
in
this
you
can
see
the
permission,
it's
true
for
anything
and
the
principle,
it's
true
for
anything.
H
So
that
means
any
request
comes
to
any
Etc
report.
It
will
be
denied,
but
it
shouldn't
happen.
So,
let's
think
about
a
scenario
when
you
have
some
HTTP
Services
running
and
you
apply
this
kind
of
policy
that
is
working
fine,
but
now
you
added
some
MySQL
or
Addis
instance
to
that
which
supports
TCB
protocol.
In
that
case,
all
the
traffic
to
that
MySQL
or
redis
will
be
broken.
So
this,
we
think,
is
not
a
correct
option
to
go
for
you.
Users
can
resolve
this
issue
just
by
adding
the
port
level
details
in
their
rules.
H
So,
for
example,
if
you
consider
this
policy,
if
you
add
a
port
level
detail
with
the
methods,
then
it
won't
be
applied
to
all
the
TCP
Port.
It
will
be
just
applied
to
the
port
9000..
This
is
happening
because
the
TC
filter
it
is
not
able
to
understand
the
HTTP
rules
and
once
it
is
not
able
to
understand
the
deny
policy
as
a
restrictive
mechanism,
it
is
denying
everything.
H
So
this
is
the
this
is
the
other
kind
of
example.
So
in
this
example,
you
have
two
different
rules.
One
has
like
just
HTTP
another
one
is
like
like
the
TCP
field,
so
in
this
case
as
well.
So
since
Aussie
policy
like
rely
on
rules
before
doing
this,
so
one
of
the
rule
has
just
the
HTTP
semantics.
If
any
of
the
rule
matches
in
the
deny
policy,
it
will
just
deny
it
so.
The
first
rule
matches-
and
it
will
deny
everything.
H
H
Okay,
so
we
are
proposing
a
change
in
stod,
so
whenever
we
create
a
TCP
filter,
we
should
we
shouldn't,
apply
the
pure
L7
rules,
so
let's
say
pure
L7
rules
which
I
have
showed
in
the
example
one.
So,
let's,
if
a
rule,
has
something
like
this
just
request,
principle
or
method,
we
shouldn't
add
this
kind
of
rule
in
the
TCA
filter
config.
H
If
we
do
that,
if
we
do
not
apply
these
kind
of
rules
in
a
TC
filter,
then
the
TCP
ports
won't
be
blocked
by
this,
and
there
are
few
documentation
changes
required
for
this.
Since
we
are
making
this
change,
probably
there
might
be
some
users
who
would
be
affected,
so
we
should
add
this
kind
of
scenarios
in
the
documentation
and
we
should
like
guide.
You
guide
our
users
on
this.
C
If
it
is
Swift,
We
have
certain
that
it's
not
going
to
be
classified
as
PCP
with
any
input
that
is
https
available
time
out.
It's
not
going
to
misclassify
anything.
It
is
HTTP,
no
matter
what.
E
H
C
C
Or
whatever
it
is,
that
will
not
look
like
HTTP
from
the
point
of
USB
versus
people
will
say:
hey.
This
is
an
HTTP
static.
Tcp
applies
the
TCP
rules
go
to
the
application,
but
the
application
HTTP
parser,
which
is
more
tolerant,
probably
would
say
hey.
This
may
be,
it
looks
like
HTTP
I
mean
I,
expect
HTTP
I'm
going
to
be
as
taller
and
as
possible
and
part
of
the
input.
C
As
you
know,
maybe
it
has
five
extra
words
in
in
the
request
line
instead
of
three,
but
the
the
color
will
will
treat
it
as
we
will
still
recognize.
E
F
Yeah
I
would
agree.
I
have
major
concern
with
that
as
well,
but
then
I
don't
know,
like
my
thought
process.
Okay,
we
can't
have
it
apply
a
sniffing
because
that
makes
sniffing
like
this
highly
secure
aspect
and
then
so
it's
like
okay.
We
only
do
it
on
explicit
with
TCP
ports,
but
then
we
have
this
really
weird
difference
of
behavior
of
explicitly
declared
ports
and
sniffing,
which
seems
wrong
as
well,
which
then
leads
me
back
to
the
current
behavior
of
being
correct.
So
well,.
C
B
C
B
D
Yeah
I
think
the
rule
of
thumb
of
oscillation
policies.
It
should
be
very
explicit
and
clear.
So
if
the
denied
policy
says
yeah,
if
this
condition
match
then
deny,
then
we
should
follow
that.
So
only
if
we
see
the
exact
match,
then
we
will
deny
the
traffic.
Otherwise
it
should
not
affect
the
traffic
I.
Think
that's
the
yeah,
that's
the
thing
is
proposing.
We
should
follow
this
rule.
D
The
current
behavior
is:
if
we,
if
the
yeah,
we
cannot
sell
the
protocol,
whether
whether
or
not
it's
measure
or
not,
we
always
deny,
and
that
part
is
wrong.
That's
the
yeah!
That's
the
thing:
we're
trying
to
fix
yeah.
C
But
but
we
should
still
verify
the
sleep
I
mean
if
we
need
to
conference
as
a
sniffer.
It's
it's
us.
You
know
tolerant
as
possible.
Basically
yeah
yeah.
E
F
Yeah,
okay,
fine
yeah
I
was
gonna
say
like
I
think
by
definition,
it
can't
be
like
every
obstacy
bug
we
get
is
basically
a
mismatch
of
envoy
versus
the
application
and
I
refuse
to
believe
that
we
could
ever
create
a
snipper.
That's
actually
accurate,
because
there's
applications
that
will
parse
the
craziest
things
as
HTTP
that
are
very
tolerant,
we're
always
pretty
strict.
Sometimes
that's
not
HTTP,
but
the
back
end
does
and
then
we're
screwed
right.
F
So
I
don't
think
it's
not
that
it
had
to
be
implemented.
It's
something
that
is
not
secure
by
Design.
Almost.
C
F
The
problem
is
that
not
everyone
implements
HTTP
the
same
way,
so
Envoy
could
look
at
it
and
think
that's
not
HTTP
I
could
look
at
it
say:
that's
not
HTTP,
but
some
back-end
could
be
like
whatever
I,
don't
care
that
it's
spelled
HTTP
instead
of
HTTP
or
something
like
fine,
that's
close
enough
and
accept
it
right
and
then
there's
a
CBE.
So.
F
C
How
about
the
middle
ground
solution,
where,
where
we
continue
to
what
we
are
doing
for
anything
that
has
anything?
But
if
the
user
is
explicit
and
say
hey,
this
is
MySQL
port
and
clear
that
it's
not
going
to
be
I,
don't
have
a
TCP
parser.
Then
there
is
no
point
to
denying
it
because
the
user
explicitly
tell
that
that
you
know,
even
if
the
request
is
post,
because
it's
my
SQL
part
that
is
processing
the
request
is
they
are
not
going
to.
You
know
be
affected
by
this.
C
D
Probably
yeah
yeah
I
want
to
comment
on
this
point.
Yeah
so
I
think.
If
customers
really
worry
about
the
security,
they
should
actually
make
a
deny
by
default.
So
if
there's
anything
yeah,
we
cannot
make
decisions,
it
should
always
be
denied
and.
E
D
D
I
Yeah
in
our
documentation,
we
claim
that
HTTP
and
HTTP
2
are
supported
for
auto
sleeping,
but
it
seems
like
we
have
a
bug
for
auto
sleeping.
Basically,
you
can
somehow
bypass,
even
though
you
are
HTTP
protocol,
but
somehow
you
can
bypass
the
auto
sniffing
as
a
different
protocol
right.
I
E
E
D
B
D
Think
we
already
yeah,
but
right
now
we
already
have
a
supported
rule
is
if
there's
only
denied
policy
is
actually
a
lot
by
default,
but
only
if
you
have
a
low
policy,
then
it
becomes
denied
by
default.
If
we
want
to
continually
support
supporting
this
Behavior,
then
we
can
ask
customers
always
add
some
other
policy
like.
H
Yeah,
so
something
like
this
in
this
case
for
this
case,
so,
let's
say
you're
saying
if
we
have
a
deny
policy
and
if
there
is
no
allow
policy
that
should
be
denied
by
default
right
for
all
for
all
the
other
cases,
then
what
there's
a
use
of
deny
policy
which
we
are
applying
to
us,
because
any
user
have
to
apply
the
allow
policy
if
they
just
have
allow
policy
that
all
the
requests
will
be
denied
so
deny
by
default,
is
already
working.
So
there
is
no
use
of
deny
policies.
In
that
case,
right
no.
D
No
deny
policy
has
higher
priority,
so
if
you
have
both
allowance
deny,
then
I
will
always
be
evaluating.
First,
okay,.
F
Saying
that
if
you
explicitly
declare
report
it
shouldn't
apply
I
almost
agree,
my
only
difference
would
be
that
I
I
feel
like
two
things.
One
is
that
we
can't
look
at
this
in
a
vacuum.
We
have
an
existing
config
and
so
I'm
actually
pretty
against
making
any
changes
to
the
existing
API
in
general,
even
if
they're
good
changes.
F
But
aside
from
that,
it
does
seem
like
the
protocol
declaration
impacting
out.
Z
is
like
it
does
make
sense
kind
of,
but
it's
also
fairly
implicit,
but
I
do
agree
with
the
concept
like.
If
you
say
this
is
TCP,
then
why
bother
with
the
rules
but
I
would
prefer
it
to
be
in
the
rule
itself
and
add
a
field
that
says
when
protocol
equals
http
did
not
get
requests
and
the
reason
I
like
that
is
it's
a
lot
more
explicit
and,
most
importantly,
it's
not
a
breaking
chain.
F
There's
no
Behavior
change
for
existing
users.
Otherwise,
if
we
want
to
do
this,
I
feel
like
we
need
to
do
it
along
like
a
breaking
change:
Moment
Like.
If
we
switch
over
to
the
Gateway
API
or
something,
then
we
can
change
Behavior
or
if
we
I
don't
know,
do
some
other
breaking
change
in
Eco.
We
could
do
it
at
that
time.
Otherwise,
it's
kind
of
tricky.
D
C
If
I
believe
it's
easy
to
Applications,
you
have
a
application
http
and
then
we
are
back
to
square
one.
That's
a
good
point,
but
I
want
to
point
out
the
reason
we
need
to
fix
this
is
that
that
can
goes
out
of
this
I
mean
we
are
in
a
situation
or
use
that
has
you
know
perfectly
happy
cluster
everything
works.
Suddenly
there
is
a
denial
of
service,
which
is
one
of
the
main
reason
for
denied.
C
You
know
it's
primarily
intending
when
you
have
it
in
our
service
or
a
query
of
that
or
some
queries.
That
is
it's.
You
know.
You
believe
that
it's
causing
problems
you
are
quickly
reliable,
for
example,
and
suddenly
your
electricity
services,
even
if
you
were
you,
know
careful,
labeled,
all
the
services
and
and
put
you
know,
protocol
TCP
and
everything
else,
but
that
that
really,
you
know
kind
of
super
scary,
because
customers
that
that's
what
I
will
typically
do.
If
I
see
a
query
of
death
rather
denial.
H
And
to
answer
John's
question
on
the
API
changes,
so
let's
say:
if
we
make
changes
for
the
raw
TC
reports,
I,
don't
think
we
will
be
breaking
any
user
in
that
case,
because
if
they
have
this
kind
of
condition,
this
kind
of
scenario
is
already
present
in
their
workloads.
Then
the
TCB
traffic
is
already
blocked
right,
so
they
might
be
having
the
better
policies
for
the
DC
workload.
So
we
are
not
touching
them.
We
are
just
upgrading
the
kind
of
policies
they
are
applying.
A
C
D
A
Because
I'm
thinking
about
like
in
the
zero
trust
sense
right,
we
basically
you
want
to
deny
everything
possibly
and
then
you
kind
of
explicitly
allow
things
as
you
needed
to
right.
You
want
to
be
extremely
explicit
if
you
can
so
in
that
sense,
you
would
still
deny
like.
You
would
have
a
blank
feline
statement
to
pretty
much
divide
everything.
A
And
then,
let's
say,
if
your
service
a
needs
to
talk
to
your
service
B,
whether
it's
on
TCP
or
HTTP,
then
you
would
build
a
very
specific
authorization
policy
to
only
allow
if
it's
zoning
allow
get
requests
but
not
on
posts
or
delete,
then
you
would
be
like
really
explicit
and
if
it's
layer
four,
you
would
also
be
very
explicit
on
what's
allowed
and
everything
else
should
be
denied.
I
D
Yeah,
so
right
now
the
designs:
we
have
the
implicit
enablement
for
assertion
policy
before
you
apply
any
operation
policy,
all
the
traffic
go
through,
but
once
you
start
applying
a
log
policy,
it
should
be
denied
but
then
denied
by
default.
Behavior
kicked
in
yes,
we
we
also
have
the
situations
that
if
there
is
only
one
allowed
or
one
dni
policy,
there
is
no
other
allow
policy.
D
Actually,
my
ideal
scenario
is
in
this
case.
It
should
also
be
denied
by
default,
but
I
think
there
are
also
arguments
like
the
current
behavior
is
actually,
if
there's
only
denied
policy,
it's
actually
Allowed
by
default.
So
if
the
deny
policy
does
not
match,
then
everything
is
still
the
old
behavior
is
is
allowed.
It's
like
a
no
authentic
policy
applied.
I
A
deny
policy,
so
basically,
if
that
doesn't
match
it
should
be
allowed
right
because
you
don't
have
you
know.
D
C
Okay,
so
so
it
doesn't
change
anything
now.
Users
will
just
need
to
do
an
extra
step
and
put
allow
star,
so
it
doesn't
really
help
in
this
case,
because
first
of
all
would
break
users
and
second,
even
if
we
make
this
change,
users
will
have
to
go
and
modify
their
policies.
What
then
allow
all,
but
we
are
back
to
square
one,
because
when
they
do
deny
Port
deny
post,
we.
D
Yeah
yeah
I'm,
just
I,
just
want
to
answer
Link's
question
being
said:
if
the
ideal
case
is
everything
is
denied
by
default.
So
I'm
saying
that's
one
exception
today
is:
if
you
only
have
one,
if
you
only
have
denied
rule
there
are
no
other
rules,
then
it's
allowed
by
default.
A
E
C
I
D
I
By
the
way,
today,
in
today's
product
it's
still
products
security
mean
we
are
going
also
going
through
this
topic
up
to
discuss
whether
allows
the
change
the
behavior
for
auto
sniffing
port
to
to
allow
the
TCP
is
like
a
is
acceptable
or
it
will
not
cause
the
security
vulnerability,
because,
right
now
the
behavior
is,
if
you
can't
sniff
the
traffic
it
will
be
denied,
but
in
this
proposal
it
will
be
changed
to
be.
C
E
C
I
Yeah
yeah
I,
agree,
I
think
as
a
second
part,
and
the
first
case
is
very
clear.
It's
about
the
second
one,
because
the
auto
sniffing
doesn't
work
reliably.
It's
kind
of
causes
concerns
on
the
it
may
cause
security,
vulnerabilities,
so
yeah
and.
C
Frankly,
if
a
user
you
know,
is
security
conscious
and
it's
going
to
the
trouble
to
put
policy
rules
and
and
have
authorization
policies,
probably
it's
very
reasonable
to
ask
them
to
labor
supports
and
not
rely
on
guessing
because
again
you
you
write
policy
rules,
you
cannot
kind
of
depend
on
guessing.
It's
not
the
most
secure
posture
to
to
get
assistance.
If
your
HTTP
and
apply
policies.
I
That's
right:
we
can
write
some
security
best
practice
to
ask
users
to
explicitly
follow
the
important
aiming
to
declare
as
a
protocol
for
the
plots.
So
then
it
will
go
through
the
the
Royal
TCP
parts
right.
So
if
it's
a
really
raw
TCP
Parts,
you
should
declare
it
as
a
royal
TCP
ports.
Then
it
will
not
be
denied
with
the
change
of
after
the
bug
is
fixed
here.
H
Okay,
so
just
to
conclude
the
point,
but
with
what
custom
made
so
basically
for
the
ports,
which
doesn't
require
any
kind
of
sniffing,
we
should
update
it.
It
shouldn't
deny
always
and
for
the
ports
where
sniffing
is
required.
Probably
they
that
could
like
the
HTTP
one
would
be
treated
as
a
TCP.
In
that
case
we
cannot
do
it,
so
we
shouldn't
change
the
behavior.
In
that
case,
right
yep.
E
D
H
C
We
cannot
have
persistent
Behavior
because
the
employee
behavior
is
different.
We
will
always
treat
it
as
TCP
and
the
user
told
us
there
is
no
HTTP
for
that.
Port
I
mean
we
know
that
it's
not
HTTP,
because
the
user
explicitly
declared
it.
But
in
the
other
case
it's
a
guess.
So
it's
not
the
same
thing
to
guess
and
to
have
a
clear
indication
of
the
protocol.
I
Yeah,
but
in
idea
what
I
agree
we
mean
that
we
should
have
was
a
consistent
Behavior,
but
right
now
it
seems
the
auto
significant
doesn't
work
consistently,
but
we
can
maybe
put
this
as
a
long-term
go.
Maybe
fixing
the
this
Auto
sniffing
path,
but
I.
D
I
just
feel
it's
really
confusing.
If
you
like
the
sniffing
result,
probably
user
cannot
tell
what
will
be
the
result
of
sniffing
then
they
cannot
really
tell
what
will
be
the
obsession
outcome
and
that
will
be
dangerous.
D
I
But
they
somehow
have
a
way
to
impersonate
other
different
protocol
right
so
attackers
somehow,
even
though
it's
HTTP,
but
somehow
it
has
a
way
to
bypass
the
sleeping,
for
example,
I
guess
Costco
mentioned
a
few
ways.
So
I
guess
that's
the
reasons.
Some
security
concern
but
I
agree.
The
behaviors
will
definitely
be
consistent.
I
think
we
internally
go
through
this.
You
know
you
know
a
separate
meeting
but
foreign.
E
I
think
the
the
consensus
was
the
that
if
the
official
policy
touched
HTTP
and
it
shouldn't
affect
the
TCP
filter
chain,
it's
separate
from
other
sniffing
right.
The
autosmithing
shouldn't
decide
how
us
the
policy
works
right.
If,
if
agree
that
http
feels
only
touches,
we
feel
the
chain,
then
then,
then
that's
it
right.
E
I
The
problem
is
the
auto
sniffing
for
auto
significant
parts
right
this.
Doesn't
it
can't
tell
whether
it's
a
really
Royal,
TCP
or
HTTP?
The
attacker
can
send
HTTP
traffic,
but
somehow
the
Amway
think.
Oh,
this
is
a
royal
TCP.
Then
it
bypass
the
the
deny
rules.
It
basically
can
get
the
passes
through.
I.
Think
that's
the
concern
here.
D
I
only
care
about
this
HTTP
traffic,
then
only
if
it
matches
then
it's
denies.
Otherwise
it
should
not
affect
other
traffic.
Auto
sniffing
has
problem.
Maybe
we
should.
Why
is
documentation?
The
other
is
saying
yeah
you
should
follow.
The
best
practice
should
not
apply
observation
policy
for
this
kind
of
Auto,
significant
traffic
and
there's
one
yeah.
One
more
way
they
can
prevent
passing
through
is
to
add
other
one.
General
allow
policy,
which
is
to
make
the
traffic
denied
by
default.
C
I
mean
whatever
we
are
doing
is
not
going
to
fix
anything.
It's
a
significance
is
used
as
a
security
feature
to
this.
Identification
applies,
City,
Rules
and
since
it's
not
accurate,
it
will
misclassify
and
the
application
will
still
receive
HTTP
requests,
and
then
we
believe
that
if
this
is
the
request,
so
there
is
no
way
it
doesn't
matter
what
police
we
are
putting.
As
long
as
what
safety
is
in
place.
With
this
behavior
of
you
know,
kind
of
creating
as
HTTP
or
HTTP
evaluates
the
opposite.
We
still
have
a
security
one
CD.
D
D
Yeah,
why
don't
we
say
if
Smith's
symphony
is
used,
then
customers
should
always
have
denied
by
default.
Rule
sounds
reasonable.
No
I
mean
customers
should
always
add
a
lot
of
policy
to
make
it
by
default,
but.
C
C
D
I
Yeah,
if
they
explicitly
follow
the
port
naming
scheme
to
declare
as
a
royal
TCP
Port,
then
it
will
not
have
this
issue.
They
will
not
go
through
the
auto
significant.
You
know
thought
yeah.
I
C
If
we
have
clear
warnings
that,
if
you
use
knitting
and
security,
something
will
flow
around
I
guess
they
will
labor
support
and
get
extra
benefits,
because
if
we,
if
we
don't
have
to
generate
the
sleeping,
we
kind
of
signify
the
config
we
have.
Let's
work
to
do,
it's
probably
faster.
There
is
no
incentive
to
it's
only
reason
to
use
knitting.
Is
your
completely
lazy
and
you
just
want
the
limit.
You
have
to
work
without
any
configuration
out
of
box,
but.
E
H
Yeah
I
agree
like
we
should
pass
a
message
like
sniffing
and
security
wouldn't
work
like
as
predicted,
and
the
thing
is
the
I'm.
My
only
concern
is
since
we
are
making
changes
for
the
non-staving
port
and
we
are
not
making
changes
for
the
auto
sniffing.
So
this
could
like
create
more
confusion
among
users,
and
we
will
see
a
lot
of
issues
on
GitHub
and
everywhere,
probably
on
this,
and
we
will
just
have
to
tell
them
every
time.
C
D
Yeah,
if
we
say
we
only
support
the
the
protocol
that
we
we
can
determine
on,
then
we
don't
need
to
have
different
behavior
for
auto
significant
versus
the
normal
yeah.
C
We
still
need
to
do
something
for
existing
users.
Some
user
has
automating
and
has
political
meaning.
We
cannot
break
some.
We
can
document
that
it's
not
supported,
we
can
modernize
them
and
use
your
cattle,
but
we
cannot
make
a
backpacking
compatible
change.
I
mean
this
is
okay
to
make,
because
it's
more
tolerant,
it's
actually
fixing
something
that
is
a
particular
clear
bag
where,
where
a
MySQL
is
blocked,
when
it
showed.
H
C
E
H
G
D
C
Happy
to
we
can
fix
it,
you
know
separate
release,
so
this
is
at
least
we
fix
it,
the
declared
ports,
and
if
someone
finds
the
solutions
that
will
work
properly
with
sniffing,
we
can
fix
it
later
as
a
second
but
yeah
but
I,
don't
know
any
solutions
that
will
work
since.
E
H
D
You're
costing,
if
we
are
saying
Auto,
sniffing
or
searching
policy,
is
not
supported,
then
not
spotted
means
we,
we
are
not
having
authorization
policy
in
the
place
does
not
mean
what
a
search
policy
will
automatically
take
effect
and
create
another
traffic.
C
H
H
C
H
Okay,
yeah
so
yeah,
just
to
conclude
like
for
sniffing,
we
don't
need
to
make
any
changes.
Whatever
the
current
scenario
is,
it
is
good.
We
are
denying
everything
for
the
cases
of
not
sniffing
where,
like
the
users
have
explicitly
defined
their
ports.
In
that
case,
we
can
change
it,
and
we
shouldn't
deny
based
on
the
L7
rules,
yeah.