Re: mast(4)

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "John" == John S Denker <[email protected]> writes:
    John> It is really nice to have a unified view of all
    John> that stuff.

    John> A diagram or two would probably be helpful to
    John> the non-initiated.

  Sure. I'm not sure what I'd put on the diagram at this time.

    John> So please clarify:  is the MAST (mechanism 1) like a
    John> virtual leased line, or is mast0 like sl0?

  Yes, it has framing, so it is closer to sl0 (or ppp0, since it could be
multiprotocol) than it is to ttyS0.

    John> Also it would help to standardize the terminology:
    John>   -- 3 "ways" of using the device,
    John>   -- 3 "methods"
    John>   -- 3 "mechanisms"
    John> Please pick a term and stick with it.

  okay. 

    John> X) Now I'm wondering whether we need this method.
    John> Isn't it just mechanism 3, in the limit of one
    John> tunnel per mast device?  If so, why not drop
    John> all discussion of the three "mechanisms",
    John> implement only mechanism 3, and discuss the
    John> strategy and tactics of arranging the tunnels
    John> and devices within this unified framework?

  Well, in actual fact, I expect that the code won't care, or even need to be
told what mode it is in. 

  There is some overhead of looking at the SAs and making sure than a
pseudo-ARP table is kept up to date. It is also probably that if you want
things to really be useful, you'll want the underlying tunnel mechanism to
perform keep-alives (make-deads) so that the ARP entry will disappear in a
timely manner. That way, the routes to that tunnel will go away, and routing
will get told about it.

  So, I'm trying to document the user's expectations. I'm not sure I want to
muddy waters with implementation details right now.

  Can you suggest some text?

    John> The mast device MUST play nicely with routers.
    John> This is super-important.

    >> The mast device permits people to create them with:

    John> What kind of people?  By that I mean: Is this an
    John> unprivileged user-mode function like mkdir(2),
    John> or does it require superuser privileges like
    John> mount(2)?

  I would like that it was unpriviledged, but I expect that in fact it will
be mediated by the kernel in some way to a priviledged process. So, I will
write "privledged processes" instead of "people" :-)

    >> flags  is one of .TP MAST PPP the device will operate only
    >> -----                --------
    >> as a point to point device ignoring any bits set in
    >> the nfmark field. .TP MAST NFMARK the  device  will
    >> -----------
    >> examine the nfmark field, extracting bits from this
    >> field to form an SArefence, which is passed to  the
    >> encapsulation  routine.  .TP  MAST NBMA  the device
    >> ---------
    >> will examine virtual layer two information  pointed
    >> to by the skb->mac.raw field.

    John> I'm still not understanding why the three modes
    John> are needed.
    John>   -- Perhaps MAST_PPP mode could be the special case
    John>      that applies whenever no nfmark is found on the packet?
    John>   -- Perhaps MAST_NFMARK could be the special case
    John>      that applies whenever there is only one tunnel
    John>      per mast device?
    John>   -- Then no "flags" are needed.  Everything can be
    John>      handled by mechanism 3.

    John> I'm not trying to argue super-hard about this;  I'm
    John> just fishing for information.  I realize the questions
    John> are getting repetitive;  an answer to any version of
    John> the question will suffice :-).

  so, I'm hedging.

    John> Let's be more explicit about what "default SA" means.
    John> I would like to see different "defaults" on different
    John> mast devices.  Yet more generally than that, it would
    John> seem sensible to treat each of the following as _selectors_
    John> in the IPsec sense of the word:
    John>   -- mast device number
    John>   -- tunnel number within each mast device
    John>   -- nfmark as set by netfilter rules
    John>   -- other selectors as mentioned in
    John>      http://www.ietf.org/rfc/rfc2401.txt

    John> So in particular, on a per-tunnel basis there could
    John> be a default that applies in the absence of an nfmark.
    John> On a per-mast basis there could be a default that
    John> applies if the tunnel doesn't have any opinions on
    John> the matter.  I don't think these need to be arranged
    John> hierarchically;  rather, a general rule-matching
    John> scheme should be easy to implement and easy to
    John> document.   (We need to make it easy to document
    John> and easy for muggles to understand;  otherwise
    John> there will be tremendous support costs down the
    John> road.)

  I think that there is some confusion here.
  The selectors of RFC2401 will be implemented by netfilter rules that use a
new -j IPSEC (or -j IPSEC_OE) to set the SAref {nfmark} bits (similar to -j SETMARK).

  The packet will be diverted to mastX where the SAref will be interpreted as
an index into the SADB. SAref #s are global. The major reason to have
multiple MAST devices at all is:
	 1) playing nicely with routing
	 2) symmetric policies for in/out

  I need to add an example, it is true.

    John> Here's a fairly deep philosophical question:  Do we
    John> want this to be IP-centric?  Or will it encapsulate
    John> layer-3 protocols other than IP?

  It is IP-centric. 

    John> Note that a layer-2 protocol such as "ether" will
    John> happily transport IPX and netbeui and other non-IP
    John> stuff.  Perhaps more to the point, note that GRE
    John> essentially implements layer2-in-IP encapsulation;
    John> page 5 of http://www.ietf.org/rfc/rfc1701.txt
    John> lists about 20 different layer-3 protocols it will
    John> carry.

  Another person could extend the MAST device such that it did automatic GRE
encapsulation. 

    John> If (as stated above) the mast device is going to
    John> include GRE functionality (and I think it should!),
    John> one needs to be quite clear about what layer-2
    John> functionality is provided, and how it is provided.

  It my intention to rewrite ipip and sit to use mast as the front end to
them.

    John> encryption.  One can accomplish a lot more by
    John> instead using GRE layer2-in-IP encapsulation plus
    John> encryption.

  Yes.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email protected] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPjwnrYqHRg3pndX9AQGI4AP/Q51oJAomriDQem8NH/nH2OY7Gc73Q660
xMGyxhN57C83gXL4dvoxOgUtQ2/AlZzObpD2yMgrUgYY8zan8dlxlESlo9YilfFF
3E30sN0s4tHQaSlIKKVT+V6fP3zqEnVKMKda/ONPX/7WbhEXJLBw4MB6qhj1LT4P
4bETd/1pTPo=
=4mJA
-----END PGP SIGNATURE-----