[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
hi franck,
thanks for your feedback. please find my comments inline:
> 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 policy rule object is not required since it the flow identifier
information is included in the ntlp. this was a mistake in the prevous
version of the draft.
>
> Should the Policy Rule Object be extended to allow more
> information to be carried?
is the information included in section 5.2.2 of
http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-01.txt
(Flow-Routing-Information) sufficient?
>
> 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.
is see your scenario but do you think that the security threats are
considerable?
is there actually an api which allows to control a firewall at this level of
granularity?
> 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.
the ipsec-SPI parameter is supported.
>
> Should the fields to carry the parameters to the firewalls be
> extended to allow other information to be carried?
good question. i thought that we captured quite a number of use cases with
the parameters defined in gimps. i, however, agree that they currently do
not capture all possible scenarios.
ciao
hannes
>
> 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
>
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis