[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
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.
Should the Policy Rule Object be extended to allow more information to be carried?
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)
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 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.
Should the fields to carry the parameters to the firewalls be extended to allow other information to be carried?
Thank you,
Franck
> -----Original Message-----
> From: nsis-bounces at ietf.org [mailto:nsis-bounces at ietf.org]On Behalf Of
> ext Franck.Le at nokia.com
> Sent: 24 May, 2004 01:40 PM
> To: stiemerling at netlab.nec.de; nsis at ietf.org
> Subject: RE: [NSIS] New NATFW NSLP I-D:
> draft-ieft-nsis-nslp-natfw-02.txt
>
>
> Hello,
>
> Many deployment scenarios had been analyzed in details and
> important key issues had also already been identified and
> described in the previous version of the document. This new
> version of the document seems in addition more structured.
>
> I would have some questions to better understand the
> protocol, some comments and some suggestions.
>
> 1) Questions:
>
> a) How are the information (e.g. protocol type, port numbers)
> relating to the pinholes to be opened in the firewalls
> carried and described? The previous version described some
> Policy Rule Object. The new version of the document provides
> more details on the other objects (e.g. Session ID object,
> Session Lifetime Object, External address object, etc.) but
> does not seem to explain how the information related to the
> pinholes are carried.
>
> b) In section "A.1 Missing Network-to-Network Trust
> Relationship", it is stated that "Possibly peer-to-peer trust
> relationship does not exist because of the large number of
> networks and the unwillingness of administrators to have
> other network operators to create holes in their firewalls
> without proper authorization. Hence in the following scenario
> we assume a somewhat different message processing and show
> three possible approaches to tackle the problem. None of
> these three approaches is without drawbacks or constraining
> assumptions." but the three approaches description seems to
> be missing, unless I missed some part? Is that correct? Could
> you please describe them?
>
> 2) Suggestions
>
> a) As described in sections 1 and 2, a protocol to open
> pinholes can be very useful. It can help to open the required
> dynamic pinholes e.g. for SIP based applications. Actually it
> can also solve some of the problems that exist between the
> Mobile IP protocols and firewalls. Should we add this use
> case and add a reference to
> http://www.ietf.org/internet-drafts/draft-le-mip6-firewalls-00.txt?
>
> b) The NSLP protocol allows an end point to open pinholes in
> firewalls. Should this protocol also support the capability
> for end points to open pinholes in the scenarios where the
> end points do not know the correspondent nodes yet?
>
> This can be useful e.g. when an end point is in a network
> protected by a firewall and would like to host a server (e.g.
> HTTP) or run some peer-to-peer applications. Currently most
> firewalls would drop unsolicited incoming requests. Since
> NSLP is already allowing pinholes creation, I was thinking
> that it could be useful to extend the NSLP feature to support
> these scenarios.
>
> The 3GPP2 Network Firewall Configuration and Control (NFCC)
> work will probably study solutions to allow unsolicited
> incoming packets to reach the protected nodes and having the
> NSLP support such features can make this protocol to be
> adopted by 3GPP2.
>
> c) The NSLP protocol allows an end point to configure packet
> filters in a firewall (by creating, deleting and prolonging
> policy rules). Should the protocol allows an end point not
> only to open pinholes but also to install packets filters in
> the firewalls?
>
> The default policy may e.g. allow ICMP messages to reach the
> nodes but the end point may be in a cellular network where
> the air interface is a limited and expensive resource. The
> node may prefer not to receive Ping messages. Such capability
> would thus allow the nodes to install the desired packet
> filters in the firewalls so that undesired data are not sent
> over the air interface but dropped in the network. This is
> only an example of the possible use cases.
>
> 3) Comments
>
> a) Overbilling: the document seems to require middleboxes to
> forward NSLP messages. This may however be used by malicious
> nodes to flood a victim, and force, as in the 3GPP
> overbilling attack, the victim to pay for undesired received
> data. This may not be acceptable especially in cellular
> networks where the air interface is limited and subscribers
> have to pay for the bytes sent over the access link.
> Would it be possible to have the sender sign the NSLP
> messages and have the firewalls verify the authenticity
> before forwarding them? Or should we at least describe the
> threat in the security consideration?
>
> Thank you,
>
> Franck
>
> > -----Original Message-----
> > From: nsis-admin at ietf.org [mailto:nsis-admin at ietf.org]On
> Behalf Of ext
> > Martin Stiemerling
> > Sent: 21 May, 2004 08:46 AM
> > To: nsis at ietf.org
> > Subject: [NSIS] New NATFW NSLP I-D:
> draft-ieft-nsis-nslp-natfw-02.txt
> >
> >
> > Hi all,
> >
> > The latest version of the NATFW NSLP Internet draft has been
> > posted to the
> > I-D repository. You will find the draft here as well:
> >
> > ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-ns
> lp-natfw-02.t
> xt
>
> A html version is available here:
> http://www.stiemerling.org/nsis
>
> The major changes:
>
> - Document has been completely restructured, so that it is now more a
> protocol specification
> - Added bit definition of messages/objects
> - Added text parts on multiplexing, policy rules
> - Changed text to fit to new structure.
>
> I'll be away from email for the next week and being reachable
> by email
> beginning with the interim meeting.
>
> Regards,
>
> Martin
>
> _______________________________________________
> nsis mailing list
> nsis at ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis at ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis