Peering: A Minimalist Approach Rohan Mahy IETF 66 — Speermint WG.

Slides:



Advertisements
Similar presentations
IETF 71 SIPPING WG meeting draft-ietf-sipping-pai-update-00.
Advertisements

© 2006 NEC Corporation - Confidential age 1 November SPEERMINT Security Threats and Suggested Countermeasures draft-ietf-speermint-voipthreats-01.
International Telecommunication Union ENUM Issues and Solutions Houlin Zhao Director Telecommunication Standardization Bureau International Telecommunication.
Rfc4474bis-01 IETF 89 (London) STIR WG Jon & Cullen.
SIP issues with S/MIME and CMS Rohan Mahy SIP, SIPPING co-chair.
Network Security Topologies Chapter 11. Learning Objectives Explain network perimeter’s importance to an organization’s security policies Identify place.
9,825,461,087,64 10,91 6,00 0,00 8,00 SIP Identity Usage in Enterprise Scenarios IETF #64 Vancouver, 11/2005 draft-fries-sipping-identity-enterprise-scenario-01.txt.
Multihop Federations draft-mrw-abfab-multihop-fed-01.txt Margaret Wasserman
Identity, Spheres and Privacy Rules Henning Schulzrinne (with Hannes Tschofenig and Richard Barnes) Workshop on Identity, Information and Context October.
DNS-centric PKI Sean Turner Russ Housley Tim Polk.
ABFAB Multihop Federations draft-mrw-abfab-multihop-fed-01.txt Margaret Wasserman
July 16, 2003AAA WG, IETF 571 AAA WG Meeting IETF 57 Vienna, Austria Wednesday, July 16,
Copyright © 2006 Juniper Networks, Inc. Proprietary and Confidentialwww.juniper.net 1 draft-penno- message-flows-02 Reinaldo Penno, Daryl Malas, Adam Uzelac,
Voice over Internet Services and Privacy. Agenda Problem Description Scope Recommendations.
21-07-xxxx IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: MIH Protocol Security Date Submitted: December, 2007 Presented.
1 NGN Issues - Numbering and Addressing Peter Darling ACIF NGN FOG No. 3.
PSTN – User ENUM – „Infrastructure ENUM“ An ETSI View Richard Stastny IETF60 San Diego.
Microsoft Active Directory(AD) A presentation by Robert, Jasmine, Val and Scott IMT546 December 11, 2004.
September, 2005What IHE Delivers 1 G. Claeys, Agfa Healthcare Audit Trail and Node Authentication.
MASS / DKIM BOF IETF – Paris 4 Août 2005 dkim.org  mipassoc.org/mass IETF – Paris 4 Août 2005 dkim.org  mipassoc.org/mass MIPA.
S/MIME Certificates Cullen Jennings
Draft-khan-ip-serv-peer-arch-03.txt SPEERMINT Peering Architecture IETF-66, Montreal, Canada Sohel Khan, Ph.D. Technology Strategist.
© 1998 R. Gemmell IETF WG Presentation1 Robert Gemmell ROAMOPS Working Group.
Jun Li DHCP Option for Access Network Information draft-lijun-dhc-clf-nass-option-01.
GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements draft-tschofenig-geopriv-l7-lcp-ps-00.txt Hannes Tschofenig, Henning.
1January 2006Richard Stastny Developments around Infrastucture ENUM and their relevance on NGNs Workshop on NGN Interconnection and Numbering TRIS – TISPAN.
July 16, Diameter EAP Application (draft-ietf-aaa-eap-02.txt) on behalf of...
DNS SRV and NAPTR Use for SPEERMINT - Tom Creighton, Gaurav Khandpur Comcast SPEERMINT Intermin Meeting Philadelphia Sept
The State of VoIP Peering Charles Studt Director of Product Management, VoEX.
7/6/20061 Speermint Use Case for Cable IETF 66 Yiu L. Lee JULY 2006.
1 SPEERMINT Use Cases for Cable IETF 66 Montreal 11 JULY 2006 Presented by Yiu L. Lee.
Slide title In CAPITALS 50 pt Slide subtitle 32 pt RTSP 2.0 TLS handling Magnus Westerlund draft-ietf-mmusic-rfc2326bis-12.
Security, NATs and Firewalls Ingate Systems. Basics of SIP Security.
Module 5: Designing Security for Internal Networks.
Session Recording (SIPREC) Protocol (draft-ietf-siprec-protocol-09) Leon Portman Henry Lum
Requirements for SIP-based VoIP Interconnection (BCP) draft-natale-sip-voip-requirements-00.txt Bob Natale For Consideration by the.
1 IETF 72 SIP WG meeting SIP Identity issues John Elwell et alia.
Rfc4474bis-01 IETF 90 (Toronto) STIR WG Jon. First principles (yet again) Separating the work into two buckets: 1) Signaling – What fields are signed,
Page 1 IETF Speermint Working Group Speermint Requirements/Guidelines for SIP session peering draft-ietf-speermint-requirements-02 IETF 69 - Monday July.
1 VoIP Peering Peering, it’s not just for IP anymore Kingsley Hill XConnect Global Networks, Ltd VP for Strategic Federations.
Session Peering Use Cases for Federations David Schwartz – Kayote Networks Eli Katz - XConnect Jeremy Barkan - Digitalshtick draft-schwartz-speermint-use-cases-federations-00.txt.
Justin Richer The MITRE Corporation October 8, 2014 Overview of OAuth 2.0 and Blue Button + REST.
Mobile IPv6 with IKEv2 and revised IPsec architecture IETF 61
Simo Veikkolainen Simple Application Configuration Protocol draft-veikkolainen-sipping-app-config-00 Simo Veikkolainen APP area open meeting.
17 February 2016 SIPPING - IEPREP Joint Meeting Fred Baker - IEPREP co-chair Rohan Mahy - SIPPING co-chair.
IETF 67 – SPEERMINT WG Presence Use Cases draft-houri-speermint-usecase-presence-00 Avshalom Houri – IBM Edwin Aoki – AOL LLC Sriram Parameswar - Microsoft.
Requirements and Selection Process for RADIUS Crypto-Agility December 5, 2007 David B. Nelson IETF 70 Vancouver, BC.
IETF sec - 1 Security Work in the IETF Scott Bradner Harvard University
IPSec is a suite of protocols defined by the Internet Engineering Task Force (IETF) to provide security services at the network layer. standard protocol.
GEONET Brainstorming Document. Content Purpose of the document Brainstorming process / plan Proposed charter Assumptions Use cases Problem description.
MODERN BoF Managing, Ordering, Distributing, Exposing, and Registering telephone Numbers IETF 92.
Page 1 IETF Speermint Working Group Speermint draft-ietf-speermint-requirements-04 IETF 71 - Wednesday March 12, 2008 Jean-François Mulé -
Page 1 IETF DRINKS Working Group Data Model and Protocol Requirements for DRINKS IETF 72 - Thursday July Tom Creighton -
SPEERMINT Architecture - Reinaldo Penno Juniper Networks SPEERMINT, IETF 70 Vancouver, Canada 2 December 2007.
IP Security (IPSec) Matt Hermanson. What is IPSec? It is an extension to the Internet Protocol (IP) suite that creates an encrypted and secure conversation.
DOTS Requirements Andrew Mortensen November 2015 IETF 94 1.
ECRIT WG IETF-75 Trustworthy Location Bernard Aboba
Cullen Jennings S/MIME Certificates Cullen Jennings
IP-NNI Joint Task Force Status Update
TLS Security Profiles Rob Horn WG-14: Security.
Goals of soBGP Verify the origin of advertisements
The Domain Policy DDDS Application
iSCSI X-key for enhanced supportability
IP-NNI Joint Task Force Status Update
* Essential Network Security Book Slides.
Maryna Komarova (ENST)
draft-ipdvb-sec-01.txt ULE Security Requirements
SAML/SIP Profiles and Call Initiation
draft-ietf-stir-oob-02 Out of Band
Presentation transcript:

Peering: A Minimalist Approach Rohan Mahy IETF 66 — Speermint WG

What is the eventual output of Speermint? IMO: Our output is a peering convention documented in one or more BCPs Consequence 1: We are describing a specific way to USE a set of protocols (SIP, ENUM, DNS, etc..). We are not defining a protocol. Consequence 2: Multiple conventions are possible, but we should define ONE. Documenting multiple conventions is inconsistent with BCP status, is bad for interoperability, and makes more work for everyone. –Analogy: SMTP is used between most mail servers, but does not prevent a group of consenting domains from using a proprietary mail exchange protocol among themselves

A Minimal Approach Discovery –Determine if target address is external –If its an E.164 address, check User ENUM –If no records in User ENUM check Carrier ENUM (for at least ‘sip’ and ‘pstn’ enumservices) –If you get an im: or pres: URI follow RFC 3861 Peering –Once you get a sip: or sips: URI, follow RFC 3263 –Connect via TLS to peer for mutual authentication –Exchange traffic. Use the Identity header to assert Identity

To TLS or not to TLS Options –Use no signaling protection Not allowed at IETF, see BCP 61 / RFC 3365 –Use sips: (e2e TLS) currently impractical. would not be able to serve the bulk of the community, since most endpoints do not support sips: –Use SIP with TLS only over the carrier to carrier hop (author’s proposal) author asserts this is practical, deployable, and easier overall than using IPsec. How do we measure if this assertion is valid? –Use IPsec using a profile like that in RFC 3788 does not provide authentication of previous/next hop requires large-scale manual configuration of source IP addresses to provide any security –Allow use of either TLS or IPsec requires everyone to implement both and negotiate one. A worst of both worlds solution.

Trust issues what mechanisms are acceptable for authentication purposes? (ex: certificate authentication w/ trusted root) –cacert.org (free cert) may be acceptable for authentication, but provides no additional authorization context how does each peer decide that the other side is authorized? may be based on who the trust root is... –peer with a fixed list of carriers –only peer with folks with cert signed by one of my federations / peering clubs –peer with anyone with a good enough reputation or accreditation score (from one of my peering clubs). –peer with anyone unless they are on the blacklist (like SMTP current practice) IMO: Speermint needs to provide/document the tools. Authorization needs to be left as local policy

Federations terminology My draft describes how to connect to someone using an example peering convention. It assumes that both carriers somehow authorized peering based on strong authentication. (think of this as “external peering”). There can still be some “club” that helps make authorization decisions. Draft mentions a “federation of domains” to mean a group of domains that acts like a single domain for the purposes of the speermint peering convention (think of this as “internal peering”). Outside our scope? We need to come up with terms for both of these