Subject: RE: [NSIS] NATFW and the GIST API

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 4 Jul 2006 12:36:54 +0100

hi all,

it seems reasonable to me to add something about the receive
interface to RecvMessage. I am tempted to leave the detailed
syntax open in the spec, but my preference would be for GIST
to classify the interface according to some logical rather than
physical aspects. see the new open issue
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue110

i'd rather however leave the MessageStatus as it is. logically
it is a call about a particular message and the message handle
is precisely what is needed (no more, no less). if there is some
special reason why it is overweight in particular cases there is
no rule not to hack the api, e.g. put the session id in the 
message handle :-)  but once you put the SID in, there is no 
reason not to put everything else about the message in as well.

robert h.

> -----Original Message-----
> From: Matthias Friedrich [mailto:[email-masked]] 
> Sent: 27 June 2006 07:17
> To: Henning Peters
> Cc: [email-masked]
> Subject: Re: [NSIS] NATFW and the GIST API
> 
> 
> Hi,
> 
> On Monday, 2006-06-26, Henning Peters wrote:
> > 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.
> 
> Ah, very well, thank you.
> 
> > 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.
> 
> 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
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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