Hi,
1)
- With deny policy in the EFI : Add a DENY rule
- With allow policy in the EFI : Remove the previous DENY rule
The question is in the second case (allow-all policy, but allow in EFI): Who created the previous DENY rule? If the NATFW NSLP created it, then you should NOT remove this previous rule, because it will be removed by terminating the corresponding signaling session.
I was thinking to close the signaling session (time out not assumed) by explicitly removing the rule that was created.
I can not find another way to close it in NATFW specification. Is there some method to do it at GIST level?
For example if I created a deny rule, then by removing it should I close the session?
In your implementation (NatFwFsm.cpp) a rule is removed only if zero-lifetime is true. So it seems that you consider removing a rule only in the case that the session lifetime is zero.
2)
About EFI Object and sub_ports field.
sub_ports field is a number that is added to the port number to define a range of ports. In draft-ietf-nsis-nslp-natfw-13.txt the draft states that sub_ports must not be other value than 0 and 1. Nevertheless it could be handy to use any number and then use it to implement a port range in iptables when crating a FW rule....
Well, that is nothing we can decide. The authors of the draft have their reasons to limit the valid values to 0 and 1 and thus we should honor there decision.
Ok. My suggestion is mainly for testing, not to extend the protocol or go against. It is handy to take the opportunity that the field could be available and use any number. And then define a set of port numbers like 1024:65535 with Iptables.
If you use a web-browser or any other application and you want to do some tests or demo, you will need to know before hand the port number (origin port) that the application is going to use in order to set the FW. In my tests I harcoded the call to Iptables to skip the origin port and use 1024:65536 instead. Otherwise I had to spent more time sending an specific port number as a parameter and I had to tcdump all the time and check the port that is using my application. It could be a transitional solution. As nsis is not integrated to my browser, it could be an approach to introduce nsis without major requirements...(just an opinion).
3)
NSIS signaling (and thus the meaning on the NSLP layer) is uni-directional. Thus you are right, that one signaling session will only open one direction. You will have to initiate NSIS signaling from both sides (!) to open the pin hole if your data is bi-directional.
Ok. I forgot to mention that I am using the proxy mode (NI-NF-NF....NF-NF case , i.e. no NR).
As there is not NR in this case. How should be opened the pinholes in the reverse direction? Will the last FW behave as NI and send a CREATE? This case is not very clear in the specification. What my implementation is doing is calling to Iptables 2 times and allow traffic in both directions. I am non sure if my approach is OK.
Regards,
Sergio
nsis_imp@informatik.uni-goettingen.de