How I Implemented a CALEA Solution (With Juniper JUNOS)

The following information was first published on 11/15/2007 at http://www.unixadmin.cc/calea/
CALEA is an acronym for, “Communications Assistance for Law Enforcement Act“. Enough time has passed that an update to this document is needed. The following should be considered historical.

Header

  • Draft Version: 0.1.2
  • Service: Flow-Tap, IPSec and Dynamic Tasking Control Protocol (DTCP)
  • Operating System: Juniper JUNOS 8.2R2.4
  • Draft Date: 11/15/2007
  • Last Updated: 1/3/2012

As of right now (1/14/2008)… flow-tap does not work if the ip-sec tunnel to the mediation device is configured on the same router. From what I understand, this is supposed to be fixed down the road, but as of now this issue renders this solution useless unless the VPN tunnel is relocated to another router/device. I relocated the VPN tunnel on my network and it worked well for my needs. This issue was discovered during testing. Only after working with JTAC was it learned that the issue existed.

Preamble

These are my notes from how I implemented CALEA capabilities on a Juniper Networks router.

During the last several months I did not have a readily available resource (of any type, human or document) which explained how to take the existing IP network I manage and re-engineer it to provide CALEA intercept capabilities.

I would like to stress that there is a difference between a basic packet capture with a protocol analyzer and a purpose built intercept mechanism; whether that mechanism be an appliance or daughter-card installed into a router chassis. Intercept depth and duration can very per intercept warrant.

Let me say now that I am very open to constructive criticism. I do not know everything, and do not imply nor suggest such. Please send your correction, suggestion or comment.

There are several facets to CALEA and this document only covers the IP aspect from a narrow point of view, mine. Please see the reference section for links to Internet destinations concerning CALEA.

The content in this document is NOT intended to explain all the aspects of CALEA, which I know I can not possibly do anyway, nor is it trying to present a complete definition of all CALEA components.

The most current version of this document may be found at http://pileofbits.com

Creative Commons License
The blog post content for “How I Implemented a CALEA Solution (With Juniper JUNOS)” is licensed under a Creative Commons Attribution 3.0 License off site link.
Please provide the following attribution if you copy or distribute the contents of this particular blog post in whole or part:
“Original content by Jeff Neuffer Jr (jneufferjr@gmail.com) located at http://pileofbits.com

Abstract

The following example has been applied to multiple autonomous system edge routers, however the example in this document will show a single router.

The following definitions are used…

  • AS: Autonomous System
  • Hair-pin IP flows: Traffic that originates and terminates on the same router. Traffic does not traverse the network outside of this physical chassis.
  • DTCP: Dynamic Tasking Control Protocol, Intercept Commands issued via DTCP
  • NE: Network Element, in this case my router
  • Entities
    • TTP: Trusted Third Party
    • NETOP: Network Operator (my employer/me)
  • IKE Security Association End Point (AKA IPSec Gateway):
    • TTP IKE security-association: 123.123.123.123/32
    • NETOP IKE security-association: 100.100.100.100/32
  • IPSec Security Association (what qualifies to be sent over the IPSec tunnel):
    • TTP IPSec Encryption Domain: 2.2.2.0/27
    • NETOP IPSec Encryption Domain: 100.100.100.101/32
  • SSH End Point
    • TTP Mediation Device: 2.2.2.2.2
    • NETOP NE: 100.100.100.101/32

The NETOP has contracted with a TTP.
The TTP demands the type of VPN be that of a Lan-2-Lan/Site-2-Site only.
All physical interfaces on the NE are public.
NE is used soley for IP transit to and from the Internet.
The NE has full BGP routes from it’s eBGP and iBGP peers.
The NE has an AS-II PIC installed.
DTCP is tunneled via an SSH connection.
IPSec tunnels are used to transport the SSH protocol.
IPSec tunnels are used to transport the intercepted data back to the TTP’s mediation device.
IPSec tunnels are terminated directly to the NE.
SSH connections are terminated directly to the NE.
DTCP and SSH are considered control plain operations in this document.
IPSec is considered the data plain in this document.

Router Diagram

Logical representation of packet encapsulation, command/control communication, and subscriber packet flow over network device

Flow-Tap Configuration

These are the additional commands I added to my existing configuration.

system { login { class ft-class { permissions [ flow-tap flow-tap-control flow-tap-operation ]; } user ft-ttp { uid 2200; class ft-class; authentication { encrypted-password "password_for_ft-ttp"; } } services { flow-tap-dtcp { ssh { connection-limit 5; rate-limit 5; } } } } chassis { fpc 0 { pic 3 { adaptive-services { service-package layer-3; } } } } interfaces { sp-0/3/0 { unit 0 { description "For Flow-Tap"; family inet; } } } services { flow-tap { interface sp-0/3/0.0; } }

IPSec Configuration

Firewall filters need to permit the following protocol/port values: TCP/32001 (SSH) UDP/1814 (DTCP) ESP (IPSec)

I’ve been asked in the past what defines the DTCP port value above (1814).  It is defined in draft-cavuto-dtcp-03.txt in section 6.5 “No specific port”.  The draft leaves it up to the implementers (vendors) to choose which port the DTCP server binds to.

interfaces { sp-0/3/0 { unit 1 { description "For IPSec TTP"; family inet; service-domain inside; } unit 2 { description "For IPSec TTP"; family inet; service-domain outside; } } lo0 { unit 0 { family inet { /* this address was already present and is primary */ address 100.100.100.101/32 { primary; } /* this address was added just for the VPN */ address 100.100.100.100/32; } } } } routing-options { static { /* 2.2.2.0/27 is a TTP-CALEA related prefix */ route 2.2.2.0/27 next-hop sp-0/3/0.1; } } services { service-set IPSEC-TTP-Company-1 { next-hop-service { inside-service-interface sp-0/3/0.1; outside-service-interface sp-0/3/0.2; } ipsec-vpn-options { local-gateway 100.100.100.100; } ipsec-vpn-rules To-TTP-Company; } ipsec-vpn { rule To-TTP-Company { term 1 { from { source-address { 100.100.100.101/32; } destination-address { 2.2.2.0/27; } } then { remote-gateway 123.123.123.123; dynamic { ike-policy 123_123_123_123; ipsec-policy dynamic-policy-1; } } } match-direction input; } ipsec { proposal dynamic-1 { description "Mimick TTP Company Phase 2"; protocol esp; authentication-algorithm hmac-sha1-96; encryption-algorithm 3des-cbc; lifetime-seconds 3600; } policy dynamic-policy-1 { proposals dynamic-1; } } ike { proposal proposal-1 { description "Mimick TTP Company Phase 1"; dh-group group2; authentication-algorithm sha1; encryption-algorithm 3des-cbc; lifetime-seconds 86400; } policy 123_123_123_123 { mode main; proposals proposal-1; pre-shared-key ascii-text "a_password_here"; } } } }

Verify IPSec

Verify the IPSec tunnels by manually generating some traffic.

operator@router> ping source 100.100.100.101 2.2.2.2 operator@router> show services ipsec-vpn ike security-associations Remote Address State Initiator cookie Responder cookie Exchange type 123.123.123.123 Matured 2d79657b04657b2f 9a5223ce9a529048 Main operator@router> show services ipsec-vpn ipsec security-associations Service set: IPSEC-TTP-Company-1, IKE Routing-instance: default Rule: To-TTP-Company, Term: 1, Tunnel index: 1 Local gateway: 100.100.100.100, Remote gateway: 123.123.123.123 IPSec inside interface: sp-0/3/0.1, Tunnel MTU: 1500 Direction SPI AUX-SPI Mode Type Protocol inbound 4075957595 0 tunnel dynamic ESP outbound 3306433064 0 tunnel dynamic ESP

Miscellaneous Notes

Coverage of the IP Network

I work for a small ISP; at the time this document was drafted, the IP coverage of this solution is roughly 80% to 90% converage. The setup used in this document is applied at the AS edge which should explain why 100% IP converage is not realized. “Hair-pin” IP flows are not accounted for and neither are inter-AS IP flows.

Appendix – References and Credits

References:

  1. Trademarks Related: JUNOS and JUNOSe are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
  2. JUNOS 8.2 – Flow-Tap Configuration Guidelines
  3. JUNOS 8.2 – IPSec Services Configuration Guidelines
  4. http://www.fcc.gov/calea/
  5. http://www.askcalea.net/
  6. http://www.opencalea.org/
  7. http://www.nanog.org/meetings/nanog19/abstracts.php?pt=MTA5OSZuYW5vZzE5&nm=nanog19 – Impact of CALEA on Network Operators
  8. http://www.tiaonline.org/standards/technology/calea/
  9. RFC2804 – IETF Policy on Wiretapping
  10. DTCP, see draft-cavuto-dtcp-03.txt at http://tools.ietf.org/html/draft-cavuto-dtcp-03

Contributed Credits:

  • None

Appendix – To do

Maybe expand on “hair-pinning” solutions once a solution is understood or concieved. Presently exploring MPLS-TE approach, however a preliminary concern with MPLS is not knowing if Flow-tap filters will extract an IPv4 datagram from an LSP.

Appendix – Change log

1/13/2008 – Added the following warning to the top of the howto. “As of right now… flow-tap does not work if the ip-sec tunnel to the mediation device is configured on the same router. From what I understand, this is supposed to be fixed down the road, but as of now this issue renders this solution useless.

1/3/2012 – Several spelling corrections.  Moved content over to a blog.
1/5/2012 – Several formatting and typo corrections
2/11/2013 – fixed formatting issues

3 comments

  1. Hi,I am trying to implement CALEA solution for my client with Junos 13.2 and having an MS-MIC-16G ,but I am not getting all the options for configuration for flow-tap as you did.
    Also another query is ,do we always require IPSec to be configured for implementing CALEA solution in the Junos devices?

    1. No, IPSec is not required, unless it is specified as an implementation requirement (policy). In the blog example it was a requirement for transporting the copied data over the Internet to the cloud.

      Flow Monitoring concepts are here,
      http://www.juniper.net/techpubs/en_US/junos14.2/information-products/pathway-pages/solutions/flow-monitoring/flow-monitoring.html

      The MX supports Active Flow Monitoring which provides FlowTap or FlowTapLite processing.

      FlowTap configuration example is here,
      http://www.juniper.net/techpubs/en_US/junos14.2/topics/task/configuration/flowmonitoring-active-flow-tap-interface-solutions.html

      FlowTapLite uses virtual tunnel interfaces and does not require a services card. However there are restrictions and the docs cover the restrictions.
      FlowTapLite configuration example is here,
      http://www.juniper.net/techpubs/en_US/junos14.2/topics/usage-guidelines/services-configuring-flowtaplite.html

      Here is a Juniper published configruation example focused on Lawful Intercept using FlowTap in PDF format,
      http://www.juniper.net/techpubs/en_US/release-independent/nce/information-products/topic-collections/nce/lawful-intercept-flow-tap/lawful-intercept-using-flow-tap.pdf

      1. Hey,thanks for the update,you are really an expert in this stuff.I am using an MS-MIC-16G card ,where I suppose Flowtap is not supported and it is allowing me to configure only Flowtaplite.
        How i got to know was it dint allow me to use my ms(no sp in MS-MIC-16G) interface for the flowtap service,it direcly asks me for a tunnel interface which is basically where we head towards flowtaplite.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s