►
From YouTube: Ambient Mesh WG meeting 2023 08 02
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
But
yeah,
let's
sync
offline.
C
I
said
I
was
gonna
Kickstarter
to
court
good
morning.
Everyone
welcome
to
the
Wednesday
August,
2nd
I,
still
ambient
weekly
contributors
meeting.
So
on
the
agenda
we
I
don't
know
who's.
Let
me
present.
First,
hang
on.
C
All
right
so
if
I
I
have
to
run
in
about
20
minutes
or
so
I
have
a
meeting
at
10
30.,
so
who's
got
this
first
agenda.
I,
don't
see
anyone's
name
on
it.
D
D
I
think
I
got
the
permissions
to
you.
I'm
just
learning
Google
meet
prison,
presenting
it's
my
third
meeting
to
work,
and
you
know
give
me
a
little
bit
here
to
figure
out
how
to
get
this
going.
C
E
D
All
right,
let's
see
if
it's
not
working
all
right,
so
yes,
that's
the
right
one.
It's
not
the
only
notes.
D
Go
yes,
so
I
wanted
to
give
an
update
on
these
docs
I
put
them
out
two
or
three
weeks
ago,
an
etrc
approval
because
of
their
size.
You've
got
one
that
equals
six
for
approval,
with
some
pretty
good
discussion
on
them.
D
I
think
I
just
want
to
give
an
FYI
that,
because
of
the
nature
of
these,
and
because
they
are
kind
of
holding
up
any
future
API
things
when
it
comes
to
Ambience
I
want
to
kind
of
ask
if
folks,
to
be
okay
with
me,
starting
at
least
the
API
changes
to
the
no
stage
nprs,
so
that
person's
gonna
get
a
better
idea
of
what
it
would
look
like,
and
you
can
make
a
little
bit
of
progress,
but
that
would
be
cool
to
kind
of
have
a
look
at
Laser
consensus
model
for
the
API
fingers,
at
least
just
so
that
we
can
get
started
on
it,
because
at
this
point
we
only
have
one
out
of
the
six
TSC
members
and
the
only
questions
seem
to
be
about
implementation.
F
F
D
Yeah
I
mean
that's,
that's
correct,
the
the
reason
why
I
bring
that
up
is
yes,
it's
CRC
dated,
but
I
believe
it
only
requires
one
or
two
UTS
human
reviews,
and
so
I
want
wow.
F
D
Yeah,
that's
fair,
I,
guess
the
other
way
I
guess
I
can
break.
This
is
like
what
what
does
Toc
this
gives
me
anything
from
me
to
get
this
ball.
To
get
this
ball
rolling
yeah.
You
can
ask
any
questions.
G
Yeah,
so
one
thing
I
would
like
to
ask:
if
it's
possible
is
to
maybe
give
some
examples
which
I
think
you
will
need
the
examples.
Will
you
submit
the
pr
in
the
API
repo
anyway,
so
it
would
be
good
to
have
some
examples
on
how
layer
uses
with
unspecified
transport
and
applications.
G
D
Okay,
I
will
add
the
examples
for
like
a
targeted.
That's
a
good
idea
for
the
Target
ref
proposal
here,
I
think
I'm
showing
that
one
for
that
one
do.
We
are
there
other
other
need
here.
Any
extra
clarification
included
on
on
this
particular
on
this
talk.
G
D
Okay
does
so
I
guess.
My
question
to
that
is:
does
ambiguity
on
the
option
preclude
or
would
ambiguity
on
the
option
if
you
haven't
decided
on
the
option
yet
would
that
preclude
the
API
itself
changing
because
this,
if
this
is
the
only
open
question,
this
is
an
implementation
question?
Would
that
preclude
an
API
change.
E
D
F
D
Topic
gotcha.
So
that's
the
case
thing.
What
I'm
hearing
is
good
to
create
the
API
trainings
for
Target
ref,
but
need
some
examples
for
the
layer
targeted
authorization
policy,
though,
does
that
sound
about
right.
F
You
so
much
that's
from
Lynn.
What
I
wanted
to
ask
was
directly
to
Eric
and
Mitch
what
is
needed
to
go
from
where
we
are
to
where
you
have
approved
the
docs.
G
D
H
So
kind
of
a
follow-up
for
previous
discussion
in
istio.
What
is
the
expectation
for
users
who
are
using
sidecars
when
this
API
is
no
longer
hidden
and
so
forth?
And
it's
available.
D
No,
so
this
this
proposal,
specifically
for
Waypoint
policy,
actually
there's
a
section
in
there
about
that
with
kind
for
without
kinds
for
the
Target
reps
and
right
now,
the
only
dot
kind
is
is
Gateway,
I,
guess
technically.
That
would
still
allow
them
to
apply
policy
to
a
Gateway
like
about
the
Gateway
API
flavored
Ingress,
Gateway
yeah.
D
I
thought
I
said
something
in
here
about
that
I,
don't
know
where
I
landed
on
this,
maybe
no!
No,
that's
not
it.
Yes,
okay.
Finally,
in
this
this
Pros
the
students
feel
to
be
a
lot
for
all
gateways
English
as
well,
but
if
those
are
managed
via
Gateway
API
and
not
issue
API.
So
yes,
the
proposal
would
allow
sidecar
users
to
use
Target
rep
to
apply
policy
to
Ingress
Gateway.
H
Okay,
I
mean
I,
I
I,
don't
have
no
opinions,
it's
just
any
backward
compartment
changes
or
anything
for
the
old
style
users.
We
may
need
to
be
careful,
but
as
long
as
it's
clear
and
specified
and
we
test
for
it.
That's
okay,.
D
Yeah
this
is
this:
probably
information
problem
like
AI
photograph.
Is
there
then
don't
it?
Is
there
and
it's
valid,
then
don't
even
look
at
workload.
Selector.
D
C
So
who's
got
Z
tunnel
hairpinning.
G
E
Yeah
is
it
working
yes,
cool
yeah,
so
I
think
most
everybody
who's
seen
I
tried
to
reorganize
it
a
bit
just
to
make
it.
You
know
just
take
everybody's
comments
into
account,
but
that
kind
of
split
to
the
dock
and
trying
to
answer
two
questions,
which
is:
how
do
we
control
what
happens
whether
we
deny,
whether
we
even
let
it
into
Z
tunnel
et
cetera
and
then
for
the
cases
that
we
do
allow
how
we
want
to
afford
that
traffic?
E
Honestly,
I,
don't
think
I
understand
this
problem
as
well
as
others
here,
like
costume
and
John
and
Ben
all
have
pretty
strong
opinions,
but
the
things
that
I
think
we
were
going
to
rule
out
are
probably
using
a
fake
identity.
It
sounds
like
that.
Just
adds
special
case
complexity
all
over
the
place,
and
it's
not
really
worth
doing
and
doing
playing
tlsh
bone
would
work.
Okay,
but
I
don't
know.
Where
do
we
want
to
start
on
the.
E
Okay:
let's
try
that
that's
constant
kind
of
suggested
using
network
policy
as
one
of
the
major
ways
to
control
this
I
assume
that's
just
as
far
as
like
saying
we
can
allow
this
set
of
things
in
Ambience
talk
to
things
that
are
not
an
ambient
or
vice
versa.
So
I
don't
know
if
you
can
help
elaborate
real.
E
H
It's
a
fundamental
problem
with
that
we
need
to
to
answer,
is
how
do
we
deal
with
non-mesh
traffic,
meaning
that
if
you
have
a
workload
that
it's
clearly
not
using
ambient,
or
at
least
your
classic,
do
we
pretend
that
we
apply
some
policies
to
it
and
and
we
clearly
Define
What
policies
apply
to
this
subset
of
workloads
that
are,
they
don't
have
identity
and
they
use
plain
text
or
network
security,
and
how
does
it
impact
the
traffic
if
they
are
using
network
police
and
other
policies
outside?
H
E
H
E
Well,
we
definitely
shouldn't
break
Network
policy.
I
definitely
agree
with
that,
but
as
far
as
like
you're
saying,
we
only
apply
some
undefined
subset
of
L7
I.
Think
John
already
explained
in
one
of
the
comments,
but
I
think
that
since
policy
is
mostly
defined
kind
of
like
server
info
server
side
perspective
or
we
should
apply
whatever
policies
we
can
so,
if
something's
written
around
using
specific
identities,
that
would
definitely
get
denied.
E
H
F
There,
the
client
has
no
identity,
and
you
can
take
that
into
account
in
your
policy.
What
I'm
not
sure
what
I
understand
unless
you're
talking
about
the
current
case,
I
think
everyone
agrees
is
broken
that
we
and
somehow
impersonate
the
identity.
That's
total
bogus!
That's
everyone
agrees
asked
to
go
I
think,
but
what
we
will,
in
my
opinion
should
say
is
that
when
the
policy
is
evaluated,
it'll
be
evaluated
as
if
the
client
has
no
identity,
because
they
don't
right.
H
Then
it
stopped
working
because
it's
your
policy
will
probably
not
say
you
know,
allow
this
weird
unknown
policy
or
unknown
identity,
and
so
you
know
by
enabling
ambient
on
a
port,
you
will
break
traffic
if
ISO
is
using.
You
know
it's
not
modifying
policy
to
put
this
unknown,
as
as,
if
it
is,
you
know,
pretend
is
your
workload.
A
F
H
One
of
the
concerns,
the
other
one,
is
that
we
are
changing
the
apis
to
introduce
this
concept
of
strange
identity
specific
to
to
you
know,
on
the
end
that
is,
is
this
unknown
identity
and
users
will
believe
that
hey
this
is,
as
I
said,
mtls
certificate,
so
it
must
be
secure.
H
F
Maybe
I
still
cannot.
We
have
five
options
here
and
I,
don't
know
which
one
you're
arguing
against.
F
H
I'm
pushing
for
an
option
for
users
to
opt
out
of
capture
of
non
to
leave;
yeah
plain
text
alone:
okay,.
F
But
the
arguments
you're
using
I
feel
like
are
against
Bad
implementations
of
capturing,
so
I'm
not
sure
that
I
buy
that
there
at
least
part
of
it
like
in
my
mind,
three
is
the
option.
That
is
the
correct
way
to
do
this,
and
then,
in
that
case,
there's
no
client
identity,
there's
not
a
made-up
unknown
fake
one,
there's
just
no
client
identity,
just
like
we
have
today.
If
you
get
plain
text
in
the
Sidecar,
so
I
think
that
addresses
at
least
some
of
your
concerns.
I'm,
not
sure
if
I
remember,
if
that
captures
all
of.
F
All
of
them,
because
a
good
variations
but
yeah,
hey,
we'll
break,
never
fall
asleep,
but
so
does
H
bone
in
general,
even
without
ambient
and
ambient
without
waypoints
and
ambient.
Even
in
your
proposal
that
plain
text
is
passed
through
like.
H
H
F
Only
captured,
but
once
both
sides
is
ambient,
then
whatever
policy
is
broken
right.
Sure.
H
F
H
Anyway,
so.
B
G
E
B
Number
two
is
number
two
is
also
oh
right
out.
Yeah,
we
don't
want
the
weird
identities.
I,
don't
think.
B
B
Three
three
and
four
I
think
are
most
appealing
to
me
personally,
mostly
I.
Don't
like
the
idea
of
a
weird
identity
and
I
also
don't
like
the
idea
of
letting
people
write,
granular
policy
against
something
that
we
can't
attest
and
I
didn't
before
and
as
long
as
we're
meeting
that
which
I
think
we
are
with
either
of
these,
because
pure
authentication
is
not
granular,
it's
either.
You
know
it's
allowed
or
not
like
that
makes
sense
to
me.
B
B
Also
I
feel
like
there's
an
opportunity
for
foot
guns
there,
because
it's
sort
of
assuming
that
it's
sort
of
assuming
that
other
pieces
are
in
place
to
allow
to
prevent
anything
from
leaking.
And
if
something
else
fails
somewhere
else,
then
it
might
actually
be
easier
to
leak
traffic
through
without
using
on
or
mtls.
H
So
I
I
don't
think
five
is
mutually
exclusive,
with
either
three
or
four
I
mean
it
is
that's
right.
All
I'm
asking
is
that
users
who
want
to
apply
networks
to
you
know
to
not
have
ambient
touch
non-ambient
traffic
to
have
an
option
to
do
it,
I
mean
if
people
want
to
use
the
others,
it's
not
necessarily.
It
should
be
a
choice.
Basically,
I
don't
want
to
exclude
five
just
because
there
are
some
element
use
cases
that
may
or
may
not
be
impacted
right.
B
And
I
mean
we
is
the
port
exclusion
thing
in
here.
I
thought
I
saw
that
at
the
bottom
or
something
yeah
yeah,
because
we
could
I
feel
like
it's
a
little
wonky,
but
you
could
achieve
that
with
those
include
or
exclude,
depending
on
what
we
want
to
do,
which
I
think
we
need
that
anyway.
But.
H
What
proposal
makes
this
smooth
because
you
no
longer
relies
on
all
the
headers
and
we
can
do
Telemetry
without,
and
we
just
had
a
discussion
in
a
previous
meeting
about
you
know
if
workload
is
not
using
metadata
exchange
to
not
send
the
extra
head
the
same
way,
so
I
I
I
think
it's
very
reasonable
for
users
to
expect
that
they
don't
use
history
on
both
ends
to
not
get
the
same.
Telemetry.
B
G
H
B
D
F
F
F
Clicks
the
client
doesn't
have
the
choice
of
whether
they're
in
Ambience,
the
server
has
deployed
a
policy
that
says
all
traffic
going
to
me
needs
to
go
through
the
Waypoint
pulse,
Waypoint
I'm,
going
to
enforce
policy
there.
If
we
bypass
that,
then
what's
the
point
of
the
Waypoint
it's,
why
would
you
apply
authorization
balls
at
a
waypoint?
If
you
can
just
bypass
it.
H
For
some
mesh
traffic,
I
mean
it's:
it's
a
policy
for
mesh
traffic,
not
for
for
non-mesh
traffic
I
mean
you.
F
And
all
the
other
stuff,
you
can
write
a
policy
that
says
I
want
to
deny
post
requests
from
everyone.
You
could
say:
I
want
to
denied
post
requests
only
from
unauthenticated
people.
You
could
say
I
want
to
deny
a
post
request
only
from
authenticated
people,
you
can
all
this
can
be
expressed,
but
if
we
just
cut
off
the
chain
and
decide
for
them,
if
it's
unauthenticated,
it's
allowed,
that
seems
extremely
broken.
F
A
H
F
E
G
H
Yeah
I
guess
you
could
not
use
Waypoint
or
tool
and
then
just
use
Gateway,
and
then
you
can
react.
Okay,
that's
that's
fine
as
well
I
mean
so.
Basically,
it's
not
using
Waypoint
is
the
best
option
to
not
so
so.
If
the
user
doesn't
have
a
waypoint,
just
use
your
regular
Gateway,
everything
is
fine.
I
mean.
F
G
Why
not
for
I,
don't
I
didn't
quite
catch?
Why
is
four
ruled
out.
B
They're
somewhat
equivalent,
but
the
idea
I
think
is
that
it's
to
John's
point
it's
a
little
better
to
once
we
get
the
traffic
we.
We
should
do
best
effort
on
it
right.
We
don't
know
anything
about
the
source
identity,
so
we
can't
actually
do
client
identity,
but
we
can
at
a
minimum,
do
TLS
right.
That's
it!
That's
that's
the
best
we
can
do
so.
Let's
do
that
sorry,
yeah.
F
I
feel
like
three
and
four
are
a
bit
confusing
to
me.
Well,
partially,
because
I
forget
what
three
says
and
I
can't
read
anymore,
but
if
the
thing
you're
interested
in
there
Lynn
is
the
ability
to
deny
you
can't.
Oh,
it
is
actually
mentioned
in
three.
You
can't
do
that.
That's
what
pure
authentication
is,
for
you
say,
strict
mode,
then
plain
text,
Graphics
denied
I,
don't
think
we
even
need
to
send
a
waypoint.
F
In
that
case,
the
difference
really
at
least
in
my
mind,
is
whether
we
send
it
as
a
one-way,
TLS,
H
bone
connection
or
plain
text,
which
it
wasn't
clear
to
me.
If
this
was
h2c
tunnel
or
raw,
we
can't
do
raw,
so
I
assume
it
would
be
hp2
tunnel
without
TLS,
which
feels
just
more
complicated
to
me
like
then,
we
have
to
add
a
different
port.
That's
like
plain
text,
H
bone,
it's
much
similar
to
do
everything
over
to
your
loss.
In
my
mind,.
E
G
So
we
do
ttrs
and
we'll
make
sure
I
understand
so
the
source
the
tunnel
would
it
use
which
identity
would.
G
H
F
F
H
E
H
So
normally
you
expect
traffic
to
go
to
zitana
zitana
sent
to
Waypoint
and
send
back
yeah.
Are
we
sure
that,
if
someone
else
on
a
talker
running
somewhere
randomly
connecting
to
Waypoint
pretending
to
be
the
Z
tunnel
that,
with
that
particular
identity
with
all
the
headers
and
everything
else
and
Waypoint
sending
it
back
to
support
that
is
you
know
targeted
will
not
risk.
H
G
D
H
Remember
this
the
problems
we
had
with
with
the
chain
gateways
where,
where
you
know
you,
you
had
some
gate
in
front
of
the
gateways
that
was
injecting
what
kind
of
X4
audit
for
and
what
kind
of
sensitive
feathers
and.
F
F
The
thing
that
The
Hairpin
requests
don't
have
an
identity
associated
with
them.
So
if
the
client,
if
this
attacker,
if
they
have
an
identity,
then
even
if
they're
an
attacker,
that's
that's
a
security
model.
If
you
have
an
identity,
that's
who
you
are
so
that's
kind
of
moved
and
doesn't
change
by
this.
If
they
don't
have
an
identity,
then
we
don't
treat
them
as
authenticated
right,
I'm,
not
sure
where
they
are
impersonating.
Someone
they're,
not
impersonating
the
disease.
I
know
they're,
just
sending
a
request
at
Z10.
F
D
As
long
as
the
the
Waypoint
and
the
view
tunnel
after
the
pair
of
request
comes
back
as
long
as
they
don't
take
any
action
on
behalf
of
an
identity,
I,
don't
see
where
the
private
escalation
comes
through
right.
If
Waypoint
is
equal
to
a
book
regard
that
original
connection,
it's
being
unauthenticated
no
identity,
then
there's
nothing
that
can
do
with
like
any
policy
that
says
you
have
to
have
identity.
That's
going
to
block
that
traffic,
any
I
can't
even
think
of
a
you
know
in
any
access
that
you
might
have.
D
H
So
there
is
no
sense
that
you've
heard
that
person
by
by
no
no
influenza
protocol
in
the
H1
protocol
and
anything
that
you
know
someone
could
use
a
waypoint
as
a
way
to
jump
to
specific,
individual
IPS
and
and
with
you
know,
because
normally
Waypoint
to
back
to
to
the
workload
is
authenticated.
And
it's
pretending
to
come
from
somewhere.
And
it's
clearly
as
a
certificate
of
the
Waypoint.
D
As
long
as
the
Waypoint
does
not
assume
that
open
requests
are
privileged,
then
I
think
we're
okay,
I,
don't
I,
don't
make
any
claims
that
it
does
it
or
not,
but
as
long
as
the
Waypoint
does
not
assume
that,
just
because
it
comes
from
the
G
tunnel,
it's
an
authenticated
connection.
Then
I
think
we're
good.
H
Okay,
my
experience
with
the
previous
chaining.
It
suggests
that
there
will
be
a
way
to
exploit
it.
I'll
wait
until
it's
implemented
and
then
I'll
try
to
see
if
I
can
break
it.
It's
it's
maybe
I,
don't
know
how
to
explain
it,
but
but
probably
could
have
easier.
B
G
H
I
mean
better
policy
will
be
broken
because
obviously
it
will
not
apply
it's
going
to
be
only
is
your
policy
where
we
cannot
apply
any
identity
based.
So
my
concern
with
network
policy
being
broken
is
a
network
policies
another
way
to
apply
policy
based
on
identity,
the
explicit
to
label
so
expresses
two
certificates,
but
it's
both
of
them
provide
rich.
You
know,
control
over
who's
allowed
and
who's
not
allowed.
H
G
Okay,
so
you
can
still
use
the
policy
on
The
Zeta
node,
that's
what
I
was
thinking
initially
on
the
Waypoint
I
agree
because
yeah,
because
the
halfway
added,
but
that's
not
unique
to
this
one.
It's
Unique
to
the
whole
ambient
architecture.
When
you
have
Waypoint
in
the
middle.
H
Agreed
I
mean
it's
I'm,
not
saying
it's,
so
it's
we.
The
user
has
a
clear
choice.
Either
it's
a
used,
Network
position.
They
use.
You
know
specific
based
policies
or
label-based
policies.
That's
kind
of
the
choice
for
identity
based
policies.
If
they
use
label
based
policies,
that's
wonderful!
If
they
work
no
problem,
it's
used,
PV
identities.
They
also
work.
H
H
G
F
D
Yeah
there's
no
switch
on
Waypoint
right
now.
The
original
ambient
API
stock
had
some
logic
about
different
about
essentially
implementing
peer
authentication.
Wait
no
yeah.
The
original
doc
has
had
some
information
about
how
peer
authentication
is
only
relevant
for
the
plain
text.
Port
of
zeotunnel,
not
the
h-bone
port
I.
Think
from
this
we
would
be
student
would
be
doing
age
bones
with
still
be
the
H
bone
Port,
but
we're
changing
the
type
of
TLS,
that's
being
or
it
wouldn't
be
neutral.
Tls
engage
from
Port.
F
Like
in
the
current
case,
traffic
from
a
waypoint,
if
the
tunnel
gets
traffic
from
a
waypoint,
it
doesn't
enforce
any
policy
at
all,
because
it
assumes
that
we
point
enforced
it
now.
The
layering
thing
should
address
that,
in
which
case
we're
going
to
need
to
have
Waypoint,
tell
us
the
identity
and
trust
it
probably
with
exported
client
sort
or
whatever,
at
which
point
it
would
not
put
an
identity
in
The
Hairpin
case
I,
think.
Does
that
make
sense.
D
D
C
F
F
D
Do
we
need
to
remove
okay,
yeah,
so
yeah?
That's
right!
If
it's
air
pinned
back
from
the
Waypoint,
we
don't
apply
any
polishing
the
Z
tunnel,
so
that
takes
care
of
that
case
and
if
there's
no
Waypoint,
then
Z
tunnel
would
still
apply
the
converted
peer
authentication
like
we
do
today
got
it.
Okay,
that
makes
sense.
D
Yeah
I'll
I'll
take
that
on
concluded
the
pure
authentication
stuff,
I'll
I'll
write
a
doc
for
how
it
currently
Works
and
then
let
me
get
with
Steven
to
make
sure
this
I
have
a
good
understanding
of
what's
being
proposed
here
and
at
that.
So
you
have
something
comprehensive.
G
H
They
have
some
legitimate
therapy
use
case.
I
mean
they
have
some
policies
that
allow
traffic.
Let's
say
you
have
I
mean
if
you
block
everything,
it's
fine,
but
if
you
have
someone
now
that
means
there
is
a
part
where
traffic
from
a
plane
to
export
goes
to
Port.
This
Mission
puts
them
to
Waypoint,
and
so
back.
H
That
means
that
anyone
else
can
pretend
to
be
the
you
know
original
Z
tunnel
inject
whatever
they
want
and
and
still
make
the
same
request
as
original
Port
we'll
go
to
the
Waypoint,
and
you
know
pretty
much
Forge
anything
else
that
was
part
of
the
protocol,
because
there
is
no
way
to
know
that
you
know
the
Z
tunnels.
That
originated
the
request.
Waypoint
is
really
easy
tunnel
and
not
something
else.
A
H
H
F
Yeah
I
think
a
kind
of
agreement
with
cops
and
there
are
some
cases
in
the
code
where
we
say
we
trust
this
header,
because
it's
from
the
Waypoint,
for
example,
we
have
exported
whatever
the
IP
is
exported
for
and
then
we
spoof
The
Source
IP.
F
F
F
F
F
To
say
it
would
be
invalid
to
say
the
request
came
from
the
Waypoint.
Therefore,
the
original
request
two
hops
back
was
from
someone
in
the
mesh
I.
Don't
hopefully
we
don't
do
that.
That
would
be
invalid,
I
think
if
the
Waypoint
told
us
that
with
exported
something,
then
I
think
that's
fine,
like
you
just
trust
the
last
hop
to
tell
us
what
we
should
trust
right.
We
shouldn't
implicitly
trust
more
than
that.
D
You
have
some
of
the
forges
the
appropriate
headers
to
make
it
look
like
the
previous
request
was
in
the
match.
How
do
we
actually
validate
essentially
I
think
what
this
boils
down
to
is:
how
did
the
way
port
and
Z
tunnel
validate
that
request
came
from
each
other?
Are
we
doing
any
kind
of
checks
to
to
confirm
that?
Well,.
F
That
part
that
part's
normal
playing,
m2s
identity
check,
we
have
a
waypoint
identity
and
Z
tunnel.
Identity
is
plural
and
we
check
they
check
each
other
I.
Think
constant's
concern
is
that
there
will
be
headers
from
the
initial
attackers
request
forwarded
from
the
Waypoint
to
Z
tunnel
and
Z10
will
trust
the
Setters
is
that
accurate.
H
Yes,
that's
in
the
same
category
with
all
the
you
know,
Ingress
exploits
and,
and
and
our
previous
you
know,
CDs
on
on
exported
foreign.
H
F
H
The
Gateway
is
doing
some
checks
on
on
the
you
know,
it's
not
accepting
expert
with
four
or
you
know
any
sensitive
header
or
nowadays
is
no
longer
replacing
that.
H
F
F
H
Required,
let's
find
some
people
with
real
security
experience
because
I'm
not
I'm,
not
it
just
feels
very
fishy
to
me
and
feels
like
a
repeat
for
previous
CVS.
That's
that's
my
my
concern
and
I.
Don't
think
we
are
going
to
start
it
out
in
this
meeting
where
I
am
going
to
be
the
best
one
to
exploit
it.
G
Now
costing
a
clarification
question
on
what
you
are
raising,
this
is
only
a
problem.
If
my
workloads
are
on
the
destination
say
you
know,
I
I
accept
if
I
impose
Mutual
TRS
through
pure
authentication.
This
is
not
a
problem
right.
It's
only
a
problem
if
I
don't
enforce
strict
maturity.
Hours
on
my
workload.
H
H
Problem
if
we
mess
with
plain
text
and
do
this
kind
of
stuff,
where
we
open
some
ports
without
training,
zero
trust
checks
and
where
you
know,
we
just
accept
TLS
traffic
from
random
people
with
no
checks,
and
then
we
treat
it
as
if
it's
coming
from
Z
panel
for
normal
ambient
or
both
ends
are
have
certificates
and
all
legs
are
authentic,
mutually
authenticated
and
we
have
real
translate
it's
it's
perfectly.
Fine
is.
F
F
D
D
F
G
Okay,
so
constant,
why
don't
you
maybe
offline
talk
to
security
Team
to
see
if
there's
any
other
concern,
if
only
if
what
you
raise
is
a
big
concern
and
then
maybe
Circle
back
with
the
team
next
week.
H
G
H
H
To
do
whatever
the
user
specifies
in
network
policy
not
intercepted,
not
touch
it.
The
option
is
to
not
intercept
traffic.
That
is
not
ours.
F
It
is
ours
because
we
deployed
a
waypoint,
that's
by
deploying
a
waypoint
you're
saying:
I
want
all
traffic
to
go
through
the
Waypoint,
and
if
you
don't
want
that,
then
don't
apply
Waypoint,
which
you
can
already
do
today.
I,
don't
think
we
should
violate
that.
That
I,
don't
know
whatever
you
call
it
statement.
G
H
You
have
local
traffic
that
is
not
going
to
be.
You
know
it's
going
to
be
cheap,
not
expensive.
You
have,
you
know,
Network
policies
that
applies.
There
are
plenty
of
benefits
of.
F
H
H
F
F
Would
be
less
concerned
about
something
like
a
server-side
policy
that
says
you
know
these
ports
are
Waypoint
enabled,
or
these
ones
aren't
than
doing
it
based
on
the
client
attributes,
whether
it's
TLS
or
not.
That's
fine,
like
opt
out
of
the
support
from
Waypoint
that
that
to
me
makes
a
lot
of
sense.
That's.
H
F
Yeah
I
guess
my
concern
was
yeah.
I
could
see
a
policy
that
you
specify
that
says
when
to
send
to
the
Waypoint
and
it
okay,
I'm
convinced
but
I,
don't
think
it's
something.
It's
an
additional
feature.
Sorry
I
think
I
agree
with
your
concerns
that
this
is
very
security,
sensitive
and
may
or
may
not
be
exploitable.
F
F
So
I
think
the
consensus
here
is
that
we
should
do
this
and
be
willing
to
do
more
and
look
into
it
more
to
improve
it.
Does
that
sound
right.