Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN

From: Melinda Shore <[email-masked]>
Date: Thu, 25 Apr 2002 10:38:47 -0400

At 10:11 AM 4/25/02 -0400, [email-masked] wrote:
>Is there any reason that this 'address-reasonableness' test could not
>defined at least as an  option. I can see its utility especially in
>enterprise sites that will be implementing their own STUN servers

It doesn't require protocol changes.

I have to note that, to a large extent, enterprise sites implementing
their own servers somewhat defeats the purpose of the protocol.  
Otherwise it's just a somewhat gooby, kludgy midcom.

Melinda

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: [email-masked]
Date: Thu, 25 Apr 2002 10:11:39 -0400

"Pete Cordell" <[email-masked]>@ietf.org on 04/25/2002 07:00:01 AM

Sent by:  [email-masked]

To:   "Pete Cordell" <[email-masked]>, "Cullen Jennings"
      <[email-masked]>, "Sanjoy Sen" <[email-masked]>,
      "'Christian Huitema'" <[email-masked]>, "Peterson,
      Jon" <[email-masked]>, "Melinda Shore" <[email-masked]>
cc:   <[email-masked]>

Subject:  Re: [midcom] WGLC - Alternatives for 'securing' STUN

In addition to my suggestion of enabling the client to be able to test the
address that it has been given, it has been pointed out to me that the
client could simply check that the address that it has been given seems
reasonable (i.e. it corresponds to one of the public addresses of the
organisation.)

This would work well for fixed devices as the valid set of addresses can be
configured at installation time along with the domain.

For mobile users using hotel and airport NATs, there seems scope for
getting
the information from DHCP and DNS at the same time as trying to find out
the
location of the STUN server, but there might need to be a little more work
here.

These methods are orders of magnitude simpler than using CMS, and much more
in tune with the scale of STUN.  While they don't offer quite the same
protection, in some aspects they offer less, and others they offer more.

Therefore, I believe it's worth considering these options.  (Sometimes if
you find a big obstacle its best to try and find a way round it, rather
than
trying to smash your way through it!)

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================

----- Original Message -----
From: "Pete Cordell" <[email-masked]>
To: "Cullen Jennings" <[email-masked]>; "Sanjoy Sen"
<[email-masked]>; "'Christian Huitema'"
<[email-masked]>; "Peterson, Jon"
<[email-masked]>;
"Melinda Shore" <[email-masked]>
Cc: <[email-masked]>
Sent: 24 April 2002 18:41
Subject: Re: [midcom] Stun Security using TLS?

> Thinking aloud (i.e. without thinking it through!) another alternative
would
> be to devise a scheme that allowed a client to test a mapping.
>
> For example, it might be able to open another socket, and send a packet
to
> the mapped address.  In theory this ought exit the NAT and loop back in
on
> the NATted address and be sent back to the client.  If the client gets it
> back, it knows the mapping is genuine.
>
> I recall that someone (possible Christian) said that NATs don't generally
> support this type of loop back.  Is there another way of doing it?  I
> considered echo, but that doesn't seem to be widely deployed.
>
> Pete.
>
> =============================================
> Pete Cordell
> Tech-Know-Ware
> [email-masked]
> +44 1473 635863
> =============================================
>
> ----- Original Message -----
> From: "Cullen Jennings" <[email-masked]>
> To: "Sanjoy Sen" <[email-masked]>; "'Christian Huitema'"
> <[email-masked]>; "Peterson, Jon"
<[email-masked]>;
> "Melinda Shore" <[email-masked]>
> Cc: <[email-masked]>
> Sent: 24 April 2002 00:14
> Subject: [midcom] Stun Security using TLS?
>
>
> >
> > Would someone be willing to propose an strawman email on how we could
do
> > this using TLS?

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 25 Apr 2002 16:57:24 +0100

----- Original Message -----
From: "Melinda Shore" <[email-masked]>

> It doesn't require protocol changes.

That surely doesn't prevent it from being included in a security
considerations section.  In many respects running protocols over TLS doesn't
change the protocols themselves, but the issue is still discussed.

> Otherwise it's just a somewhat gooby, kludgy midcom.

It's simple and effective, and will probably achieve 90% of what can be
achieved with a CMS or TLS solution.

For something that is so much simpler than the other candidates, it needs
slightly more consideration than simply saying that it's gooby.  Rome wasn't
built in a day.  Who knows, Rome might have been gooby in the beginning
also.

Pete.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 25 Apr 2002 12:22:22 -0400

>built in a day.  Who knows, Rome might have been gooby in the beginning

I was referring to enterprises running their own STUN servers.

At any rate, while what you're proposing is a good idea in certain
deployments it's not a substitute for securing the STUN protocol,
which we *must* do.

Melinda