Subject: Re: [rrg] ILNP q1: Scalability

From: [email-masked] (Noel Chiappa)
Date: Tue, 8 Jun 2010 14:52:29 -0400 (EDT)

> From: Patrick Frejborg <[email-masked]>

    > It would be wonderful if the firewall rules is based only on the
    > identifiers ... Then the enterprise could change the locator values
    > and no need to worry about their partner connections, much less
    > costs is caused by topology changes. 

This has been pointed out before, in the context of renumbering - it's
'relatively' (in the sense of 'easier than other things' - I know it's
still non-trivial) easy to change local configuration information, but
information that _other_ places have stored about you is much harder.

    > I'm afraid that the security part in ILNP is too weak to convince
    > the security architects that you could build your security rules
    > only on identifier information ... I could be wrong about this...

This is the exact same 'argument' that was raised against 8+8. It was
incorrect then (Steve Bellovin, if memory serves, prepared a succint
analysis of why that line of reasoning was incorrect), and it's still
incorrect now.

It's relatively easy to design a system which has at least as much
security as the faux security that the 'address-based authentication' of
the current system (even with DNSSec) has.

	Noel

---

From: Patrick Frejborg <[email-masked]>
Date: Wed, 9 Jun 2010 00:52:40 +0300

> the current system (even with DNSSec) has.

Please elaborate around this a little bit more, thanks.

If I use B2B server in the DMZ and my partner is behind a VPN
connection then having an "address based authentication" gives me some
level of protection - when returning packets goes out from my B2B
server they are routed by the firewall towards the VPN connection -
even though the source address would have been faked and arriving from
somewhere else than the VPN connection. So the bad guy can't get the
data from my B2B.

If the "address-based authentication"gets replaced by identifier then
the firewall doesn't care about the locator anymore, the bad guy
steels the partner's identifier (public DNS record) and put his own
locator on the packets. My firewall would route the returning packets
according to the locator and data goes to the bad guy.

How can this be prevented by DNSSEC? It ensures that the resolver gets
to the correct record information but how can my B2B or firewall know
that the request comes from the partner - should the firewall or B2B
verify  the source locator  from DNSSEC before responding to the
request?

RFC 3383 says:
   - While some participants in the meeting were interested in
     protecting against disclosure of DNS data to unauthorized parties,
     the design team made an explicit decision that "DNS data is
     `public'", and ruled all threats of data disclosure explicitly out
     of scope for DNSSEC.

   - While some participants in the meeting were interested in
     authentication of DNS clients and servers as a basis for access
     control, this work was also ruled out of scope for DNSSEC per se.

What do I miss?

-- patte

---

From: Tony Li <[email-masked]>
Date: Tue, 08 Jun 2010 19:03:41 -0700

Hi Patrick,

> somewhere else than the VPN connection. So the bad guy can't get the

In this case, is the firewall routing based on your source locator or on the
destination locator?  Presumably, if it's part of your VPN service, that
return routing is purely based on the destination locator.

What you'd really like is to block packets arriving at your server that
don't come off of the VPN.  It is not unreasonable to do this with source
locator filters in this specific case, because you can (reasonably)
guarantee that the return packets will be directed to the VPN.

> according to the locator and data goes to the bad guy.

Given that ILNP identifiers are not global, doing identification purely on
identifier is not going to help.  If your server is not willing to perform
application level authentication, then you can have your firewall perform
authentication against a static locator and identifier binding, or against a
pre-shared DNS name.  The latter has the advantage that it allows locator
mobility for your correspondent.

This security seems like it is equivalent to IPv4 and maybe a touch better
given DNSSEC. 

> verify  the source locator  from DNSSEC before responding to the

Yes, verifying the source locator is the correct thing to do, or resorting
to higher levels of authentication (e.g., IPsec).

>      control, this work was also ruled out of scope for DNSSEC per se.

Why is this relevant?  This is clearly in scope for an architecture.  And
clearly DNSSEC privacy is not required for this either.

Regards,
Tony

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 10 Jun 2010 08:49:32 +0300

Hi Tony,

sorry for the delay, wish I could cope up with the discussion better...

> guarantee that the return packets will be directed to the VPN.

Right, use uRFP on the locator value

> This security seems like it is equivalent to IPv4 and maybe a touch better

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

> to higher levels of authentication (e.g., IPsec).

But then we are back in the renumbering challenge, if the partner
changes his locator value I have to change my rule base simultaneously
- and we are not really improving mobility here (either worsening it
from current solution). 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

> clearly DNSSEC privacy is not required for this either.

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. 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. Throwing a shim header
on the problem won't help either - in site mobility scenario the edge
locator remain unchanged and the core locator changes, so here you
could use edge locator value to create fw rules. 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 - 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).

Filtering on IP addresses is not a good security solution, I agree on
that - but it is used everywhere and it is not the final
authentication method, instead you are limiting access from part of
the Internet to  particular zones, then you have some additional
authentication methods on the server to have final access to the
applications. If the locator is flexible we need something else to be
able to set the scope of zones.

-- patte