#LyX 1.3 created this file. For more info see http://www.lyx.org/
\lyxformat 221
\textclass article
\language english
\inputencoding auto
\fontscheme times
\graphics default
\paperfontsize 12
\spacing single 
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\use_natbib 0
\use_numerical_citations 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation skip
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default

\layout Title

High Level Design of Cient-OSS Connection
\layout Author

Peter Braam, Eric Mei
\layout Date

Feb 13, 2005
\layout Section

Requirements
\layout Itemize

Establish gss connections between clients and OSS.
\layout Itemize

Establish gss connections between servers.
\layout Section

Functional Specification
\layout Standard

In Lustre system, there are several kinds of connections and security options
 can be chosen separately:
\layout Itemize

between client and MDS's
\layout Itemize

between client and OSS's
\layout Itemize

between MDS's
\layout Itemize

between MDS's and OSS's
\layout Standard

Currently we are able to establish secure connections between the client
 and MDS's, simply by adding a mount parameter 'sec=sec_flavor', here sec_flavor
 could be 'krb5i' or 'krb5p' for this moment.
 Now we also need the secure connections between client and OSS's also be
 an option, to prepare for the coming object security features.
 So the original mount option 'sec' will be break into 2 options: 'mds_sec'
 and 'oss_sec'.
\layout Itemize

mount.lustre should be able to recognize options 'mds_sec=sec_flavor' and
 'oss_sec=sec_flavor'.
\layout Itemize

lmt should be able to add 'mds_sec' and 'oss_sec' into xml file and recognizable
 by lconf.
 And lconf should be able to write this info into config log with option
 --write-conf.
\layout Standard

Usually we consider MDS and OSS are trusted nodes, but networks are normally
 not secure.
 So connections of MDS <=> MDS and MDS <=> OSS must be secure in most cases.
 We should also provide security on connections between servers.
\layout Standard

For inter MDS's and MDS's to OSS's, We provide options for lconf and lmt,
 just like client <=> OSS's case:
\layout Itemize

lconf should be able to recognize options '--inter_mds_sec=sec_flavor' and
 '--mds_oss_sec=sec_flavor'.
\layout Itemize

lmt should be able to add 'inter_mds_sec' and 'mds_oss_sec' into xml file
 and recognizable by lconf.
\layout Standard

Servers will have options to accept only certain types of connections.
 When setup OSS/MDS via lconf, option '--deny_sec=sec_flavor[,sec_flavor...]'
 should be recognized and notify OSS/MDS kernel.
 Currently sec_flavor could be 'null', 'krb5i', or 'krb5p'.
\layout Standard

Maybe privacy connections to the OSS servers are only needed from the MDS,
 since there will be no secret transfer between OSS and client.
 And if we in the future support mixed security type in single security
 context, then integrity type might be enough for most cases.
 But anyway we provide the flexibility here.
\layout Section

Use Cases
\layout Subsection

Mount lustre at client
\layout Enumerate

Sysadmin add options into config: lmt --mds_sec krb5p --oss_sec krb5i config.xml.
 And setup OSS/MDS ready.
\layout Enumerate

User mount lustre by 'mount -t lustre server:/mds1/client /mnt/lustre'
\layout Enumerate

Connections to MDS's are privacy protected, connections to OSS's are integrity
 protected.
\layout Enumerate

User umount lustre.
\layout Enumerate

User mount lustre by 'mount -t lustre -o mds_sec=krb5i,oss_sec=krb5p server:/mds
1/client /mnt/lustre'
\layout Enumerate

Connections to MDS's are integrity protected, connections to OSS's are privacy
 protected.
\layout Enumerate

User umount lustre.
\layout Enumerate

User mount lustre by 'mount -t lustre -o mds_sec=krb5p,oss_sec=krb5p server:/mds
1/client /mnt/lustre 
\layout Enumerate

Connections to all MDS's and OSS's are privacy protected.
\layout Subsection

Startup MDS
\layout Enumerate

Sysadmin add options into config: lmt --inter_mds_sec krb5p --mds_oss_sec
 krb5p config.xml
\layout Enumerate

Sysadmin start mds by: lconf --node mds config.xml.
\layout Enumerate

Connections between MDS's and MDS's to OSS's are privacy protected.
\layout Enumerate

Sysadmin stop MDS's.
\layout Enumerate

Sysadmin start mds again by: lconf --node mds --inter_mds_sec=krb5i --mds_oss_se
c=krb5p config.xml.
\layout Enumerate

Connections between MDS's are integrity protected, while MDS's to OSS's
 are privacy protected.
\layout Subsection

Deny certain type of connection
\layout Enumerate

Sysadmin start OSS's by 'lconf --node ost1 --deny_sec=null config.xml'
\layout Enumerate

Sysadmin start MDS's by 'lconf --node mds1 --mds_oss_sec=null config.xml',
 setup will fail because OST reject connection from MDS's.
\layout Enumerate

Sysadmin start MDS's by 'lconf --node mds1 --deny_sec=null --mds_oss_sec=krb5i
 config.xml', will succeed.
\layout Enumerate

Client mount by 'mount -t lustre -o mds_sec=null server:/mds1/client /mnt/lustre
' or 'mount -t lustre -o oss_sec=null server:/mds1/client /mnt/lustre' will
 fail because either MDS's or OSS's will reject connection.
\layout Enumerate

Client mount by 'mount -t lustre -o mds_sec=krb5i,oss_sec=krb5i server:/mds1/cli
ent /mnt/lustre' will succeed.
\layout Section

Logic Specification
\layout Standard

With Kerberos, each service provider needs a service principal, and a correspond
ing service key installed.
 Usually the principal is bound to certain host for security.
 For example, currently lustre service principal is 'lustre/hostname@REALM'.
 While in clustered MDS case, we should use single principal for all MDS's,
 to minimize the administrator burden.
 It should be 'lustre@REALM' for all MDS's.
 Now we should break 'lustre@REALM' into 2 principals: 'mds@REALM' for MDS
 and 'oss@REALM' for OSS.
 All MDS's will be installed service key of 'mds@REALM', while all OSS's
 will be installed service key of 'oss@REALM'.
\layout Standard

If MDS <=> MDS or MDS <=> OSS security is used, we also need start client
 gss daemon (lgssd) on MDS's at proper time.
 This needs to be incorporated into test scripts.
\layout Standard

The interaction between kernel gss module and lgssd need some modification,
 which need to be notified the target service type (i.e.
 mds or oss) to issue the correct gss request.
\layout Standard

Integrating security flavor setting into MDS's startup procedure and client's
 mount procedure needs to be integrated into the MDS startup configuration
 log.
 
\layout Standard

Additionally the MDS and OSS should have configuration options that provide
 information on what kind of connections to accept.
 
\layout Section

State Management
\layout Standard

MDS nodes need run lgssd if gss is active on any inter-server connections.
\layout Standard

No disk format change.
 No special recovery consideration.
\layout Section

Alternatives
\layout Standard

None.
\layout Section

Focus of Inspection
\layout Itemize

Are there more clean design/divide on those new options?
\the_end