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

Christer Holmberg <> Wed, 10 June 2015 15:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D92BD1B2B8D for <>; Wed, 10 Jun 2015 08:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5_PtdNh4ftO5 for <>; Wed, 10 Jun 2015 08:20:06 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A2CE1B2B9C for <>; Wed, 10 Jun 2015 08:20:05 -0700 (PDT)
X-AuditID: c1b4fb25-f79b66d000001131-a1-557855a347b1
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 9F.9D.04401.3A558755; Wed, 10 Jun 2015 17:20:03 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Wed, 10 Jun 2015 17:20:03 +0200
From: Christer Holmberg <>
To: "Dawes, Peter, Vodafone Group" <>, "" <>
Thread-Topic: New draft: draft-holmberg-dispatch-received-realm-00
Thread-Index: AdCiHwUUGsBUGXYYRyCmNYpBt1QlewBXgnVwAATWnjA=
Date: Wed, 10 Jun 2015 15:20:03 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D8B72D9ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvre7i0IpQg1+7bSyWTlrAatH38guT A5PHkiU/mTz6ZqxnDGCK4rJJSc3JLEst0rdL4MronrWNpeCUc8Xv6b2MDYzvrLoYOTkkBEwk Fjy7wAZhi0lcuLcezBYSOMoosXeVGYS9mFGiZb9cFyMHB5uAhUT3P22QsIhAhsTdddPZQWxh AUeJBRt2M0LEnSSu/FzAAlIuImAlsXleJkiYRUBV4nrbBSYQm1fAV+Lr1aksENNnMkrsei0D YnMKhEncfTKBFcRmBLrm+6k1YPXMAuISt57MZ4K4UkBiyZ7zzBC2qMTLx/9YIWwlibWHt7NA 1OcDxa8wQ+wSlDg58wnLBEaRWUhGzUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9g ZF/FKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERhRB7f8Vt3BePmN4yFGAQ5GJR5ehVnloUKs iWXFlbmHGKU5WJTEeWdszgsVEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMjVESjQyB9pIGlk 9OnlxJLsW4fMt7FMEtzT8CT0lN66/L+Nl4T9aw+v/76uUPdi4f7Pj25MmXE34MwG24+3G88u yXl3NnVz58eQ17nOKxav/t//ZoJM8cKEWwslPqUL1/yLkDwQvs71aVHIdXbH0wqemUU3ylId FaNDD3i82hB39KFqae9uW0MlluKMREMt5qLiRABG0oVBiQIAAA==
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: Wed, 10 Jun 2015 15:20:09 -0000

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.