[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [NSIS] new draft about security threats for the NAT/firewall

To: "'Hancock, Robert'" <robert.hancock at roke.co.uk>, <Franck.Le at nokia.com>
Subject: RE: [NSIS] new draft about security threats for the NAT/firewall
From: "Hannes Tschofenig" <Hannes.Tschofenig at siemens.com>
Date: Tue, 15 Jun 2004 12:06:33 +0200
Cc: nsis at ietf.org
In-reply-to: <EA943CD30BCB104E9D38F5B5DC2D9A70019A061C@rsys004a.roke.co.uk>
List-help: <mailto:nsis-request@ietf.org?subject=help>
List-id: Next Steps in Signaling <nsis.ietf.org>
List-post: <mailto:nsis@ietf.org>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
Sender: nsis-bounces at ietf.org
Thread-index: AcROx/8v5YaK+MDZScizucKLZOaiTgD9LliA
hi robert, 
> hi,
> 
> i'll check if i understand correctly by asking 
> 
> Is this actually a generic threat which applies to any 
> firewall configuration method where the network 'behind'
> the firewall uses any mechanism for dynamic address 
> assignment (which could cause addresses to be re-assigned)?

my impression is that the same threat would be applicable if you use snmpv3
(midcom) to create your firewall pinholes. 

> 
> If so, we should document it (in that form).
i think we should.

> It may not be 
> specific to the NATFW NSLP; however, there may be deployment 
> considerations related to it which could usefully be captured 
> somewhere (in this case, I think it would be that there 
> should be some interdependency between the soft-state 
> lifetime of the address assignment mechanism and of the NATFW 
> NSLP state management.)
there is certainly a relationship between the soft-state and the natfw state
management. 

ciao
hannes

> 
> r.
> 
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig at siemens.com]
> > Sent: 09 June 2004 12:33
> > To: Franck.Le at nokia.com
> > Cc: nsis at ietf.org
> > Subject: RE: [NSIS] new draft about security threats for the 
> > NAT/firewall NSLP
> > 
> > 
> > hi franck,
> > 
> > thanks for your quick response. 
> > 
> > > Hi Hannes,
> > > 
> > > Thank you for your comments.
> > > 
> > > I agree with you that similar problem may exist with other
> > protocols. 
> > > However, the damages that can be caused by the NAT FW 
> NSLP protocol 
> > > can be more important since the NAT FW NSLP allows the 
> end node to 
> > > open any
> > > ports/pinholes: if the external node and the node within 
> the network 
> > > protected by the firewall are complices, they might create the 
> > > pinholes and specify the ports to launch attacks to 
> future victims.
> > 
> > i would like to avoid giving other people the perception 
> that we are 
> > creating a protocol which introduces new threats and 
> attacks which are 
> > not available today. we are not introducing new 
> vulnerabilities with 
> > the nat/firewall nslp. i think my ipsec example showed this. we are 
> > additionally not able to overcome the limitations of packet filters 
> > (if we only signal packet filters).
> > 
> > it is good to document this threat. after we listed all the 
> threats we 
> > need to think which threats are important to us and how we address 
> > them. therefore we will derive a few security requirements 
> and decide 
> > how to provide security mechanisms at the nat/firewall nslp.
> > 
> > > Such pinholes can be used to spread
> > > viruses, trojan horses or other malicious attacks.
> > the nat/firewall work cannot provide protection against 
> those attacks. 
> > however, other protocols cannot provide this capability either.
> > 
> > > Also the NAT FW protocol allows the end points to specify the 
> > > lifetime of the pinholes which may be set to an extended value.
> > yes, but the network nodes are allowed to modify the 
> lifetime. this is 
> > part of the authorization decision computed.
> > 
> > ciao
> > hannes
> > 
> > > 
> > > Would you agree?
> > > 
> > > Franck
> > > 
> > > > -----Original Message-----
> > > > From: ext Hannes Tschofenig 
> [mailto:Hannes.Tschofenig at siemens.com]
> > > > Sent: 08 June, 2004 11:14 AM
> > > > To: Le Franck (Nokia-NRC/Dallas)
> > > > Cc: nsis at ietf.org
> > > > Subject: RE: [NSIS] new draft about security threats for the 
> > > > NAT/firewall NSLP
> > > > 
> > > > 
> > > > hi franck,
> > > > 
> > > > i think it could be useful to add this issue to the threats
> > > document.
> > > > it would, however, be fair to state that it might be an 
> issue with 
> > > > other protocols as well.
> > > > 
> > > > ciao
> > > > hannes
> > > >  
> > > > > Hi Hannes,
> > > > > 
> > > > > I agree with you that the data sender can detect when 
> the data 
> > > > > receiver is replaced. However the data sender may be a
> > malicious
> > > > > node with bad intentions, and therefore may decide 
> not to stop 
> > > > > sending data but may take advantage of the pinholes to
> > > launch some
> > > > > attacks on the victim.
> > > > > 
> > > > > For the solutions, I was not suggesting any specific one.
> > > > > Actually, depending on the network environment, different
> > > solutions
> > > > > can most probably be adopted: if a network entity can
> > detect that
> > > > > the previous data receiver has disconnected and 
> released the IP 
> > > > > address (e.g. in 3G networks), the network entity could
> > > inform the
> > > > > firewall which will remove the pinholes.
> > > > > 
> > > > > But again, I was not suggesting any specific solution. I
> > > was instead
> > > > > wondering if such threat should be documented so that 
> people who 
> > > > > decide to deploy NAT FW NSLP can be aware of the
> > > potential threats
> > > > > and analyze solutions to prevent them.
> > > > > 
> > > > > Franck
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: ext Hannes Tschofenig
> > > [mailto:Hannes.Tschofenig at siemens.com]
> > > > > > Sent: 08 June, 2004 02:21 AM
> > > > > > To: Le Franck (Nokia-NRC/Dallas)
> > > > > > Cc: nsis at ietf.org
> > > > > > Subject: RE: [NSIS] new draft about security 
> threats for the 
> > > > > > NAT/firewall NSLP
> > > > > > 
> > > > > > 
> > > > > > hi franck,
> > > > > > 
> > > > > > i agree with you that this is a possible threat.
> > > > > > 
> > > > > > how imagine nsis uses where the data receiver does not
> > > > support nsis
> > > > > > (only the initiator and the firewall). the same situation
> > > > can occur
> > > > > > but this scenario shows more similarities with ipsec usage:
> > > > > > 
> > > > > > NSIS          ------------> NSIS     ----------->    Data
> > > > > > Initiator                   Firewall                Receiver
> > > > > > = IKE                       = IKE
> > > > > >  Initiator                  Responder
> > > > > > 
> > > > > > now, if the data receiver is replaced by some other
> > > entity (as you
> > > > > > described) then the data sender will just no recognize it.
> > > > > > application layer
> > > > > > interaction, however, will reveal this issue. 
> > > > > > 
> > > > > > the solution to this "problem" is: use end-to-end
> > > protected data
> > > > > > traffic.
> > > > > > this cannot be provided by nsis.
> > > > > > 
> > > > > > ciao
> > > > > > hannes
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Franck.Le at nokia.com [mailto:Franck.Le at nokia.com]
> > > > > > > Sent: Montag, 07. Juni 2004 16:09
> > > > > > > To: Tschofenig Hannes
> > > > > > > Cc: nsis at ietf.org
> > > > > > > Subject: RE: [NSIS] new draft about security 
> threats for the 
> > > > > > > NAT/firewall NSLP
> > > > > > > 
> > > > > > > Hi Hannes,
> > > > > > > 
> > > > > > > Thank you for your comments.
> > > > > > > 
> > > > > > > In addition to the potential threat discussed below, I
> > > > > was wondering
> > > > > > > if the following scenario, which does not seem to be
> > > > described in
> > > > > > > the draft, may represent another threat or not:
> > > > > > > 
> > > > > > > An external node in the Internet (node 1) may send a
> > > > > Create message
> > > > > > > to a node (node 2) protected by a firewall. Node 2 may
> > > > > reply with a
> > > > > > > Path Succeeded that will create the rules in the firewall
> > > > > (or vice
> > > > > > > versa i.e.
> > > > > > > node 2 sends the Create message and node 1 replies with
> > > > the Path
> > > > > > > Succeeded message).
> > > > > > > 
> > > > > > > Node 2 may then disconnect from the network (e.g. for
> > > mobility
> > > > > > > reasons, or deliberately) without sending a 
> Delete message.
> > > > > > > 
> > > > > > > The pinholes may therefore remain in the firewall 
> until the 
> > > > > > > expiration time which may be long.
> > > > > > > 
> > > > > > > If a node (node 3) arrives in the network protected by
> > > > > the firewall,
> > > > > > > it may be assigned the IP address previously allocated
> > > > to node 2.
> > > > > > > The external node (node 1) may then take advantage of the
> > > > > pinholes
> > > > > > > in the firewall to flood node 3, or launch other
> > > > attacks against
> > > > > > > node 3, depending on the installed firewall rules.
> > > > > > > 
> > > > > > > Would you agree that this scenario can represent 
> a threat? 
> > > > > > > Should it also be documented?
> > > > > > > 
> > > > > > > Franck
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: ext Hannes Tschofenig
> > > > > [mailto:Hannes.Tschofenig at siemens.com]
> > > > > > > > Sent: 30 May, 2004 02:42 PM
> > > > > > > > To: Le Franck (Nokia-NRC/Dallas); 
> ali.fessi at netlab.nec.de
> > > > > > > > Cc: nsis at ietf.org
> > > > > > > > Subject: RE: [NSIS] new draft about security
> > > threats for the
> > > > > > > > NAT/firewall NSLP
> > > > > > > > 
> > > > > > > > 
> > > > > > > > hi franck,
> > > > > > > > 
> > > > > > > > you are right with your observation that we have
> > envisioned
> > > > > > > scenarios
> > > > > > > > where the nsis nat/firewall signaling message needs to
> > > > > > traverse the
> > > > > > > > firewall to allow both endpoints to authorize 
> the creation
> > > > > > > of policy
> > > > > > > > rules. this circumstance might be exploited for the
> > > > attack you
> > > > > > > > mentioned.
> > > > > > > > 
> > > > > > > > regarding your reference to the "3GPP2 Network Firewall
> > > > > > > Configuration
> > > > > > > > and Control specification" document. i remember 
> that this
> > > > > > document
> > > > > > > > focused on scenarios which go beyond the functionality
> > > > > currently
> > > > > > > > offered by the current nat/fw nslp 
> specification. it might
> > > > > > > be useful
> > > > > > > > to see where nsis could be helpful.
> > > > > > > > 
> > > > > > > > ciao
> > > > > > > > hannes
> > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Franck.Le at nokia.com [mailto:Franck.Le at nokia.com]
> > > > > > > > > Sent: Samstag, 29. Mai 2004 00:00
> > > > > > > > > To: ali.fessi at netlab.nec.de
> > > > > > > > > Cc: nsis at ietf.org
> > > > > > > > > Subject: RE: [NSIS] new draft about security
> > > > threats for the
> > > > > > > > > NAT/firewall NSLP
> > > > > > > > > 
> > > > > > > > > Hello Ali,
> > > > > > > > > 
> > > > > > > > > Thank you for your reply.
> > > > > > > > > 
> > > > > > > > > I agree with you that a malicous node who wants to
> > > > > exhaust the
> > > > > > > > > battery and the network resources of a victim can use
> > > > > > any type of
> > > > > > > > > traffic to flood the victim. Most firewalls typically
> > > > > > > block incoming
> > > > > > > > > unsolicited data in order to avoid such threat. 
> > > > > > > > > (Unsolicited messages can actually create more
> > damages in
> > > > > > > cellular
> > > > > > > > > networks as outlined in the 3GPP2 Network Firewall
> > > > > > > Configuration and
> > > > > > > > > Control specification).
> > > > > > > > > 
> > > > > > > > > The natfw-nslp, on the contrary, require firewalls to
> > > > > > forward the
> > > > > > > > > nslp messages.
> > > > > > > > > Such requirement may therefore open the door for
> > > flooding.
> > > > > > > > > Since this requirement is specific of natfw-nslp and
> > > > > > > because of such
> > > > > > > > > requirement, this type of attack is possible, I was
> > > > > thinking it
> > > > > > > > > could useful to report the threat in the "Security
> > > > > > > Threats for the
> > > > > > > > > NAT/Firewall NSLP" draft or at least in the security
> > > > > > > consideration
> > > > > > > > > of the "NAT/Firewall NSIS Signaling Layer Protocol
> > > > > > (NSLP)" draft.
> > > > > > > > > 
> > > > > > > > > Would you agree?
> > > > > > > > > 
> > > > > > > > > Franck
> > > > > > > > > 
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: ext Ali Fessi [mailto:ali.fessi at netlab.nec.de]
> > > > > > > > > > Sent: 28 May, 2004 02:13 PM
> > > > > > > > > > To: Le Franck (Nokia-NRC/Dallas)
> > > > > > > > > > Cc: nsis at ietf.org
> > > > > > > > > > Subject: Re: [NSIS] new draft about security
> > > > > threats for the
> > > > > > > > > > NAT/firewall NSLP
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Hi Franck,
> > > > > > > > > > 
> > > > > > > > > > thanks for reading the draft and thanks for
> > > your feedback.
> > > > > > > > > > 
> > > > > > > > > > We focused the draft on the way how 
> unauthorized users
> > > > > > > > > could use the
> > > > > > > > > > natfw-nslp to install policy rules for their
> > advantage,
> > > > > > > > > since this is
> > > > > > > > > > our main concern.
> > > > > > > > > > 
> > > > > > > > > > About the threat that you suggested: i 
> think it is not
> > > > > > > > specific for
> > > > > > > > > > the natfw-nslp. You could flood the victim with any
> > > > > > > kind of data
> > > > > > > > > > traffic if you want to exhaust his battery or the
> > > > > > > > resources of his
> > > > > > > > > > access network.
> > > > > > > > > > i don't think that this threat fits well in the
> > > document.
> > > > > > > > > > 
> > > > > > > > > > ciao, Ali.
> > > > > > > > > > --
> > > > > > > > > > Ali Fessi
> > > > > > > > > > NEC Network Laboratories     Kurfürsten-Anlage 
> > > > 36, D-69115
> > > > > > > > > Heidelberg
> > > > > > > > > > Phone: (+49) 6221 9051151    Email: 
> > > > ali.fessi at netlab.nec.de
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Franck.Le at nokia.com wrote:
> > > > > > > > > > 
> > > > > > > > > > >Hello,
> > > > > > > > > > >
> > > > > > > > > > >Thank you for the internet draft. It is a good
> > > > > document that
> > > > > > > > > > can be helpful when designing the security
> > solutions for
> > > > > > > > the NAT/FW
> > > > > > > > > > NSLP. Many of the threats have been identified and
> > > > > > > described. The
> > > > > > > > > > following one is however not mentioned but might be
> > > > > > > relevant: The
> > > > > > > > > > NAT/FW NSLP requiring firewalls to forward NSLP
> > > > messages, a
> > > > > > > > > malicious
> > > > > > > > > > node may keep sending NSLP messages to a
> > > target. This may
> > > > > > > > > consume the
> > > > > > > > > > access network resources of the victim, drain the
> > > > > > > battery of the
> > > > > > > > > > victim's terminal and may force the victim to
> > > pay for the
> > > > > > > > received
> > > > > > > > > > although undesired requests (especially in cellular
> > > > > networks).
> > > > > > > > > > >
> > > > > > > > > > >Would you agree with this threat? Should it be
> > > > included in
> > > > > > > > > > the document as well?
> > > > > > > > > > >
> > > > > > > > > > >Thank you,
> > > > > > > > > > >
> > > > > > > > > > >Franck
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >  
> > > > > > > > > > >
> > > > > > > > > > >>-----Original Message-----
> > > > > > > > > > >>From: nsis-bounces at ietf.org
> > > > > > > > > > [mailto:nsis-bounces at ietf.org]On Behalf Of
> > > > > > > > > > >>ext Ali Fessi
> > > > > > > > > > >>Sent: 25 May, 2004 11:56 AM
> > > > > > > > > > >>To: nsis at ietf.org
> > > > > > > > > > >>Cc: Martin Stiemerling; Tschofenig Hannes
> > > > > > > > > > >>Subject: [NSIS] new draft about security
> > > threats for the
> > > > > > > > > > NAT/firewall
> > > > > > > > > > >>NSLP
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>Dear all,
> > > > > > > > > > >>
> > > > > > > > > > >>after some discussions within the NAT/firewall
> > > > NSLP team,
> > > > > > > > > we decided
> > > > > > > > > > >>to make a full analysis of the security
> > > threats for the
> > > > > > > > > NAT/firewall
> > > > > > > > > > >>NSLP before we continue.
> > > > > > > > > > >>
> > > > > > > > > > >>We submitted a new draft "Security Threats for the
> > > > > > > > > > NAT/Firewall NSLP".
> > > > > > > > > > >>
> > > > > > > > > > >>If you want to have a look at it before it becomes
> > > > > > > > > available in the
> > > > > > > > > > >>I-D repository, please have a look at:
> > > > > > > > > > >>
> > > > > > > > > > 
> > > > > > 
> > >>ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-fessi-nsis-na
> > > > > > > > > > >>tfw-threats-00.txt
> > > > > > > > > > >>
> > > > > > > > > > >>Comments are very welcome!!
> > > > > > > > > > >>Thanks,
> > > > > > > > > > >>Ali.
> > > > > > > > > > >>--
> > > > > > > > > > >>Ali Fessi
> > > > > > > > > > >>NEC Network Laboratories     Kurfürsten-Anlage 
> > > > > 36, D-69115
> > > > > > > > > > Heidelberg
> > > > > > > > > > >>Phone: (+49) 6221 9051151    Email: 
> > > > > ali.fessi at netlab.nec.de
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>_______________________________________________
> > > > > > > > > > >>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
References:
- RE: [NSIS] new draft about security threats for the NAT/firewall NSLP
  - From: Hancock, Robert
Prev by Date: RE: [NSIS] Another "Security Threats for NSIS" Draft Update
Next by Date: RE: [NSIS] new draft about security threats for the NAT/firewall NSLP
Previous by thread: RE: [NSIS] new draft about security threats for the NAT/firewall NSLP
Next by thread: RE: [NSIS] new draft about security threats for the NAT/firewall NSLP
Index(es):
- Date
- Thread