Subject: zill-ipv6wg-zone-prefixlen-00 comments

From: Pekka Savola <[email-masked]>
Date: Thu, 6 Mar 2003 12:37:06 +0200 (EET)

A few comments on the individual submission.

big issues:
-----------

==> note to self and to the w.g.: this is very similar to Bellovin's
access-prefix draft, but simpler (with advantages / drawbacks that result
from that).  So, I believe it might be useful to try to compare these two
approaches so we could better understand which features are needed and which
are net.

==> note that if one sets the O field to 1 but forgets to set "Org
PrefixLen", org prefixlen defaults to zero, and makes all of the 
Internet a trusted, "in-organization" zone (as the field was previously
reserved").

This must be stated in the security considerations.

I would also recommend that the prefix length "0" in conjunction with
O-bit=0 is a special value which MUST be treated as equal to "none", 
and a possible error be logged.  This reduces the amount of flexibility
slightly, but the tradeoff seems too huge, otherwise.

     5. Security Considerations

==> it should be noted that a single on-off binary value
in-org,outside-of-org may not be granular/flexible enough,
and that as many attacks come from inside the organization (either by an
insider attack or breaking into a system in the organization and attacking
there), depending too heavily on security of the "in-organization" may not
be a good idea.

substantial/semi-editorial:
---------------------------

        Option format to allow the router to also advertise the length of
        the advertised prefix which belongs to the same organization (or
        other administrative entity). 

==> clarify "other administrative entity", think the point here was to say
like "not necessary the same organization, but also otherwise named, *same*
administrative entity"?

==> if not, this may require syncing elsewhere in the draft (where it
discusses same-org, same-admin-entity)

editorial:
----------

     IPv6 Working Group                                 Brian Zill
     Internet Draft                                     Microsoft

==> "IPv6 WG" is premature as this is not yet a w.g. document..?

==> the whole document should be shifted 5 characters to the left; it
exceeds the maximum line length.

     References

==> split the references explicitly, even though those are probably all
Normative.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Thu, 6 Mar 2003 12:41:49 +0200 (EET)

> O-bit=0 is a special value which MUST be treated as equal to "none", 

I meant O-bit=1, of course.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 06 Mar 2003 13:46:43 +0200

I have a comment on the Zill draft as well as the Bellovin
draft. The Zill draft lacks instructions for the host on
what it should *do* with the information it receives.
The Bellovin draft, however, describes this in its
Section 2.3. I'm fine with that description. However,
I worry about one paragraph:

    In their default configuration, devices MUST NOT accept packets from
    any non-link-local prefixes until they have received suitable
    advertisements.  However, there MAY be a configuration option to
    permit acceptance of packets with the current link's prefix.

If this text is to be taken literally, it would imply that
a host that supports this extension could never communicate
outside the link if the router doesn't support the same extension.
I'm assuming this only applies *if* the use of the advertisements
has been configured on?

And then I have some higher-level questions. Steven says himself
in the draft that its an open question whether such an extension
should exist. I have a few related questions. One question is why
this would have to be done by the nodes, wouldn't it be simpler
to do this in the routers (acting also as firewalls)? Note that
to use the extension, you'd have to configure the routers anyway.
In this case the argument about the hardness of filter configuration
on a toaster isn't very good.

Secondly, I know you Steven have worked on distributed firewalls.
Do you think we should have a very simple mechanism for filtering
as a part of neighbor discovery, a more powerful but also more
complex mechanism running at higher layers, or both?

Jari

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 15 Mar 2003 23:18:33 -0500

>what it should *do* with the information it receives.

There's certainly no reason that my behavioral description couldn't
be copied into Zill's draft.  My concern about that draft, apart from 
Pekka's comments (and I agree with them), is that I think that the 
Prefix Information option is getting overloaded.  Zill's draft shows 
four different flags -- what are the interactions between those flags?
Are all 16 combinations of them legal?  (I confess that I don't know 
what the R flag is, nor have I been able to find its definition in a 
quick grep through the RFC and drafts directories.)  The Router 
Renumbering RFC might have to be updated to cover either draft.

But draft-zill is certainly simpler than mine, and I have no objection
to it being adopted.  

>I'm assuming this only applies *if* the use of the advertisements

Actually, I meant what I said, though I've changed the text to read

	In their default configuration, devices that use this option...

If your IPv6 light bulb doesn't have any better access controls than 
this, and if your router doesn't support this option -- then yes, that 
light bulb shouldn't talk off-link; it has no other way of knowing 
who's authorized to turn it on or off.
>on a toaster isn't very good.

The problem with doing the filtering in the router is that the option 
then applies to all nodes behind that router, even if they have better 
security mechanisms.  I may want this mechanism to apply to most 
of my hosts, but not to the hosts that run ssh servers.  Or perhaps the 
unprotected hosts are my incoming mail gateways.
>complex mechanism running at higher layers, or both?
I think that configuration of a real distributed firewall is a much 
more complex question, and not something I want to do on the fly in 
this working group.  Furthermore, I very much don't want it to be 
router-based -- my paper points out that first, a lot of the benefit is 
for complex topologies, when you don't have a trusted perimeter router. 
Furthermore, my design relies heavily on ipsec and ipsec certificates.  
That's much more than I want to put into a router advertisement message.

Should there be this sort of simplistic filtering based on router 
behavior?  I'm not certain.  But there seemed to be a feeling in the 
working group that that was one of the benefits of site-local was the 
built-in access control.  We can't easily carry it further (i.e., put 
more general ACLs in the messages) without resorting to lots of 
reliable multicast groups on each link.  I don't think I want to go 
there.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)