John Vollbrecht
This page is to outline issues for token marking paper.
pages
TokenPictures
Some issues to consider for token marking paper
What are the use cases we want to consider for possible use with token marking?
a)
two end systems withing the same organization
infrastructure req = level 2 switch at each end to mark each connection
Note that this seems identical to creating a key between two end systems and
using it to sign/encrypt data between the systems.
This may be the ultimate value of the token signing of streams. If this is valuable for
pairs of endpoints multiplexing streams, then it proves the value of tokens
LG: This mechanisms may also force pairs of end systems that have a trust relationship only to talk to each other via
designated or a set of restricted ports.
Port locking via its MAC address on a layer 2 switch is a similar mechanism aimed at restricting end-station access to a
specific port. Port-locking is a valuable feature implemented within enterprise networks. This mechasism allows sessions to be
locked to infrastructure ports.
b) possible out of band “alternative path” to main internet
switch can identify valid traffic
this case requires that a switch be set to identify marked traffic to
take a different path than the "default" thru the net
this requires that traffic going toward the switch be marked by the
system sending it and that the switch be configured to recognize the mark
traffic in different directions could take different paths if marked appropriately
traffic identification requires some infrastructure that determines which streams are
marked and which are not.
c) identifying traffic on multi-organization path
multi-organization naming and control
in this scenario the mark identifies a stream that uses a multiorg path - e.g. going from
Amsterdam to Chicago to UIC.
mark must be known by all orgs
could modify mark at each switch as in MPLS labels, but then hard to authenticate
the stream based on a hash done at origin.
I am not sure how MPLS/GMPLS identifies path for eventual takedown
this could be the same in our token marking scheme
infrastructure requires sending "key" to each switch
d) pre-setup of path for “later” activation
This seems like doing EAP/RADIUS for a two switch environment (a above)
This seems independent of the actual token authentication process itself. Must prove that tokens are valuable
before spending lots of time working on this.
e) authentication of frames on path
authentication is planned using some sort of hash (could be same as 802.11's set of possibilities?)
What are some interesting issues to correlate with taken marking
a) exchange point functionality
marking is possible in frames - for L2 traffic frames are appropriate (as in MPLS)
- for IP traffic could use IP header for token, use MPLS for switching - is this plausible?
- for wave switching would need some "control band" to carry token info - is this plausible
b) comparability with frame relay and ADSL
frame relay is typically best effort multiplexing, ADSL is more fixed bw
either seems possible with this. which is actually more interesting from UvA point of view?
c) possibility of inclusion with lambda switching
is there a "control band possibility with Lambda switching?
can I have "control band" accross multiple organizations?
d) use with MPLS – what is the difference between a “label” and a token
Seems that the token goes with the frame and doesn't change from sw to sw. label is setup for a segment of a path
e) comparison with 802.1X and
IKEv2/IPSec
These seem very similar at the authorization level if only two parties are involved. For multiple parties the ability to
do multi organizational authorization needs to be worked out. May be more like 802.1ae. We should check.
f) infrastructure required to support token making
this requires that token be manufactured somewhere and given to path generator and to switches on path
token is different in each direction
all this assumes point to point connections
g) use with Grid Resource management
Grid resource authorization and setup seems very similar to initial key creation and deployment
termination of path by any switch should terminate path at other switches
h) locking of path used to transmit traffic as opposed to securing the content of traffic
In the wave switch environment one knows who is connected where. Do we also need to prove the data on the path is valid,
or is this only useful for multiplexed streams within the path?
i) key management
seems that key management from EAP and IETF in general would be useful. We should reference this
j) setting allowed paths before trying to send data
one question is whether all mapping of a path needs to be done before sending data or if mapping can be done based on
on initial token -
Some additional issues
a) difference between user authentication and authentication of traffic
It is interesting that in 802.11 one talks about authentication of a packet as authenticating the hash on data packet
diifferent that authenticating the user at the beginning of the connection
b) reqirement for distribution of key(s) (as from AAA server to AP) vs generation of keys (as by SSL) at each end.
user authentication seems to require generation of keys, distribution of keys is done to support authentication of packets
c) Value of authenticating traffic on path within a single organization vs crossing multiple organizations
d) Value of cross organizational ete path setting
is setting ete paths important for networks in general? will internet evolve into ete paths for data transfers? seems possible
e) Do you have to encrypt traffic if one can guarantee a secure path?
I guess that this is not needed if path is secure. so perhaps some segments may not need this capability? I am not sure
how one knows if this is the case.
f) What level is controlled by tokens (e.g. l1, 1.5,2,3
)
This is important to enumerate in order to be sure people understand the intent of this
some possible add-ons
a) use of authentication in level 2 switching – 802.1ae for example
b) setting up authentication within MPLS/GMPLS
c) RFC 2904 tie in with token marking
d) Multiplexing of token marked streams vs setting up of lambdas for ete connections
In general this seems to map to best effort vs fixed bw - do others agree?
e) Difference between ete validity (e.g. IPSec) and point to point validity with tokens checking at each exchange point
An interesting question is whether doing the token checking at each switch proves ete validity without checking the token at
the receiving end. If one does check the token at the receiving end then what does the checking at intermediate switches do?
- I think it may prohibit hacking at the intermediate switches
- I think it may be used only on network equipment to set up path, not ete circuit
Comments by John 2006-03-03
Initial summary seems to be
- need to separate token marking from user authentication/ authorization
- need to define what point of marking is - ete stream validation or path validation
- lots of tie ins to RFC2904, 802.1X, IKEv2, Grid Resource Management,
- next steps in my opinion are to put together an abstract and architecture diagram showin this
Categories
CategoryUsers
There are no comments on this page. [Add comment]