[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Field Variance Analysis
In message <199508151458.AA06122@interlock.ans.net>, Andy Bayerl writes:
> Craig metz writes:
> I recall that you were mentioning IPSO. I seem to vaguely remember
> that CISCOs can be set to add IPSO tags to outgoing packets. This
> would seem to be something that could screw things up. Anyone recall
> if this is the case?
>The filtering of packets that do not meet a set of configured criteria,
>such as the above, is an extreme case of (perhaps inappropriate) behaviour
>on the part of a router, that can lead to connectivity problems. It relates
>only tangentially to the more general isues of:
IMO, it is inappropriate, but this depends on your view of things.
> a) Whether IPSO options should/may be modified by any router
> b) Whether IPSO options should be part of the authentication stream
> c) Whether the IPSO options should be included at all
>
>The answer to (a) is yes in the most common deployed MLS (multi-level
>security) configurations that I am aware of. In this case, however,
>the "router" in question is really an MLS gateway between networks
>with differing security policies. It could, potentially, be something like
>a CISCO configured to filter and add IPSO appropriately, but will often
>be a B1 or B1/CMW or B2 evaluated MLS system. A configuration might
>look something like this:
>
> Unclassified Classified
> Single Level ---+ MLS +---+ WAN +---+ MLS +---+ Single Level
> Network Gateway 1 + Gateway 2 Network
> |
> |
> |
> +
> MLS +-----+ Multi-level
> Gateway 3 Network
>
>In this case, the single level systems are assumed to be non-MLS systems
>which generate and expect traffic with no IPSO. The MLS gateways add
>IPSO with the appropriate classification and compartments before
>putting it on the WAN. They strip the IPSO before forwarding packets
>to the single level networks.
For single-level to single-level, IPSO is stripped, end of problem.
For single-level to multi-level, tunneling seems reasonable to me.
> 1) The endpoint systems are IPv6 security aware (but not necessarily
> MLS) and do end-to-end authentication. Here, the answer is obviously
> that the IPSO CANNOT be part of the authentication stream, since the
> MLS gateways will be adding, stripping or possibly modifying them.
>
> This presents a problem to the gateways in that IPSO coming from
> the WAN cannot be authenticated and cannot be used reliably for
> routing/filtering decisions.
Luckily, there is no IPSO in IPv6, so this isn't a problem. If you
mean that they have IPv4 AH, then you can strip (single-level to single-level)
or tunnel (any combination of MLS). The latter packet would be:
IPv4 IPSO IPv4 AH ULP
> 2) The endpoint systems use unauthenticated IPv6 (or IPv4) possibly
> with IPSO in the case of the multi-level network. In this case
> the MLS gateways would add the authentication.
>
> (NOTE: I am assuming that this is possible. Can someone please
> tell me if it is so?)
IPv4, yes. IPv6, no.
> In this case, if we assume the routers on the WAN do not muck
> with the IPSO, the IPSO could and probably should be part of the
> authentication stream. This gives us assurance that the IPSO is what
> it says it is, but it still has the well-known flaw of putting up the
> bright red flag that says this secured data worthy of analysis.
In which case use with ESP might be in order...
> 3) We attempt to use the Security Association features of the
> authentication mechanism. If the S/A is strictly end-to-end
> (is this TRUE?), then the answer is simple. The endpoint
> systems (even the single level ones in my diagram) become MLS aware
> to the extent that the S/A has an implied senstivity level. The MLS
> gateways become simple routers, since they are presumably no privy
> to the S/A and cannot make routing decisions based on the
> sensitivity level.
Security associations are currently end-to-end but can be used for
intermediate network authentication. The intermediate network authentication
part allows one to use asymmetric cryptography to create case where the
routers/gateways can verify that a packet is authentic and belongs to a
certain security association (and they can thusly make policy decisions
based on the implied labels) without being able to forge packets. The
pieces aren't all in place yet for intermediate network authentication,
though.
>Number (3) provides the best security and it works for deployment of new
>programs with endpoint systems that use the latest technology. Unfortunately,
>in my experience, that is rarely the case. Usually, there is a VERRRYYYY
>long lag time between program inception and actual deployment and once
>deployed it is extremely difficult to inject updates.
Implicit security labels, IMO, have a number of important benefits
over IPSO. But we have IPSO in use right now, and we have no AH implicit
security labels in use right now.
>I suspect that the answer will probably be encapsulation, as suggested by
>Hillarie. I am not completely sure how works in gory detail, but seems
>to be the only real answer in this type of configuration.
For single-level to single-level, stripping makes more sense to me.
Involve a MLS box, and encapsulation for this case as I explained above
seems more reasonable.
-Craig
References: