Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows

From: "Stastny Richard" <[email-masked]>
Date: Fri, 14 Apr 2006 19:31:26 +0200

Maybe I am finally getting confused now, because I am already one week on vacation,
 
I do not understand scenario 1:
how can I have L5/L7 connectivity without having L3 connectivity?
Telepathy?
 
I know some IMS and TISPAN guys are discussing this, but ...
 
Richard

________________________________

Von: Brian Rosen [mailto:[email-masked]]
Gesendet: Fr 14.04.2006 19:11
An: 'Reinaldo Penno'; 'Hadriel Kaplan'; 'Michael Hammer (mhammer)'; [email-masked]
Betreff: RE: [Speermint] SPEERMINT Routing Architecture Message Flows 

>Finally, as with any peering "endeavour" I believe there will always be
>the casethat they have physical/co-location security so TLS is not
>needed.

I wonder about that.

Seems to me there are a few cases of interest:
1. Peering is conducted in a closed environment, where you have no L3
connectivity unless you are allowed L5/L7 connectivity

2. Peering is conducted in an open environment where you have open L3, and
need restricted L5/L7

3. Peering is conducted in a closed L3 environment, but needs authorization
for L5/L7

In case 1, you don't need any form of authentication.  If you can connect,
you are allowed to peer.

In case 2, TLS is appropriate

In case 3, you want some form of authorization, but don't need privacy or
integrity protection.  What you need is authorization.  TLS mutual
authentication would be very appropriate.  You don't have to engage
encryption or MAC processing, just the authentication part. 

I think the registration mechanisms discussed are a misuse of SIP.
Registration in 3261 is described as UAC to Registrar, not proxy to proxy.

There are also problems with using the Proxy-Authenticate process defined in
section 22.4.  Section 22 of 3261 discusses User to User and User to proxy
authentication.  Proxy to proxy is noticeably not discussed in 3261.
RFC3603 gives some private extensions for proxy to proxy within PacketCable
DCS, but these are not generalizable to SPEERMINT.

Thus, I suggest we consider using TLS mutual authentication when peers need
to authenticate with one another.

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 14 Apr 2006 13:41:05 -0400

This is the "Club Room" environment.  I run a peering service.  I only let
you into my peering fabric under controlled conditions (private network
connection, IPsec or other VPN connections).  If you are in, you are in, no
further authorization needed.

Brian

  _____  

From: Stastny Richard [mailto:[email-masked]] 
Sent: Friday, April 14, 2006 1:31 PM
To: [email-masked]; Reinaldo Penno; Hadriel Kaplan; Michael Hammer
(mhammer); [email-masked]
Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows 

Maybe I am finally getting confused now, because I am already one week on
vacation,

Richard

  _____  

Von: Brian Rosen [mailto:[email-masked]]
Gesendet: Fr 14.04.2006 19:11
An: 'Reinaldo Penno'; 'Hadriel Kaplan'; 'Michael Hammer (mhammer)';
[email-masked]
Betreff: RE: [Speermint] SPEERMINT Routing Architecture Message Flows 

I wonder about that.