Subject: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 12 Jul 2013 00:39:11 -0400

Howdy,
I've been meaning to submit a couple drafts for STIR - one for how a DNS model could work, and one for how the stuff can get through SIP and other protocols in-band.

Since some of the recent discussion has touched on some of the issues, and the deadline for new drafts is fast approaching, I've submitted the latter draft just now:
http://tools.ietf.org/html/draft-kaplan-stir-ikes-out-00

Sorry about the length, and yes it's still drafty/straw-man-ish.  It's also repetitive in sections, and needs a re-write, but the general concept should be understandable.

Comments/flames appreciated.

-hadriel

Begin forwarded message:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : An Identity Key-based and Effective Signature for Origin-Unknown Types
> 	Author(s)       : Hadriel Kaplan
> 	Filename        : draft-kaplan-stir-ikes-out-00.txt
> 	Pages           : 28
> 	Date            : 2013-07-11
> 
> Abstract:
>   This document describes a mechanism and format for signing source
>   identity information of communication requests, in a manner capable
>   of crossing multiple communication protocol types - even if the
>   origin's protocol type is unknown.  This is useful for providing
>   E.164 and other forms of Caller-ID reputability for various
>   communication protocols, such as SIP, XMPP, WebRTC, H.323, and
>   SS7/ISUP.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-kaplan-stir-ikes-out
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-kaplan-stir-ikes-out-00
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Torrey Searle <[email-masked]>
Date: Mon, 15 Jul 2013 22:05:40 +0200

I really like your draft, especially the fact that inter networks with ss7.
 Just have a initial comment that in the case of the UUI header, the spec
should probably specify that  the Protocol Discriminator for the UUI header
should be set to 00 - User Specific Coding.  Though it might me an
interesting question if it is possible to use a new value for the protocol
discriminator to easily identify that the value in the UUI header is a
signature.

Also how about the case where [email-masked] gets aliased to an e164 when
reaching the pstn gateway?  I assume the pstn gateway would "own" the e164
and can re-sign the call before forwarding, but would it be interesting to
mention this case in the spec?

Look forward to hearing your thoughts!

Torrey

On Fri, Jul 12, 2013 at 6:39 AM, Hadriel Kaplan
<[email-masked]>wrote:

> Howdy,
> I've been meaning to submit a couple drafts for STIR - one for how a DNS
> model could work, and one for how the stuff can get through SIP and other
> protocols in-band.
>
> Since some of the recent discussion has touched on some of the issues, and
> the deadline for new drafts is fast approaching, I've submitted the latter
> draft just now:
> Sorry about the length, and yes it's still drafty/straw-man-ish.  It's
> also repetitive in sections, and needs a re-write, but the general concept
> should be understandable.
>
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 15 Jul 2013 23:19:26 -0400

On Jul 15, 2013, at 4:05 PM, Torrey Searle <[email-masked]> wrote:

> I really like your draft, especially the fact that inter networks with ss7.  Just have a initial comment that in the case of the UUI header, the spec should probably specify that  the Protocol Discriminator for the UUI header should be set to 00 - User Specific Coding.  Though it might me an interesting question if it is possible to use a new value for the protocol discriminator to easily identify that the value in the UUI header is a signature.

Crap, I forgot about the protocol discriminator.  I don't mean I forgot to mention it, I mean I forgot about the byte it takes, not to mention the type and length bytes.  That means there're only 128 bytes available, which for a 1024-bit private key means all of those 128 bytes will be the signature.  So I'll have to move the key index and timestamp fields into the Call-Reference param instead.  Ugh.

But anyway, yeah good catch, the discriminator should probably be 0x00.

> Also how about the case where [email-masked] gets aliased to an e164 when reaching the pstn gateway?  I assume the pstn gateway would "own" the e164 and can re-sign the call before forwarding, but would it be interesting to mention this case in the spec?

Does that ever happen in the PSTN gateways?  I know it happens in some service providers (like skype for example), but I thought it happened on some SIP or H.323 system just before it reached the PSTN GW.  Regardless, yes I should mention that in the draft too.

Thanks for the feedback!

-hadriel

---

From: Torrey Searle <[email-masked]>
Date: Wed, 17 Jul 2013 09:26:02 +0200

Hello,

Regarding the SIP <->XMPP inter-working of SUBSCRIBE.  Subscriptions in SIP
are time limited, and last forever in XMPP, as a result, sip<->xmpp gateway
may need to generate several SIP subscribes in response to a single XMPP
subscribe.  Perhaps it's worthwhile to  note that only the Dialog Creating
and Dialog Destroying subscriptions will have a signature, and the rest of
the in-dialog requests should be considered trusted as well?

Regards,
Torrey

On Tue, Jul 16, 2013 at 5:19 AM, Hadriel Kaplan
<[email-masked]>wrote:

> > I really like your draft, especially the fact that inter networks with
> ss7.  Just have a initial comment that in the case of the UUI header, the
> spec should probably specify that  the Protocol Discriminator for the UUI
> header should be set to 00 - User Specific Coding.  Though it might me an
> Crap, I forgot about the protocol discriminator.  I don't mean I forgot to
> mention it, I mean I forgot about the byte it takes, not to mention the
> type and length bytes.  That means there're only 128 bytes available, which
> for a 1024-bit private key means all of those 128 bytes will be the
> signature.  So I'll have to move the key index and timestamp fields into
> the Call-Reference param instead.  Ugh.
>
> > Also how about the case where [email-masked] gets aliased to an e164
> when reaching the pstn gateway?  I assume the pstn gateway would "own" the
> e164 and can re-sign the call before forwarding, but would it be
> interesting to mention this case in the spec?
>
> Does that ever happen in the PSTN gateways?  I know it happens in some
> service providers (like skype for example), but I thought it happened on
> some SIP or H.323 system just before it reached the PSTN GW.  Regardless,
> yes I should mention that in the draft too.
>
> Thanks for the feedback!
>
> -hadriel
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 17 Jul 2013 10:11:30 -0400

On Jul 17, 2013, at 3:26 AM, Torrey Searle <[email-masked]> wrote:

> Hello,
> 
> Regarding the SIP <->XMPP inter-working of SUBSCRIBE.  Subscriptions in SIP are time limited, and last forever in XMPP, as a result, sip<->xmpp gateway may need to generate several SIP subscribes in response to a single XMPP subscribe.  Perhaps it's worthwhile to  note that only the Dialog Creating and Dialog Destroying subscriptions will have a signature, and the rest of the in-dialog requests should be considered trusted as well?

Yeah I'm cool with that - in fact, I'm not really sure we need dialog-destroying subscriptions to be supported for IKES.  Likewise a BYE doesn't really need IKES.
I mean this STIR stuff is really for the purpose of caller-id authentication, not in-dialog/in-call message dialog-matching verification. (and besides, middleboxes need to be able to generate BYEs successfully)
I only put them in the IKES draft to show they could be handled, because 4474 handles them... but if we move forward with the IKES draft I'd probably suggest we take the extraneous stuff out.

-hadriel

---

From: <[email-masked]>
Date: Tue, 23 Jul 2013 16:23:12 +0000

Hadriel,

A couple of initial questions/comments on this draft. 

Just an observation, first. Sometimes in 4.1 and 4.2 (see below), definitions seem to refer to numbers in general, examples taken from the NANP,... and some conclusion drawn essentially from an observation on the example rather than from the definition. :) 

> IKES also considers toll-free 1-8xx type numbers to be "E.164" numbers, 
> even though technically they are not.

If the statement is not only about US toll free numbers but on "freephone" numbers in general ("cc-8xx" being indeed very common for that), "technically they may not be", would be more accurate I think, on other CCs some of them are actually reachable from abroad. 

> Nationally-specific number codes are numbers that are not E.164 
>   numbers, nor are private numbering plan numbers, but are instead 
>   number codes used for specific purposes within national numbering 
>   plans.  Examples of these are N11 codes in the NANP, two or three 
>   digit emergency numbers such as 112, and inter-carrier common short 
>   codes.  Even if they cannot be used as caller-id numbers , they are 
>   destination numbers and thus IKES needs to support them.  

Actually short codes can sometimes be used as CgPN, again it depends on the country. Probably not emergency numbers, (although you might even find corner cases in the European 116 series, some of which qualify as such in some countries) but short codes can be. 

>   Likewise for nationally-specific number codes, the IKES process 
>   generates a canonical representation of the number code.  A leading 
>   country-code is prepended to the number code, to indicate the 
>   national numbering plan they are for.

I suppose you've been waiting for this but the usual problem of using such "pseudo E.164 numbers" for non E.164 numbers instead of local numbers is that, for countries that use national trunk codes eg 0, you can have an overlap between the short codes and the initial digits of the E.164 NDC or the SN. It's obviously not a problem as long as we stay in the dialing plan (actually that's precisely what the national trunk code is here for, to have more spare values to use) but it seems this would mean that the assignee of say range 112 could legitimately sign +CC-112, I'm not sure that's a good thing. (although this particular one 112 is indeed generally reserved in the national E.164 numbering plan but I use it to get the picture). 

> 10.  Usage in SS7/ISUP
[...]
> the signature, key 
>   index, and timestamp are carried in the User-to-User Information 
>   parameter ;

(Noted past exchanges on this. Don't think this was addressed) Generally speaking, what if the UUI is already used for a different purpose? (eg RFC 6467 use cases)

Thanks, 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Friday, July 12, 2013 6:39 AM
To: [email-masked]
Subject: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt

Howdy,

-hadriel

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 23 Jul 2013 17:10:46 -0400

Thanks for the review and catching this stuff!  More comments inline...

> Just an observation, first. Sometimes in 4.1 and 4.2 (see below), definitions seem to refer to numbers in general, examples taken from the NANP,... and some conclusion drawn essentially from an obs…

Ahh sorry.  I need to clean the draft up for sure. :)

> If the statement is not only about US toll free numbers but on "freephone" numbers in general ("cc-8xx" being indeed very common for that), "technically they may not be", would be more accurate I t…

OK, will fix in next rev.

> Actually short codes can sometimes be used as CgPN, again it depends on the country. Probably not emergency numbers, (although you might even find corner cases in the European 116 series, some of w…

I meant to imply that but it didn't come across right - when I said "Even if they cannot be used as caller-id numbers", I really meant more "Even for cases where they cannot be used as caller-id numbers".

> I suppose you've been waiting for this but the usual problem of using such "pseudo E.164 numbers" for non E.164 numbers instead of local numbers is that, for countries that use national trunk codes…

Yup, I've been waiting for that. :)

So right now in the CIDER draft it talks about there being a different domain name anchor for E.164s vs. number-codes.  So "cid.example.com" might be the E.164 anchor, while "nid.example.com" might be used for number-codes.  So a key holder for the whole E.164 range prefixed by +33-112 couldn't successfully sign a number-code of 112 in France, because the IKES-receiving verifier would look the latter E.164 up as "2.1.1.3.3.nid.example.com", while the attacker's key is only in "2.1.1.3.3.cid.example.com" and thus only valid for that number-code.

I think I put an example in where they used the same anchor, which is probably dangerous for the reason you said.  If I did, I'll fix it next rev.

> (Noted past exchanges on this. Don't think this was addressed) Generally speaking, what if the UUI is already used for a different purpose? (eg RFC 6467 use cases)

Yeah, I was waiting for the emails discussion around it to coalesce.  I think the right thing to do would be for RFC 6567 to win - the UUI in that case is for a end-to-end UUI as used in inter-PBX/inter-branch cases, so the IKES Generator or SIP-SS7 interworking gateway should not replace it with the IKES stuff.  I'm thinking that's ok, because as far as I know those inter-PBX cases are already in controlled environments and don't have a faked caller-id problem from random sources.  Yes/no?

-hadriel

---

From: <[email-masked]>
Date: Wed, 24 Jul 2013 09:57:07 +0000

Thanks for clarifying. A follow-up on the last two points, in-line. 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, July 23, 2013 11:11 PM
To: FOUQUART Philippe OLNC/OLN
Cc: [email-masked]
Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt

[snip] 

[PhF] Thanks, I get the picture now (apologies maybe I should have started with cider, always better to start with the lighter stuff first). 

I find the term canonical a bit misleading then for two reasons: 
- the point of converting into a canonical form to me is to have a unique form upon which all subsequent operations can be done whilst the non canonical form and related information that lead to it may be discarded altogether. I now understand why the draft insists on the IKES Generator using the "source identity type" in addition to the "canonical identity", it's just that having two distinct numbers (albeit of a different nature) leading to exactly the same "canonical" string to be processed and signed differently depending on their 'type' is quite confusing. 
- "canonical [E.164] form" for a number is as you know a very common term to describe the international E.164 format of a number stripped out of the visual separators. The canonical form in the draft is not that, well, expect for the E.164 numbers... I wouldn't like this "canonical" form to appear 'as is' in RU/To or From, for that matter, as I said in some numbering plans in would be problematic. 

Maybe that would be preferable to use a different term; if you'd rather not, maybe you want to add something along the lines of 3966 that says that "converting a nationally-specific number code into its canonical form/string does not make it a valid E.164 number: the string consisting of the leading country-code prepended to the number code cannot be assumed to be a valid E.164 number" 

[PhF] (thanks, sorry mistyped the rfc number) Well, sort of: a) not all of them are in "controlled environments" b) it is not uncommon in national "PSTN" interconnect offerings to support this and pass it on transparently and c) this type of access may actually be the source if not maliciously-faked, at least erroneously-configured caller-id. Maybe for c) depending on their use of the UUI, they could privately/bilaterally come up with an index of sort to assert the "on-net" calls, but I think that's just too complex.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 24 Jul 2013 08:58:09 -0400

> - the point of converting into a canonical form to me is to have a unique form upon which all subsequent operations can be done whilst the non canonical form and related information that lead to it…

Just to be clear, they're not the same canonical *IKES* string in the end - an E.164 would end up with a "G:" in front, while a number-code would end up with a "C:" in front, for the IKES-IF string.

> - "canonical [E.164] form" for a number is as you know a very common term to describe the international E.164 format of a number stripped out of the visual separators. The canonical form in the dra…

Right it doesn't change the SIP message at all, and is only used for IKES processing internally in the IKES generator/verifier.  Can you suggest a better word than "canonical"?  I was thinking "normalized" but that word is also commonly used.

> Maybe that would be preferable to use a different term; if you'd rather not, maybe you want to add something along the lines of 3966 that says that "converting a nationally-specific number code int…

I will add that line too - thanks!  But I agree with your earlier comment as well that using a different term might help.

> [PhF] Well, sort of: a) not all of them are in "controlled environments" b) it is not uncommon in national "PSTN" interconnect offerings to support this and pass it on transparently and c) this type of access may actually be the source if not maliciously-faked, at least erroneously-configured caller-id. Maybe for c) depending on their use of the UUI, they could privately/bilaterally come up with an index of sort to assert the "on-net" calls, but I think that's just too complex.

Right, but the "threat" for STIR is that someone receiving a INVITE/IAM gets a calling party number that it uses for caller-id display (or whatever) and the number is being maliciously misrepresented.  Obviously we don't know when it's being maliciously misrepresented or just an honest mistake/error, and many INVITES/IAMs won't be signed at all at least in the beginning, so we likely won't be able to block such calls for a very long time if ever.  Instead we'll either anonymize the calling number (block number display), or check with some other policy engine, or log it for later analysis, or send it to an IVR, or whatever - it's a local policy decision really.

So assume you get a INVITE/IAM with a RFC 6567 UUI.  It would be a local policy decision what to do.  You can decide that the destination subscriber doesn't have a UUI service, for example a mobile/home phone wouldn't, and thus treat it as an unsigned call and anonymize the calling number or block it or whatever.  Or you can decide that the SIP Trunk to an Enterprise has such UUI "service", and pass the INVITE/IAM on to it unchanged as you do today.  The IP-PBX is then responsible for deciding whether the INVITE/IAM with such a UUI is valid/allowed - for example if it's from a branch office or whatever.  That's what it has to decide already today, and we don't seem to have a spoofed caller problem for those cases today. 

The danger with letting a RFC 6567 UUI trump an IKES UUI is that malicious sources could just start adding RFC 6567 UUIs to their INVITEs.  We can easily detect and block that for destinations that don't expect to get 6567 UUIs.  The hard part is how to block it for IP-PBXs that do expect 6567 UUIs.  If it becomes a problem, there are some potential solutions.  One solution is to only support 6567 UUI for inter-branch calls that stay SIP along the whole path (since the IKES info is in a SIP header, it can be used at the same time as 6567 UUI for SIP).  That's not unreasonable, because as far as I know such inter-branch calls typically only work within the same carrier, or only within a small set of fixed/known/pre-arranged set of carriers in a country.  If that's true, then it's not unreasonable to expect the small set of carriers to support SIP interconnect, at least by the time this becomes a problem.  So the IP-PBX or penultimate carrier can have a local policy that it only believes INVITE/IAM with 6567 UUI if it also has a valid IKES info in a SIP header; and the IP-PBX can even have a local policy that only allows it if the validated number is for a number it allows to use 6567 UUI for (ie, it knows the branch office private number), etc.

-hadriel

---

From: <[email-masked]>
Date: Wed, 24 Jul 2013 15:46:35 +0000

Thanks for the clarifications. Some comments in-line. 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Wednesday, July 24, 2013 2:58 PM
To: FOUQUART Philippe OLNC/OLN
Cc: [email-masked]
Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt

[PhF] OK, thanks. Well then maybe the trick would be to say just that, "canonical IKES string", or even indeed "normalized IKES string", (eg Determining the normalized IKES string for E.164 Numbers and Number Codes for 4.2) rather than canonical form, and say as you put it that it's "only used for IKES processing internally in the IKES generator/verifier".

So assume you get a INVITE/IAM with a RFC 6567 UUI.  It would be a local policy decision what to do.  You can decide that the destination subscriber doesn't have a UUI service, for example a mobile/home phone wouldn't, and thus treat it as an unsigned call and anonymize the calling number or block it or whatever.  Or you can decide that the SIP Trunk to an Enterprise has such UUI "service", and pass the INVITE/IAM on to it unchanged as you do today.  The IP-PBX is then responsible for deciding whether the INVITE/IAM with such a UUI is valid/allowed - for example if it's from a branch office or whatever.  That's what it has to decide already today, and we don't seem to have a spoofed caller problem for those cases today. 
The danger with letting a RFC 6567 UUI trump an IKES UUI is that malicious sources could just start 
adding RFC 6567 UUIs to their INVITEs.  We can easily detect and block that for destinations that don't 
expect to get 6567 UUIs.                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 

[PhF] I'm missing something here: how does an interconnect point detect that a particular end site expect UUI or not? Suppose one of your malicious source adds those RFC 6567 UUIs to get through, how would you possibly know upstream whether it is legitimate or not, as you said it's a local policy? 

The hard part is how to block it for IP-PBXs that do expect 6567 UUIs.  
[PhF] It seems to me that part of the problem is precisely that you don't know which do and which don't.  

If it becomes a problem, there are some potential solutions.  One solution is to only support 6567 UUI for inter-branch calls that stay SIP along the whole path (since the IKES info is in a SIP header, it can be used at the same time as 6567 UUI for SIP).  That's not unreasonable, because as far as I know such inter-branch calls typically only work within the same carrier, or only within a small set of fixed/known/pre-arranged set of carriers in a country.  
If that's true, then it's not unreasonable to expect the small set of carriers to support SIP interconnect, 

[PhF] As an aside, even if they did support SIP interconnect, this seems to assume that you don't have ISUP or some encapsulation of it in parallel/addition to "full SIP". 

at least by the time this becomes a problem.  So the IP-PBX or penultimate carrier can have a local policy that it only believes INVITE/IAM with 6567 UUI if it also has a valid IKES info in a SIP header; and the IP-PBX can even have a local policy that only allows it if the validated number is for a number it allows to use 6567 UUI for (ie, it knows the branch office private number), etc.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 25 Jul 2013 01:22:48 -0400

> [PhF] I'm missing something here: how does an interconnect point detect that a particular end site expect UUI or not? Suppose one of your malicious source adds those RFC 6567 UUIs to get through, h…

Sorry, I didn't mean the ingress point (SBC/IBCF) of a carrier could block it - I just meant the carrier could block it somewhere, for example in the S-CSCF that routes the call to the IP-PBX's trunk, or an SBC connecting to the IP-PBX trunk, or whatever.

> [PhF] It seems to me that part of the problem is precisely that you don't know which do and which don't.  

As far as I know, the carriers know if a PBX-trunk/Enterprise-customer has UUI support or not.  For example it's in the service contract/agreement with the Enterprise for SIP trunk service.  Is that not the case? (I could easily be wrong about that - it was just what I heard)

> [PhF] As an aside, even if they did support SIP interconnect, this seems to assume that you don't have ISUP or some encapsulation of it in parallel/addition to "full SIP". 

Sorry I should have been clearer.  I meant the IKES info is still in a SIP header, even if there's an ISUP mime body in the SIP message.  So for SIP-SIP scenarios, you can leave the RFC 6567 UUI alone, while still having IKES.  IT should probably be clearer about that in the draft.

-hadriel

---

From: <[email-masked]>
Date: Thu, 25 Jul 2013 15:48:31 +0000

Thanks. More in-line...

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Thursday, July 25, 2013 7:23 AM
To: FOUQUART Philippe OLNC/OLN
Cc: [email-masked]
Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt

[PhF]  OK, thanks. The difference then is that the call server would then know whether UUI is supported to/from a particular site, it doesn't mean that UUI 'must' or 'must not' be present for a particular message. (see next) 

[PhF] It is. I don't know if it's the general situation for all such contracts but indeed for the baseline offer I'm familiar with, UUI is actually always included by default, but the endpoint may or may not use it, or may use it only occasionally, so at a given point in time, how would the network know whether to expect UUI to/from that site? 

-hadriel