1. 1 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials draft-bajko-nsis-fw-reqs-01 Gábor Bajkó IETF Interim 23-24 May 2005

2. 2 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Scope of the work in 3GPP2 Make Firewalls MIPv6 compatible Being possible to contact/connect_to Mobile Nodes from outside the FW protected network and filter out unsolicited traffic to save bandwidth, and battery

3. 3 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Changes from version 00 Most of the SHOULDs changed to MUSTs Wildcard or address range is only needed for address, port, protocol and spi fields 2 new requirements added Reformulations, clarifications Lots of cleanups and editorials (non-relevant descriptive text and the annex have gone)

4. 4 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials The new requirements “It MUST be possible to open a pinhole with a single protocol request/response pair of messages. This is required because: a wireless link is a scarce and expensive resource (save bandwidth) real-time applications are delay sensitive” “A client MUST be able to fetch the list of all its installed pinholes at a given time from a Firewall” possible LI requirements charging aspects

5. 5 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials ‘Problematic’ requirements Some requirements do not fit with into the path-coupled scenario: A client MUST be able to close any or all the pinholes it created with a single protocol instance. A client MUST be able to refresh all associated pinhole timeouts with a single protocol instance. The protocol MUST allow an end point to create, modify or delete several firewall states with one protocol instance.

6. 6 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Important requirements Encapsulated packet filtering (n levels, n=2?) Mobile IP is extensively used and the tunnel between the HA and the MN should not be an entry point for unsolicited traffic The ability of opening a pinhole without knowing the address of the CN is a basic requirement

7. 7 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Standard use case Mobile Node hosts a server and installs a rule in the FW to be reachable by anyone Martin suggested to use UCREATE for this purpose, but: Section 2.9 reads: " The UCREATE mode is used to block a particular data flow on an upstream firewall.“ The use case require to install an ALLOW rule The “opportunistic address” does not have any relevance, as anyone should be able to contact the mobile node. The pinhole is not ment to allow SOMEONE specific to connect to the mobile node, but rather ANYONE should

8. 8 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Opportunistic address hints in section 3.7 Public IP address of the data sender N/A, as the sender is unknown Public IP address of the data receiver N/A, as it is its own one (no NAT) IP address of the Application Server N/A, as ASs are in most cases part of the same address space or protected network ‘Random’ Opportunistic Address might be a DoS against itself randomly selected IP addresses are blacklisted to help fight against scanning worms

9. 9 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Other protocol concerns “The CREATE/REA/UCREATE request message with a lifetime value of 0, does not generate any response, neither positive nor negative, since there is no NSIS state left at the nodes along the path” Carrying multiple objects in NSLP messages. E.g., CREATE[lifetime=0] for many flows at the same time. Security?