Re: mast(4)

Michael Richardson wrote:

> This is still a bit rough.

It is very useful as it is.
It is super-important to circulate such ideas
in the rough stage.  By the time the ideas become
non-rough, it's often too late to solicit
meaningful improvements from the community.

> The mast device provides a way to anchor routing daemon to virtual
> topologies. It provides a constant abstraction to various kinds of
> tunnelling technology: IP-encap (protocol 4), IPv6 (protocol 41), GRE
> (protocol 47), ESP (protocol 50), AH (protocol 51), IPIP (protocol
> 94) and ENCAP (pro­ tocol 98)

It is really nice to have a unified view of all
that stuff.

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

> There are three ways that a mast can be used. They relate to how
> additional information (i.e. policy) is attached to the packets that
> are directed toward the device.

I'm struggling to understand the three mechanisms.

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

> The simplest way is that a mast is considered to be an open sink to
> which packets that need a predefined kind of encapsulation may be
> sent. The mast acts as a point to point device - a virtual leased
> line - sending all packets into the an underlying tunnel mechanism,
> having attached a default security policy to each packet. (As is
> described under "SECURITY POLICY", the nfmark is used). A mast de­ 
> vice used in this way should be indistinguishable from a SLIP
> interface - it has no layer 2 protocol. The layer two link status of
> the mast device may reflect the state of the dead peer detection
> status for the remote end point, if this feature has been enabled.

There are some ambiguities here.

1) Consider the contrast:

   1a) A virtual leased line might have no formatting at all
(at any layer greater than 1).  In the simplest case,
imagine two serial cards (one on each machine) talking
to each other.  All you get is a byte stream.

   1b) A virtual SLIP device is quite a bit more than that.
As the name implies (Serial-Line IP) the SLIP device
has an IP address and netmask.

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

2) Probably the same question in other words:

> it has no layer 2 protocol.

Does this mean it provides neither layer 2 nor anything
higher, or does it mean that it provides layer 3 without
needing (and without providing) anything at layer 2?

> The second way that a mast device may be used is as an en­ try into a
> non-broadcast, multiple access encapsulation media. The choice of a
> particular tunnel is indicated by setting bits in the control
> structure (the skb). This is described under "SECURITY POLICY".

I'm not understanding why this would ever be
preferred over mechanism 3 (below).  Users
can ignore the ARP-like features of mechanism
3 if they want.

> The third way that a mast device may be used is with a virtual link
> layer. This is a variation of the previous method - the device is
> still a non-broadcast, multiple ac­ cess device, except that the mast
> device supports a layer two similar to ARP. The layer two information
> that the network stack attaches to each packet will be used to de­ 
> termine which tunnel will be used. The mast device will keep the
> neighbour cache updated with liveness info. If the tunnel to a given
> neighbour is known to be down (such as, because of a lack of a key,
> or expiration of such), then the neighbour cache entry will be
> removed.

OK.

> Packets that emerge from the mast device will be marked by the tunnel
> on which the packet was received. The choice of which mast device to
> emerge from is also defined by the tunnel decapsulation mechanism.

To be explicit:
The user MAY define an arbitrary number of mast devices.
The user MAY attach an arbitrary number of tunnels to
each mast device.

 > Typically, a unique device will be created per major policy category.
 > This is done to simply the firewall rules.

Right.

> The first method is most appropriate for use on the client side of a
> road warrior configuration, or when there is a sufficiently small
> number of VPN tunnels that it is prac­ tical (or desireable) for each
> tunnel to have its own de­ vice associated with it. The
> simplification of firewall rules for output is the primary benefit of
> this mode.

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

> The second mechanism is used by more traditional VPN topologies, and
> by Opportunistic Encryption. These two categories of use mandate a
> different output device per major policy. Both would use specific
> setting of policy bits (skb->nfmark) for selection of outgoing
> policy.

Repeat previous remark "(X)".

> The third mechanism, where an ARP-like layer two is main­ tained, is
> most appropriate for layered systems like the xbone, where there may
> be too many tunnels for it to be practical to create a device per
> tunnel. At the same time, the reachability information that the
> layer-two tables provide can be used by routing systems to determine
> the optimal path.

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

> The mast device permits people to create them with:

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


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

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

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

 > SECURITY POLICY

It's good to see discussion of this.
Early versions of freeswan were (shall we say)
a bit vague about how security policy was to
be implemented.


 >        When the mast devices is configured to be  in  MAST NFMARK

I am going to ignore that sentence, because I think
the following sentences can be (re)interpreted to
apply more broadly than that...

 >                                                           -
 >        mode, it will examine the skb->nfmark field of each incom­
 >        ing packet. The upper 24 bits of the nfmark  will  be  ex­
 >        tracted. If bit 31 is set, then the nfmark will be consid­
 >        ered to be have been initialized. Bits 8 thru 30 are  then
 >        shifted  to  the right, resulting in a 23 bit number. This
 >        is considered the flowref.
 >
 >
 >        If the bit is not set, then the packet will have  the  de­
 >        fault SA applied to it.

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

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

======================================

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

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

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

IMHO there is great conceptual simplicity and great
power to be gained by focussing on the layer-2
features.  Do a good job on the layer-2 features,
and the rest is easy.

As has been previously discussed, IPsec tunnel mode
can be understood, to a fair approximation, as
IP-in-IP encapsulation plus IPsec transport-mode
encryption.  One can accomplish a lot more by
instead using GRE layer2-in-IP encapsulation plus
encryption.