In message <[EMAIL PROTECTED]>, Jari Arkko writes:
>
>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.
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.
>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?
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.
>
>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.
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.
>
>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?
>
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)
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
