Subject: [homenet] homenet hosts security requirements and realm discovery

From: Dmitry Anipko <[email-masked]>
Date: Tue, 31 Jul 2012 02:10:02 +0000

In draft-ietf-homenet-arch-04, I was looking for and could not find a requirement for the network to provide homenet hosts with the information about the realms - as a basic example, which prefixes are associated with the most trusted homenet realm, as opposed to guest/Internet.

For the hosts, described in section 3.6.3, which opt into transparent inbound communication, this capability would be useful to enable on the host scenarios such as "share resource A, require user authentication for guest/Internet realms and don't require for homenet", or "share resource B within the homenet only, while share resource C with all realms".

Is there already a section that implies such requirement, or if not, are there concerns with adding such requirement to the draft?

-Dmitry

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 31 Jul 2012 17:30:46 -0400

In message <[email-masked]>
Dmitry Anipko writes:
 
> In draft-ietf-homenet-arch-04, I was looking for and could not find a
> requirement for the network to provide homenet hosts with the
> information about the realms - as a basic example, which prefixes are
> associated with the most trusted homenet realm, as opposed to
> guest/Internet.
>  
> For the hosts, described in section 3.6.3, which opt into transparent
> inbound communication, this capability would be useful to enable on
> the host scenarios such as "share resource A, require user
> authentication for guest/Internet realms and don't require for
> homenet", or "share resource B within the homenet only, while share
> resource C with all realms".
>  
> Is there already a section that implies such requirement, or if not,
> are there concerns with adding such requirement to the draft?
>  
> -Dmitry

Dmitry,

Look at the first sentence in section 3.3.1.  "The homenet will need
to be aware of the extent of its own 'site', which will define the
borders for ULAs, site scope multicast, service discovery and security
policies."

A host gets connected to a realm and the realm simply determines the
boundary of where the ULA, site scope multicast, etc is propogated
beyond the local subnet.  In many cases a realm consists of one local
subnet.  Borders in this case imply a firewall, though the realms
could have a null firewall (pass everything) if security is
accomplished using IPSEC, TLS, or applications layer security.

In a current enterprise, internal WiFi users are connected to a subset
of channels with slightly stronger authentication.  Guest within the
building may use a shared password authentication given to them when
they enter the building or none at all (open WiFi if the building has
RF shielding or the campus is large enough that WiFi range doesn't
extend beyond the campus (or both).

Section 3.6.3 does not imply that host security should be based on the
homenet realm.  A host security using TLS for example should be
applied the same regardless of the homenet realm.  For example, a
connection from a mobile phone (without WiFi) would come from the
external internet homenet realm.

Firewalls should only block access to insecure or very weakly secured
services behind the firewall.  IMHO there should be no insecure or
very weakly secured services anywhere.  If so, there is no need for a
firewall.  (BTW - the 1990s T3-NSFNET infrastructure and NMS had no
firewalls and was quite secure even by today's standards, much more
secure than most enterprises that I have encountered).

This has nothing to do with any notion of domain, realm, etc in
Windows (or krb5/gssapi) if that is the question.

Curtis