[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,
Thank you Robert for the clarification.
I agree with you. In addition to the sequence number, as you mentioned, firewall policies often include TCP flags.
It might be useful to extend the nat/fw nslp protocol to carry this information that is usually required by firewalls.
Franck
> -----Original Message-----
> From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig at siemens.com]
> Sent: 29 May, 2004 06:31 PM
> To: 'Hancock, Robert'; Le Franck (Nokia-NRC/Dallas);
> stiemerling at netlab.nec.de; nsis at ietf.org
> Subject: RE: [NSIS] New NATFW NSLP I-D:
> draft-ieft-nsis-nslp-natfw-02.txt
>
>
> hi robert,
>
> i fully agree with you.
>
> the proposed sequence number extension to the flow identifier would
> certainly go into the nat/fw nslp rather than in the ntlp.
>
> currently, we already have a few flow identifier related
> attributes (such as
> in the reserve mode case) which need to be carried in the
> nat/fw nslp.
>
> in the past we have also discussed whether we should carry an
> application
> identifier to provide "application layer" firewalls with additional
> information. we have dropped it since we wanted a simple
> version in the
> first place. anyway, there is room for extensions in the
> nat/fw nslp if
> people think that some additional functionality is needed.
>
> ciao
> hannes
>
>
> > -----Original Message-----
> > From: Hancock, Robert [mailto:robert.hancock at roke.co.uk]
> > Sent: Sonntag, 30. Mai 2004 00:02
> > To: Tschofenig Hannes; 'Franck.Le at nokia.com ';
> > 'stiemerling at netlab.nec.de '; 'nsis at ietf.org '
> > Subject: RE: [NSIS] New NATFW NSLP I-D:
> > draft-ieft-nsis-nslp-natfw-02.txt
> >
> > Hi all,
> >
> > a quick comment on the provision of N-tuples in GIMPS vs.
> > their provision in an NSLP.
> >
> > This question actually came up (from several sources) during
> > the framework development. The result of that discussion was
> > to make a firm distinction between:
> > 1) the information needed to route a signalling message, and
> > the information that a NAT needs to be able to rewrite, and
> > 2) additional information needed by an NSLP
> >
> > The hope/view is that (1) is fixed and fairly common to all
> > scenarios, but (2) could vary wildly. (1) is in GIMPS but (2)
> > is definitely not (and never should be). If more fine-grained
> > information is needed, then (2) has to be defined by the NSLP.
> > (Note that the NSLP should not define a complete classifier,
> > but just the 'extra bits'.) I can see firewall signalling
> > being a reasonable case of this: you often do see policies
> > expressed in terms of TCP flags, but it's very unlikely that
> > TCP flag setting would affect routing or be re-written by
> > NATs (that is, such information would never be part of (1)
> > and carried by GIMPS).
> >
> > r.
> >
> > -----Original Message-----
> > From: Hannes Tschofenig
> > To: Franck.Le at nokia.com; stiemerling at netlab.nec.de; nsis at ietf.org
> > Sent: 29/05/2004 22:31
> > Subject: 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
> >
> > --
> >
> > Visit our website at www.roke.co.uk
> >
> > Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
> >
> > The information contained in this e-mail and any attachments
> > is confidential to Roke Manor Research Ltd and must not be
> > passed to any third party without permission. This
> > communication is for information only and shall not create or
> > change any contractual relationship.
> >
>
>
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis