Mailing List Archive: what about making OSPFAPI port usage configurable?

what about making OSPFAPI port usage configurable?

amir at datacore

Feb 13, 2004, 6:32 AM

Post #1 of 8 (1656 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ralph, Hasso, Paul,

Not long ago Hasso talked to me about OSPFAPIs port usage and asked me
if there is a way to choose which ports OSPFAPI uses for his two
connections between OSPFD and the OSPFAPI client.

Hasso proposed to make the port usage configurable, and I think that's a
reasonable request and should not be hard to implement. It's even quite
simple...

I would propose that Paul exports two defines from configure.ac which
have the default 2606 and 4005 and which can be changed by two:

- --with-ospfapi-port 2607
- --with-ospfapi-backport 4005

Then Ralph could use the above two defines as the port numbers used by
OSPFAPI.

- - Amir
- --
Amir Guindehi, nospam.amir@datacore.ch
DataCore GmbH, Witikonerstrasse 289, 8053 Zurich, Switzerland

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-nr1 (Windows 2000)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFALNIFbycOjskSVCwRArdSAKDhZExjhlbrytl3eW18SCnU9B0yEACeIW/C
kupEKFDh0FLwyZLjzyOyMOc=
=euQ+
-----END PGP SIGNATURE-----

Re: what about making OSPFAPI port usage configurable? [ In reply to ]

hasso at estpak

Feb 13, 2004, 6:58 AM

Post #2 of 8 (1636 views)

Amir Guindehi wrote:
> Hi Ralph, Hasso, Paul,
>
> Not long ago Hasso talked to me about OSPFAPIs port usage and asked
> me if there is a way to choose which ports OSPFAPI uses for his two
> connections between OSPFD and the OSPFAPI client.
>
> Hasso proposed to make the port usage configurable, and I think
> that's a reasonable request and should not be hard to implement.
> It's even quite simple...

No. Seems that you misunderstood. My idea was to make address and port
configurable at ospfd launch time with option to disable port
listening at all - a la:

ospfd -d --ospf-api-port 2700 --ospf-api-address 127.0.0.1

Setting port to 0 will disable port listening at all.

--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator

Re: what about making OSPFAPI port usage configurable? [ In reply to ]

Feb 13, 2004, 7:38 AM

Post #3 of 8 (1638 views)

ospfd -d --ospf-api-port 2700 --ospf-api-address 127.0.0.1

Setting port to 0 will disable port listening at all.

That sounds good. Also, it would be really nice to have this be over
AF_LOCAL. While I realize that remote access is sometimes useful,
without strong authentication it is unsafe and SHOULD NOT (ietf-speak)
be enabled by default, even if ospfapi support is compiled in.

(Actaully, the same goes for vtys - those should be bound to ::1 and
127.0.0.1 only - it is annoying to have to firewall them.)

--
Greg Troxel <gdt@ir.bbn.com>

Re: what about making OSPFAPI port usage configurable? [ In reply to ]

hasso at estpak

Feb 13, 2004, 7:49 AM

Post #4 of 8 (1644 views)

Ühel kenal päeval (reede, 13. veebruar 2004 16:37) kirjutas Greg
Troxel:
> ospfd -d --ospf-api-port 2700 --ospf-api-address 127.0.0.1
>
> Setting port to 0 will disable port listening at all.
>
> That sounds good. Also, it would be really nice to have this be
> over AF_LOCAL. While I realize that remote access is sometimes
> useful, without strong authentication it is unsafe and SHOULD NOT
> (ietf-speak) be enabled by default, even if ospfapi support is
> compiled in.
>
> (Actaully, the same goes for vtys - those should be bound to ::1
> and 127.0.0.1 only - it is annoying to have to firewall them.)

You can do it with vtys (-A and -P), but you can't with ospfapi. Yes,
I can disable ospfapi at all in compile time, but most of users use
packages.

--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator

Re: what about making OSPFAPI port usage configurable? [ In reply to ]

Feb 13, 2004, 8:36 AM

Post #5 of 8 (1639 views)

On Fri, 13 Feb 2004, Greg Troxel wrote:

> That sounds good. Also, it would be really nice to have this be
> over AF_LOCAL.

Eek yes. Though, doesnt SRRD use OSPF-API to provide an OSPF looking
glass?

> While I realize that remote access is sometimes useful, without
> strong authentication it is unsafe and SHOULD NOT (ietf-speak) be
> enabled by default, even if ospfapi support is compiled in.

You do not need strong auth to unprivileged information though. Eg,
web servers :)

> (Actaully, the same goes for vtys - those should be bound to ::1 and
> 127.0.0.1 only - it is annoying to have to firewall them.)

They can easily be, and are in the RPMs.

Also, the vty is easily capable of denying access by way of a
prefix-list.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Honk if you love peace and quiet.

Re: what about making OSPFAPI port usage configurable? [ In reply to ]

amir at datacore

Feb 13, 2004, 8:47 AM

Post #6 of 8 (1638 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Paul,

>>That sounds good. Also, it would be really nice to have this be
>>over AF_LOCAL.
>
> Eek yes. Though, doesnt SRRD use OSPF-API to provide an OSPF looking
> glass?

Yes, it does. But for that it only needs access to the _local_ ospf
daemon. SRRD use the OSPFAPI port over 127.0.0.1 and be happy.

>>While I realize that remote access is sometimes useful, without
>>strong authentication it is unsafe and SHOULD NOT (ietf-speak) be
>>enabled by default, even if ospfapi support is compiled in.
>
> You do not need strong auth to unprivileged information though. Eg,
> web servers :)

Yes, but OSPF can do md5 auth. A form of protection would not be bad.

Cheers
- - Amir
- --
Amir Guindehi, nospam.amir@datacore.ch
DataCore GmbH, Witikonerstrasse 289, 8053 Zurich, Switzerland

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-nr1 (Windows 2000)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFALPF7bycOjskSVCwRAnGOAJ4iA2Uv/OQcxP5wiaT9FzCj4lMSaQCfSXm7
FFjPWp1KxfrlbAuBDIU2abw=
=n5mg
-----END PGP SIGNATURE-----

Re: what about making OSPFAPI port usage configurable? [ In reply to ]

Feb 13, 2004, 8:52 AM

Post #7 of 8 (1639 views)

You do not need strong auth to unprivileged information though. Eg,
web servers :)

Sure, but routing info is perhaps privileged; it depends on who owns
it and how paranoid they are. I don't want the world connecting into
my router to look at the current LSA dtabase. Certainly injecting
opaque lsas should be a privileged operation.

So arguably the ospfapi interface should have an acl as well.

They can easily be, and are in the RPMs.

Not quite:

> zebra -A ::1 -A 127.0.0.1

and then only the v4 addr works (because it was last, I suspect).

Also, the vty is easily capable of denying access by way of a
prefix-list.

sure, but the default doesn't do that, and my general policy is not to
let demons talk to the net at all unless it is necessary - there could
be an exploitable bug in the vty deny code (probably not, though).

I know, I should stop whining and write the necessary code.
One needs to have multiple sockets for vty/etc. to bind to multiple
localhost addrs, have a 'all' keyword to get back *, and then make
localhost only the default.

Re: [srrd-dev 28] Re: Re: what about making OSPFAPI port usage configurable? [ In reply to ]

Feb 13, 2004, 9:06 AM

Post #8 of 8 (1638 views)

On Fri, 13 Feb 2004, Greg Troxel wrote:

> Sure, but routing info is perhaps privileged; it depends on who
> owns it and how paranoid they are.

hence the simple password?

> I don't want the world connecting into my router to look at the
> current LSA dtabase. Certainly injecting opaque lsas should be a
> privileged operation.

OSPF-API - definitely!

> Not quite:
>
> > zebra -A ::1 -A 127.0.0.1
>
> and then only the v4 addr works (because it was last, I suspect).

Hmm.. no idea really.

> sure, but the default doesn't do that,

It does. If you install the RPM (eg RedHat, or the next Quagga RPM
release) it is installed so by default.

> and my general policy is not to let demons talk to the net at all
> unless it is necessary - there could be an exploitable bug in the
> vty deny code (probably not, though).

> I know, I should stop whining and write the necessary code. One
> needs to have multiple sockets for vty/etc. to bind to multiple
> localhost addrs, have a 'all' keyword to get back *, and then make
> localhost only the default.

Actually, what I think is needed is for the listening to be
controlled by 'line vty', just like IOS. Perhaps with an enhancement
to allow one to specify the listen address.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
When the speaker and he to whom he is speaks do not understand, that is
metaphysics.
-- Voltaire