Melinda Shore [mailto:mshore cisco.com] wrote:
> On 5/30/07 5:32 PM, "Philip Matthews"
> <philip_matthewsmagma.ca> wrote:
> > I would be interested in hearing what you see as
the
> > deployment problems.
>
> Sure:
>
> You need to have something that can turn the message
around and
> provide a reply,
That would be a STUN server, in the case of today's STUN,
and also
in the case of draft-wing-behave-nat-control-stun-usage.
> or else you need to receive responses back from
> the middleboxes.
> The first option is unreliable
It is no more unreliable than other UDP-based protocols
(e.g., DNS).
> and the second
> option leads to the possibilities of message
proliferation and
> message expansion (since you can no longer rely on
packet rewriting
> as a way of propagating topological information).
Yep, and that's only necessary if the discovery process
includes firewall
discovery. It wasn't until -02 that firewall discovery was
in
draft-wing-behave-nat-control-stun-usage; prior to that the
document only
did NAT discovery which doesn't lead to expansion of the
response message to
discover on-path NATs.
I'm not sure what you're referring to with 'message
proliferation' -- is
that in relation to discovery or control of multiple
middleboxes, all of
which need to be discovered and controlled separately
causing proliferation
of messages to each of them, or referring to something
else?
> You need to have some way to secure messages when you
don't
> know in advance who you'll be sending messages
to/receiving
> messages from,
That is the substantial difference between
draft-wing-behave-nat-control-stun-usage and previous
attempts in this space
(e.g., UPnP, MIDCOM, NSIS).
With draft-wing-behave-nat-control-stun-usage, the security
model is easier
because you're using the same host port ('socket') to open
the NAT binding
as you're using to discover on-path NATs as you're using to
request the NAT
to extend its binding timeout. Most other approaches (e.g.,
MIDCOM and
NSIS) do need a more involved security model because they
need to create
some association between the host and its NAT and what the
host wants the
NAT to do. To another extreme, other approaches (e.g., UPnP
and NAT-PMP
(Bonjour)) allow any internal host to request and open any
NAT binding it
wants -- for other hosts or for other ports on the same
host.
This makes STUN, and STUN Control, unique -- in order to
open a binding for
a port, you need to send a packet from that port, and in
order to adjust its
binding duration you need to send a packet from that same
port and be able
to respond to the NAT's nonce challange. This means to
adjust someone's NAT
binding using draft-wing-behave-nat-control-stun-usage the
attacker needs
to be on-path between the host and its NAT -- such an
attacker is able to
already cause much harm to existing protocols such as DNS
and TCP which
cannot adequately defend themselves from that same on-path
attacker.
> and you'll be doing it in situations where you're
> trying to limit packet size (avoid UDP fragmentation)
draft-wing-behave-nat-control-stun-usage only increases
packet size with the
new 'tagging' feature, added in -02 to support Markus'
request for discovery
of on-path firewalls. This discovery adds 12 bytes to the
STUN Response
packet for every firewall that wants to be separately
controlled using STUN
Control. The typical STUN Response packet is approximately
150 bytes
(including IP and UDP headers). I think we're fine -- we
can have about 30
on-path firewalls before exceeding 512 bytes. (I chose 512
bytes because
that's what DNS chose and it seems reasonable.)
> and limit computational load (public key operations in
a
> middlebox). We found that group keys are an excellent
solution
> for use within a single security domain, but are
obviously
> unsuitable for use in situations in which you might be
crossing
> arbitrary administrative boundaries and can't know in
advance
> who they'll be.
STUN Control has no need for such heavy-handed security
because
each port on the host can only adjust its own bindings on
the
NAT.
Crossing administrative boundaries isn't possible with
typical
NAPTs because a packet has to originate from behind the
NAPT
in order to create the binding on the NAPT. Anyway,
handling
authorization across domains isn't related to what
draft-wing-behave-nat-control-stun-usage attempts to address
because a host can only control NAT bindings that it,
itself
created with its own UDP port. As the host didn't create
NAPT
bindings on public interfaces of another administrative
domain's
NAT, it cannot control them. The other administrative
domain
is responsible for its own policy -- just as today they are
responsible for whatever their NAT traversal scheme is (if
any)
and for keeping their NAT bindings alive (if any), their
own
HTTP proxies, and their own firewall policies and whatever
else
they like to run.
> One end or the other end has to have a public
address/presence.
> If neither end has a public address or presence, that
presence
> has to be outsourced to some other device. That often
means
> dropping yet another box (a relay, for example) into
both ends
> of the network. The placement of the relay has to be
topologically
> appropriate to the endpoints or else the relay ends up
being
> a sort of SBC.
>
> If you do go with a relay, you have to have some way to
associate
> it with the endpoint and you have to have some way to
publicize the
> association. The way that's typically handled right
now is through
> telephony signaling. In fact, this whole thing is
looking an
> awful lot like a VoIP network, and it's not actually
very useful
> for other applications. (Presumably that's the reason
for an
> interest in using STUN rather than an actual signaling
protocol,
> as well).
>
> It's doable, but it's not doable in a general way and
it's really
> going to work only in very constrained environments.
It's not an
> 80/20 solution, but rather a 20/80 one.
Your points in the above two paragraphs are related to ICE
and
if ICE determines (through its connectivity checks) that it
needs a
relay (a TURN server) or if ICE discovers (through its
connectivity
checks) if can establish connectivity without a relay using
IP
addresses learned via STUN. This is interesting but not
germane
to draft-wing-behave-nat-control-stun-usage.
Further, the existing deployments of ICE, on the Internet,
have
demonstrated it works 100% of the time.
I do hope the vendors that have shared that information with
me
privately are able to comment to that effect publicly in
this
thread.
> And, by the way, STUN would probably need substantial
changes
> to the protocol machinery in order to handle state
maintenance.
> Packetization is really not that interesting (a little
interesting,
> but not a lot) - what matters is how the protocol
behaves. "NAT
> control" installs state in middleboxes - you'll
need to be able
> to handle errors like transmission failures, device
reboots,
> routing changes, and so on. You'll also need to be
able to
> delete the state you install.
Merely sending a UDP or TCP packet across a NAT creates
state --
the NAT binding. All
draft-wing-behave-nat-control-stun-usage
does is query the NAT for its binding duration and provide a
way
to adjust that duration -- and that query and control is
only
for the same IP address and same UDP port that created that
initial state on the NAT.
> By the time you're done tweaking it so
> that it will be a useful state maintenance tool you'll
have a
> full-blown signaling protocol, only a quirky one that's
not
> very general and probably isn't very different from
other signaling
> protocols aside from packetization. (FWIW, a few years
ago I
> wrote up a "STUN-based Signaling"
specification that uses the NLS
> state machine but STUN packetization, and there should
still be
> copies floating around ID archives - it solves a
political problem
> but not a technical one and was rightly ignored).
draft-wing-behave-nat-control-stun-usage avoids this
complication
by using the same IP address and UDP port on the host that
created
the NAT binding.
> I could accept (and do accept) the argument that NSIS
is not a
> good choice for situations in which the substantial set
up costs
> can't be amortized well, but that's not the argument
that's being
> presented here.
>
> Anyway, the broader point is that we've already done
on-path
> signaling six ways from Sunday and the hard problems
association
> with NAT signaling remain unsolved. I have a hard time
seeing why
> it's a good idea to create yet another protocol while
continuing to
> avoid dealing with the problems associated with the
architecture.
-d
_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave
|
