Subject: [NSIS] NATFW and the GIST API

From: Matthias Friedrich <[email-masked]>
Date: Mon, 26 Jun 2006 18:03:19 +0200

Hi,

I'm currently implementing the NATFW draft and have a problem with the
GIST API version 09.

A NATFW implementation needs to know from which network interface a
received message came from. This is to check if a message came from
the inside or from outside of the local domain or from the public or
private side of a NAT. However, this information isn't available in the
RecvMessage primitive (see B.2.).

I hacked our local GIST implementation to give me the IP address of the
network interface that received the message, which is easily available.
How did others solve this problem? Did I overlook something or should
the GIST API be extended?

While I'm at it: The MessageStatus primitive (B.3.) would be far more
useful to me if it also gave me the session ID. It would save me from
keeping track of message handles which is overkill in my situation.

Thanks for reading,
	Matthias

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

---

From: Henning Peters <[email-masked]>
Date: Mon, 26 Jun 2006 21:05:15 -0400

Matthias,

your observation is correct. I remember that we discovered this issue 
last fall similarly while implementing NAT/Firewall NSLP and raised 
discussion for an API change.

While I forgot the final outcome of the API discussion (I hope GIST 
folks have not?!), I know that our workaround is based on configuration. 
We simply maintain a mapping between IP addresses and private/public 
interface (see example conf attached, look for natfw.isPrivateNet option)

Extending the API with the network interface (how do you define this?) 
might not be expressive enough, adding the receiving IP address is not 
necessary and creates ambiguity. A boolean variable (private/public) 
would suffice for protocol operation.

It should be also noted that for non-hierarchical NAT operation a 
heuristical approach based on RFC1918 could be used.

I would still favor the API change, though, because it cleanly decouples 
GIST and NAT/Firewall NSLP depedency and minimizes redundancy in a 
configuration-based approach.

Henning

example Göttingen GIST + NAT/Firewall NSLP 0.4.0 configuration snippet:

%<------
# The first entry is meant as a default route. It is used when
# no subsequent entry matches.
IPv4[0].addr = 10.0.0.1
IPv4[0].net  = 0.0.0.0
IPv4[0].mask = 0
# Use this address as the external address for NatFW NSLP
IPv4[0].natfw.useAsExternalAddress = yes
# Default network is public (i.e. the global internet)
IPv4[0].natfw.isPrivateNet = no

# This entry defines the outgoing local interface card
IPv4[1].addr = 192.168.0.1
# These entries define the network segment you want to reach
# with the previously defined outgoing interface card
IPv4[1].net  = 192.168.0.0
IPv4[1].mask = 24
# The network 192.168.0.0/24 is private
IPv4[1].natfw.isPrivateNet = yes

# The second network (192.168.1.0/24) uses the SAME outgoing
# interface again.
IPv4[2].addr = 192.168.0.1
IPv4[2].net  = 192.168.1.0
IPv4[2].mask = 24
# The network 192.168.1.0/24 is private
IPv4[2].natfw.isPrivateNet = yes
------>%

---

From: Matthias Friedrich <[email-masked]>
Date: Tue, 27 Jun 2006 08:16:48 +0200

Hi,

> discussion for an API change.

Ah, very well, thank you.

> would suffice for protocol operation.

The first thing I had in mind was to extend the API to give me the
network device identifiers (eth0 is public, eth1 is private, etc.), but
they are highly unportable. The IP address of the network interface that
received a message is easily accessible using the socket API.

A private/public boolean variable would hand the problem off to GIST and
would require configuration on GIST level because you can't always be
sure that only RFC1918 addresses are used on the private side. Because
of this, I like your configuration based address matching better.

At the moment, I'm not sure which approach to use, but I don't have to
decide it immediately.

Regards,
	Matthias