Subject: Re: [rrg] ILNP q1: Scalability

From: RJ Atkinson <[email-masked]>
Date: Thu, 10 Jun 2010 06:54:23 -0400

Much Earlier, Tony Li wrote:
>> Given that ILNP identifiers are not global, 
>> doing identification purely on identifier
>> is not going to help. 

This is precisely true, but a bit misleading.
ILNP has 2 different classes of Identifier,
global-scope and local-scope.  

The normal case is to use a global-scope Identifier.

The binding between the Identifiers and the Locators
for a node, and between the FQDN and both Identifiers 
and Locators can all be cryptographically authenticated
using DNSsec.  (Maybe 2 years ago, it was not so clear
that DNSsec deployment would happen soon, but actually
the speed of DNSsec deployment is quite rapid now,
so using DNSsec is quite reasonable for ILNP.)

The local-scope Identifier capability exists primarily 
to handle uncommon special cases (e.g. people who want 
to use CGAs, or who want to use HIP-like Identifier 
values [e.g. based on a hash of a public key]) or who
have some other special use model.  As with all choices,
the choice to deploy a local-scope Identifier has
implications for the deployment overall.

There is a single bit in the EUI-64 which indicates
whether a given EUI-64 is local-scope or global-scope.
So it is trivial to determine which scope a given 
Identifier value possesses.

Tony's original comment is precisely correct in that 
when one is using a local-scope Identifier there is an 
extremely small, but non-zero, probability that 2 nodes 
would accidentally generate the same Identifier value 
in overlapping timeframes.  However, by the existing ARP
and Neighbour Discovery (ND) mechansisms, it is NOT
possible for 2 nodes to use the same Identifier on
the same subnet (i.e. with the same Locator value) 
at the same time.

Now, as [CERT CA-1995-01] explained 15 years ago, it is
already both trivially easy and common to forge IP addresses.
The same half-hearted risk reduction measures that are
(partly) deployed today, namely uRPF checks, work equally
well with Locator values as they do with the routing prefix
portion of the IP address.

So if one applies existing uRPF checks against Locator
values (which is only sensible and no additional 
implementation work or deployment work than the existing 
uRPF checks) and then uses the Identifier in the place of 
the IP address in one's rule set, one gets equivalent security 
and equivalent assurance as with today's deployed IP Internet.

Now, if a node C is trying to impersonate another 
node A that is legitimately talking with B, the 
impersonation still won't work.  If the packet with 
C's Locator and A's Identifier reaches B (and it ought not, 
since the ACL rule can be automatically updated - details 
below), then B will check the received ID & Locator values 
against its local session cache and discover that C's Locator 
is not associated with A's Identifier and realise that it 
is either a forgery or a new session connection attempt.  
This implementation issue is discussed at more length 
in one of the ILNP I-Ds.

Later, Patrik Frejborg wrote:
> But then we are back in the renumbering challenge, 
> if the partner changes his locator value I have 
> to change my rule base simultaneously 

This turns out to be trivial, because the partner
will always send an ICMP Locator Update message,
which can be authenticated, to provide the new
Locator values.

Since the seecurity appliance is along the path
from source to destination, the security appliance
will always see the ICMP Locator Update message
and can update the set of valid Locator bindings
by itself instantly.[1]

We talk about this in one of the MILCOM papers
in more detail than I am writing down in this note.
Our example in that paper relates to NAT and updating
the NAT session state, but there is no fundamental 
difference between updating NAT session state and
updating an ACL rule.

> - and we are not 
> really improving mobility here (either worsening it
> from current solution).

Actually, mobility is MUCH improved here, for the
reasons I've outlined above -- dynamic changes to
location automatically cause the ACLs to be instantly
updated.

> It would be nice if the identifier could be used to
> limit access to my server farm, the final authentication
> is then done (by e.g. IPsec)  by the server.

In the normal case it can be done that way, since in
the normal case Identifier values are global-scope.

> It seems that the firewalls should move towards
> DNS based filtering solutions.

Yes, and that is true even if none of the Routing RG
proposals get adopted, because it mitigates risks
in the current deployed Internet.

> I'm exploring the capabilities and limitations of the 
> ILNP identifier, also renumbering - if renumbering could be 
> made easier we would have a business case at the enterprises.

A good paper to read is [MILCOM09].

> We can't use the identifier at the firewalls to limit access 
> at a security zone, if we use locators we loose mobility 
> - both site and host mobility.

That's not true, for the reasons I've outlined above.

> But then we have host mobility, a cellco is not keen to let 
> the end user to roam over to another network that they can't 
> charge for - 

This is no longer true.  The bandwidth pressures created 
by various "smart phones" mean that mobile phone operators
are quite keen to encourage their users to migrate to WiFi 
if they roam to an area with good WiFi coverage (for example),
at least for data traffic (Handoffs of voice telephony traffic
to WiFi is still in flux in the marketplace).

> thus the core locator do not change but the edge locator 
> will change when the device is moving at the cellco's 
> RAN (if you take the identifier mechanism to the future mobile 
> network architecture).

I don't agree.  The current approach to mobility is driven by
Internet architectural constraints, and available engineering
options, rather than by business models.  

Mobile phone operators already use the handset's identifier 
(e.g. GSM SIM ID) to ensure that both the carrier being 
roamed onto and the carrier the subscriber belongs to normally 
can bill, and settle cross-charges between operators, and that 
the subscriber in turn can be charged extra for roaming 
(if applicable to the subscriber's tariff).  None of those 
capabilities are lost if using ILNP. In fact, several become
simpler because ILNP has a location-independent ID, and existing
IP addresses don't. 

(I'm not sure, but I think there is even an open specification 
of how one puts a GSM SIM ID into EUI-64 format.)

Yours,

Ran Atkinson
[email-masked]

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 10 Jun 2010 17:47:56 +0300

> difference between updating NAT session state and

Couldn't open this one
http://www.cs.st-andrews.ac.uk/~saleem/papers/2009/milcom2009/milcom2009-rab2009.pdf
Firefox reported it broken

However, it could be hard to sell this to the security officers, i.e.
having an external partner updating their ACL or firewall rules
automatically....

> in the current deployed Internet.

I'm starting to get sold on this approach - when you design an
enterprise architecture you need to create security zones. If you
could align the DNS zone names together with security zones, having
security nodes verifying incoming sessions to the security zone by the
identifier and DNSSEC the renumbering would be a breeze after that.
Take an example, you have departments 1 & 2 with their dedicated
services dep1&dep2 and user groups 1 & 2. Also some common services is
provided for both departments. You set DNS zones dep1.foo.com,
dep2.foo.com, user1.foo.com, user2.foo.com and common.foo.com.
Separate the users from the services by a identifier&DNSSEC enabled
firewall. You set up following rules in the firewall:
- user1.foo.com allowed to access dep1.foo.com, needed ports
- user2.foo.com allowed to access dep2.foo.com, IPsec
- user1 and user2.foo.com allowed to access common.foo.com, needed ports

Now user1 and user2 can be located anywhere inside the enterprise
network, no need to separate the users in separate VLANs&VRFs. The
firewall verifies the user based upon the identifier value that is
checked via DNSSEC that has been updated during the logon to the
enterprise network. If there is a common service between user1 and
user2 groups, e.g. VoIP or Video the service is located in the
common.foo.com zone but the RTP stream between user1&user2 takes the
shortest path in the network since there is no VLAN&VRF separation
with checkpoint somewhere far in between the users 1&2
Also user1 can't listen and steel data from user2 group when they
accessing dep2 services, only IPsec is allowed for those sessions.

Is there any papers available around this kind of a solution?
Or is this a brain damaged approach?

> to WiFi is still in flux in the marketplace).
Think the reason is that the current TDM connections are too expensive
and gets filled by data that is not generating much revenue. This
model could change back once carrier ethernet is available, they
should be much much cheaper than the TDM connections.

-- patte

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 10 Jun 2010 12:33:45 -0400

> Firefox reported it broken

Hmm. I just was able to click on that and have the PDF open.
So I'm not sure what happened.  Maybe some transient 
network issue somewhere.

I apologise for being very unclear in my earlier note.
I actually meant the other MILCOM 2009 paper online:

  R. Atkinson  &  S. Bhatti,
  Site-Controlled Secure Multi-homing and Traffic Engineering for IP, 
  28th IEEE Military Communications Conference (MILCOM), 
  Boston, MA, USA, October 2009

(I just verified that link from the ilnp.cs.st-andrews.ac.uk
site, and it opened the right PDF, at least for me.)

> having an external partner updating their ACL or firewall rules

Hmm.

It isn't really "having an external partner update their ACL 
or firewall rules", but instead using learned local-knowledge
(knowledge that can be authenticated !) to locally update 
local ACL or firewall rules.  

That is, the ruleset remains whatever was locally chosen, 
it is just that as the location change is learned 
and then the same locally-specified rule is applied 
to the same locally-specified node/site, 
at the remote node/site's new location.

There are multiple authentication mechanisms for those
ICMP Locator Updates:
	- non-cryptographic session nonces are always used
	- cryptographic authentication of the packet (IPsec AH)
	  can optionally be used

Separately, DNS with DNS Security can be used to retrieve
the revised Locator value(s) from the DNS 

&&

the mobile site/node can use Secure Dynamic DNS Update
to send the revised Locator value(s) to its authoritative
DNS Servers.

(I think the authentication aspect of the updates is
pretty thoroughly covered in the current ILNP specs.)

> Think the reason is that the current TDM connections are
> too expensive and gets filled by data that is not generating
> much revenue. This model could change back once carrier ethernet
> is available, they should be much much cheaper than the TDM
> connections.

That could be true for some operators in some places.

The subset of mobile telephone operators who already have 
deployed Carrier Ethernet over glass that I happen to have 
talked with told me that (for them at least) the bandwidth 
of the radio links is the fundamental limitation (and they
told me that moving to any of the 4G radio technology options 
don't alleviate that limitation for them).

Of course, "mileage could vary" from one operator, location, 
or regulatory environment to another.  Also, not all IP 
carriers use mobile telephone technology, some use copper
wires (e.g. DSL), fibre-optic cables (e.g. Verizon FIOS), 
hybrid fibre-coax (HFC), or other wireless  technologies 
(e.g. WiMAX as a  "last mile" point-to-point link).

Cheers,

Ran

---

From: Tony Li <[email-masked]>
Date: Thu, 10 Jun 2010 09:52:35 -0700

> So I'm not sure what happened.  Maybe some transient

I just tried and got a server timeout.  An alternate server might be
helpful...

Tony

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 10 Jun 2010 13:58:51 -0400

On 10  Jun 2010, at 12:52 , Tony Li wrote:
> I just tried and got a server timeout.  
> An alternate server might be helpful...

Well, I've tried several different times this morning,
always from outside the UK, and have never had any issues.
The server seems completely fine, and has all day.

Regardless, a quick web search <http://scholar.google.com> 
reveals that various other sites have PDF copies of most 
of the ILNP papers, including both of the MILCOM 2009
papers.

As always, Internet routing is dynamic and reachability 
of a given site from some specific other location 
might vary from moment to moment (e.g. if BGP is 
flapping anywhere along the path to that other location).

So I'll just suggest using one's preferred web search engine 
if the U. St Andrews site is temporarily unreachable from 
wherever one might be connected at the moment.  One might
have thought this approach were obvious, but apparently not.

Yours,

Ran

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 10 Jun 2010 22:48:44 +0300

>  Boston, MA, USA, October 2009

Thanks, got it!

>        - cryptographic authentication of the packet (IPsec AH)

This is a little bit controversial, for the routing architecture the
IP address is divided into identifier&locator values but in order to
traverse security architectures both are glued again together as an IP
address - making one architecture scaling better but the other one
becomes more complex.

> the revised Locator value(s) from the DNS

Found this on wikipedia
http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Zone_enumeration_issue.2C_controversy.2C_and_NSEC3

"In addition, the information from an enumerated zone can be used as a
key for multiple WHOIS queries; this would reveal registrant data
which many registries are under strict legal obligations to protect
under various contracts.

It is unclear whether DNSSEC is legal to deploy at all in many
countries, unless such lists can be kept private. DENIC has stated
that DNSSEC's zone enumeration issue violates Germany's Federal Data
Protection Act, and other European countries have similar privacy laws
forbidding the public release of certain kinds of information."

Seems that NSEC3 is needed before we can use DNSSEC to carry the identifier

-- patte

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 10 Jun 2010 16:36:12 -0400

On 10  Jun 2010, at 15:48 , Patrick Frejborg wrote:
> IP address is divided into identifier&locator values, but in order to

I don't understand what you are trying to say just above.
Your use of the word "this" is perhaps where I get lost.

The obvious anteceent would be "authentication mechanisms",
but I can't figure out what might be controversial about
either mechanism.  ILNP AH does not bind to the Locator
in any event, and the Nonce value isn't cryptographically
bound at all.

(Please provide a bit more context to your comment, 
and maybe expand it a bit so I can understand it.  Thanks.  :-)

Cheers,

Ran Atkinson

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 10 Jun 2010 16:46:00 -0400

(NB:  I've revised the Subject line to reflect that this
has moved off-topic from ILNP and is really purely
about DNS, DNSsec, and alleged privacy issues.)

On 10  Jun 2010, at 15:48 , Patrick Frejborg wrote:
>> Earlier, Ran Atkinson wrote:
> "In addition, the information from an enumerated zone
> can be used as a key for multiple WHOIS queries; this would
> reveal registrant data which many registries are under strict
> legal obligations to protect under various contracts.

I don't have any reason to believe that the quoted claim 
above is true.  In fact, I have some evidence (below)
that the claim is not valid/correct.

For example, more than one registrar today simply returns 
its own contact information in response to a WHOIS query 
for a domain that has a private registration.   Multiple 
queries (for the same domain or for a variety of different 
domains) don't reveal anything at all, except that some huge 
number of domains that happen to have been coincidentally
registered by the same registrar.  

All of those privately registered domains will return
identical information (e.g. the registrar's name and
the registrar's contact information, but will NOT return
the registrant's name or contact information) from a 
WHOIS perspective, so there is no privacy issue.

More generally, there is nothing in DNSsec that requires 
a registrar to reveal private registrant data.  Keeping 
that registrant data private is solely a registrar issue, 
one that can be solved entirely within a given registrar, 
with no changes to the DNS protocol (and no changes to the 
WHOIS protocol either).

> countries, unless such lists can be kept private.

That information can be kept private, with one example
approach described above, so there is no actual issue here.

No protocol changes are needed for this in any event.

> DENIC has stated that DNSSEC's zone enumeration issue violates
> Germany's Federal Data Protection Act, and other European countries
> have similar privacy laws forbidding the public release of certain
> kinds of information."

This is why DNSsec also has other mechanisms (e.g. NSEC3) 
that don't enable zone enumeration.  Those mechanisms 
(e.g. NSEC3) are widely available now [1], well before ILNP 
is widely available. so there is no current issue here either.

Yours,

Ran

[1] According to this URL, the very commonly used BIND 
implementation of DNS and DNSsec has included NSEC3 
in shipping releases for over 2 years already:
  <http://www.isc.org/software/bind/new-features/9.6>

Other DNS implementations also exist with NSEC3 support.  
BIND is simply a convenient example to cite, because 
it is especially widely deployed at present.

Yours,

Ran

---

From: Steve Crocker <[email-masked]>
Date: Thu, 10 Jun 2010 17:31:14 -0400

Ran,

Thanks for providing clarification to the list on this topic.  I  
hadn't noticed the wikipedia entry before.  The language regarding  
whether DNSSEC is legal to deploy in some countries is unnecessarily  
inflammatory.  I am not aware of any country prohibiting its  
deployment, though I am told that deployment with NSEC is not ok.   
Deployment with NSEC3 seems to meet the various privacy requirements,  
and, indeed, a number of European countries are actively deploying  
DNSSEC.  SE, BG, CZ, PT, CH and LI are up and running.  Several others  
are in the process of deploying DNSSEC and will be functional either  
this year or early next year.

For those who care about the technical details, NSEC3 uses a hashed  
space to report intervals of non-existent names.  This makes it  
difficult to enumerate the names in the space.  However, a querier can  
still walk the zone, though the "walk" is more like a drunken, random  
stagger because each probe has to be at some new random place and not  
based on the previous probe.  With the results in hand, one can then  
try a dictionary attack and, if the names are reasonably guessable,  
determine which ones exist.  For most purposes, this difficulty and  
energy to do this has been considered sufficient protection of the  
information to meet the perceived privacy needs.  At the end of the  
day, the information we're protecting is simply the complete list of  
names within a particular zone.  Information associated with any of  
those names, e.g. whois information, is subject to its own controls.

For anyone who wants even stronger protection of the names in the  
zone, the "epsilon" approach does the job.  "Epsilon" refers to  
creating a minimal span for an NSEC response.  This requires using the  
private key on the fly to create the response, and thus poses some  
possible risk of key exposure and also increases the computational  
load.  However, if a hardware box is used which has adequate  
protection of the key and if adequate computational resources are  
available, this will be quite adequate.  For anyone who is having  
trouble following what I have just said, suppose ALPHA, BETA and GAMMA  
are instantiated names within the zone, and someone asks about APPLE.   
The standard NSEC response is (NSEC ALPHA, BETA), which means there is  
nothing between ALPHA and BETA.  The querier is responsible for  
computing that APPLE is lexicographically between ALPHA and BETA.   
This response discloses that BETA is the next name that exists in the  
zone.  If the querier then asks about, say, BETA0000, he will get back  
the response (NSEC BETA GAMMA), and thus he able to "walk the zone" to  
find all the names.  If the zone is signed with NSEC3, the responses  
look like (NSEC xxxx yyyy), where xxxx and yyyy are hashes.  The  
querier is responsible for computing hash(APPLE) and then checking  
that xxxx < hash(APPLE) < yyyy.  This doesn't tell him what names were  
used to compute xxxx or yyyy.  And in the epsilon approach, the  
response to a query about APPLE would be (NSEC APPLE APPLE00000...),  
thereby asserting that APPLE doesn't exist but not disclosing the  
actual name that is next in the zone.

We are providing a map of currently signed and soon to be signed zones  
as part of the web site at http://www.dnssec-deployment.org.  A few  
others are also keeping track of the signed zones.

Cheers,

Steve

On Jun 10, 2010, at 4:46 PM, RJ Atkinson wrote:

> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

---

From: Patrick Frejborg <[email-masked]>
Date: Sat, 12 Jun 2010 09:49:29 +0300

> Your use of the word "this" is perhaps where I get lost.

Sorry, my bad.

What I'm trying to say here is that in the network arena we are trying
to separate the identifier and locator mechanisms completely, it
shouldn't matter if you change network attachment point the sessions
stays up with the help of the identifier.
But when it comes to security nodes you are suggesting the locator and
identifier are tied together in order to be verified against security
rules. I find that a little bit conflicting - in network separate
locator and identifier but in security nodes go ahead and overload.

Back to the example, For a partner connection over a VPN, do I really
care about the location information, does it add any value for me?
When a new incoming session is hitting my firewall the fw should check
the FQDN with the help of the identifier - if the identifier lookup at
DNSSEC returns a FQDN that matches the FQDN in my rule I allow the
session to go to my B2B server (where I could still use IPsec to do
the final authentication). Once the session is verified the fw should
monitor transport parameters and the locator values - if e.g. locator
value changes then the fw needs to check the identifier/FQDN again
before allowing the session to continue. Or use the nonce method.
Does this make sense?

Having said that, however it could be useful to have locator as an
optional parameter in the firewall though the primary authentication
is based upon identifier/FQDN. E.g. if there are services that should
only be reached when you are attached to the office network you would
also use the locator value together with identifier/FQDN verification.
But I would use this only when I have control over the locator value -
here you have a location aware firewall solution.
Having n*external partner sessions coming into my firewall configuring
dynamically locator values in the ruleset gives me cold feet. Instead
the same level of verification can be fetched over one connection to
my DNSSEC server that have reliable connections to other DNSSEC
systems.

Hope this clarify...

-- patte