[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [NSIS] New NATFW NSLP I-D: draft-ieft-nsis-nslp-natfw-02.txt
--On Freitag, 28. Mai 2004 11:43 Uhr -0500 Franck.Le at nokia.com wrote:
| Hello,
|
| In addition to the comments sent earlier, please find some additional
| questions/comments.
|
| The new version (02) of the draft does not seem to describe how the
| pinholes are created (e.g. what parameters are included). The previous
| verion (01) described the Policy Rule Object, composed of the five
| parameters (Source IP address, Destination IP address, Transport
| Protocol, Source Port Number, Destination Port number) based on which
| firewalls decide to whether let the incoming packets pass, drop or log
| them.
The most information (source/destination) is carried within the NTLP. The
firewall rules or NAT binding information can extracted out of this.
|
| Should the Policy Rule Object be extended to allow more information to be
| carried?
That is the current intention of the policy rule object.
|
| Current firewall technology typically perform many more operations than
| filtering based on the 5 parameters described above. As an example most
| firewalls today perform TCP Sequence Verifier. Most firewalls (e.g. Check
| Point FireWall-1 NG FP3) include a Sequence Verifier feature: it watches
| all traffic flows going through the gateway and keeps track of the
| Sequence Numbers in the packets. If it sees a packet is received with an
| incorrect sequence number, the Enforcement Point (i.e. the FW) will
| consider the packet out of state and drop the packet. Firewalls typically
| learn the values of the TCP sequence numbers by analysing the TCP
| connection set up messages (TCP SYN, TCP SYN ACK and TCP ACK)
TCP sequence numbers are subject to firewall internal logic and in my
opinion not part of the pinhole signaling.
|
| Now, assuming a node (Terminal 1) in a network protected by a Firewall.
| Let's assume that the Terminal 1 moves to a different subnet protected by
| a new firewall, and changes its IP address from IP1 to IP2. By using the
| NATFW NSLP protocol, it may create the necessary packet filters in the
| new firewall to let incoming packets to IP2 pass through the firewall.
| However, NSLP currently does not allow the TCP Sequence numbers of the
| flows to be included. The new firewall will thus not be able to perform
| TCP Sequence verification, and the potential threats/attacks against the
| users may increase. The firewalls may not be able to perform the
| operations that they currently typically perform.
The question in my mind: Moving sequence numbers from one box to another is
more in the context of seamoby's context transfer? Right now, I do not see
why NSIS NATFW NSLP should take care about this.
|
| The TCP sequence number is just an example. The end point may also be
| using IPsec and may therefore want to filter based on the Security
| Parameter Index value. A code indicating SPI, and followed by the SPI
| value would allow the UE to request the FW to filter based on this
| parameter.
SPI is different than TCP sequence numbers and is already handled by NTLP
specification.
|
| Should the fields to carry the parameters to the firewalls be extended to
| allow other information to be carried?
The idea is good, but we have to sort out which further information for
firewalls/NATs are useful and not covered by other areas.
Thanks,
Martin
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis