Re: mast(4)

Michael Richardson wrote:

 >     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.

You may remember some words and diagrams from OLS a couple
of years ago:
   http://www.monmouth.com/~jsd/vpn/ipsec+routing/mast.htm

The drawtool source for the diagrams is available if
you want to change or extend them.....

> 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.

Sounds about right.

> 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?

   http://www.monmouth.com/~jsd/vpn/ipsec+routing/mast.htm

> I would like that it was unpriviledged,

Good.

> 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" :-)

There needs to be both.  There needs to be an unprivileged
interface, analogous to the way users can pipe stuff to 'lpr',
which in turn results in some privileged things happening,
such as i/o to the /dev/lp hardware.

> 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).

Sounds good.

 >   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.

OK.

 >     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.

Mumble grumble.

 >     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.

Mumble grumble.

 >     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.

Why not GRE?  (See below for more on this.)

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

So we agree!

Is there any reason to believe ipip is easier or better than GRE?
Is there any reason to believe sit is easier or better than GRE?

I don't see the advantage of dealing with ipip+sit (two
things) when dealing with GRE (one thing) can handle IPv4,
IPv6, and a lot more.

In particular, as outlined in the document
   http://www.monmouth.com/~jsd/vpn/ipsec+routing/mast.htm
it really helps to think of the mast device as a _device_.
Devices are pretty much layer-2 creatures, and GRE is pretty
much a virtual layer 2 (in contrast to ipip and sit, which
are pretty much virtual layer 3s, if you can fit them into
the layer model at all).

=========

Tangential remark:  The mast device has important ramifications
for Extemporaneous, Scalable IPsec (aka opportunism);  see
   http://www.monmouth.com/~jsd/vpn/ipsec+routing/mast.htm#sec-extempo