Re: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00

"Dawes, Peter, Vodafone Group" <> Thu, 11 June 2015 12:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1B9BA1ACEC1 for <>; Thu, 11 Jun 2015 05:50:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xPhkjKTiJqHT for <>; Thu, 11 Jun 2015 05:50:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E17311ACEBF for <>; Thu, 11 Jun 2015 05:50:33 -0700 (PDT)
Received: from [] by id 46/4F-01139-81489755; Thu, 11 Jun 2015 12:50:32 +0000
X-Originating-IP: []
X-StarScan-Version: 6.13.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9422 invoked from network); 11 Jun 2015 12:50:27 -0000
Received: from (HELO ( by with DHE-RSA-AES256-SHA encrypted SMTP; 11 Jun 2015 12:50:27 -0000
Received: from ( []) by (Postfix) with ESMTP id 3m6lQq29lqz1yJj; Thu, 11 Jun 2015 14:50:27 +0200 (CEST)
Received: from (localhost []) by (Postfix) with ESMTP id 3m6lQT5kqbzfZnN; Thu, 11 Jun 2015 14:50:09 +0200 (CEST)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3m6lQT57jWzfZlK; Thu, 11 Jun 2015 14:50:09 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0224.002; Thu, 11 Jun 2015 14:50:08 +0200
From: "Dawes, Peter, Vodafone Group" <>
To: Christer Holmberg <>, "" <>
Thread-Topic: New draft: draft-holmberg-dispatch-received-realm-00
Date: Thu, 11 Jun 2015 12:50:08 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2BFFVOEXM31Winterna_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Jun 2015 12:50:39 -0000

Thanks Christer,
I would like to see this draft progress, I think it describes functionality that is needed. I have other comments and questions on the text but they can be raised later.


From: Christer Holmberg []
Sent: 10 June 2015 16:20
To: Dawes, Peter, Vodafone Group;
Subject: RE: New draft: draft-holmberg-dispatch-received-realm-00

Hi Peter,

Thanks for your comments! See inline.

> I agree that it is useful for a (transit) network to know which network a request arrived from, as this
> draft argues. But isn't this information to be in the Via header field already in the entry before the
> transit network? The draft mentions that inter-operator identifier cannot be used but I think the
>draft should expand on why a new header field parameter is needed.

Via headers may contain IP addresses, and they cannot always be used to identify the network. Also, the consumer of the information would have to scan through the Via headers, and figure out which belongs to the consumer network and which belongs to the adjacent network.

The purpose of the identifier is to have an explicit indicator, which prevents such scanning etc.

I try to explain that in the draft, but maybe more text is needed :)



From: dispatch [] On Behalf Of Christer Holmberg
Sent: 08 June 2015 20:15
Subject: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00


I've submitted a new draft to dispatch: draft-holmberg-dispatch-received-realm-00. The draft defines a new Via header field parameter, "received-realm", which network entry entities can insert in order to inform other entities in the network from which network the request was received.

Previous versions of the draft have been submitted to SIPCORE, but I was advised by the SIPCORE chairs to submit it to DISPATCH.

Compared to previous versions, there is a technical change: the entity which inserts a parameter also calculates a HMAC value, which is inserted together with the network value.