[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comments on IPSO and AH/ESP




[my co-chair hat is off :-]

IPsec folks,

% And in fact, not only CAN they be configured to mess with IPSO,
% CISCO's are shipped with a DEFAULT behaviour that allows only
% unclassified BSO traffic thru. To allow other IPSO (of the RFC1108
% flavor) thru you have to jump thru hoops to figure out how to
% configure the routers. And to this day I am not sure how to do that.

Folks at NRL and other parts of the DoD do know how to do it.  It
isn't THAT hard to do.  Also, by default a Cisco will pass traffic
without any IPSO label whatsoever.  The key thing is that no router
will by default munge any IPSO labels -- IPSO munging is something
that the router admin must specifically turn on and configure in each
router.

% 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:

%  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:

Note: IPSO is strictly an IPv4 option.  There is currently no analogous
	option for IPv6.  Ditto for CIPSO at present.

I agree that it is not uncommon.  It is widely viewed within the DoD
as being a "least of all evils".  Many in the DoD believe that 
using unauthenticated IPSO labels to perform Mandatory Access Controls
for security is highly undesirable because of the security risk.
I personally dislike IPSO labels for that latter reason and because
they advertise "this packet is a high-value target, see the IPSO label".

One of the goals of the IPsec WG from long ago was to be able to
authenticate IPSO labels from source to destination, thus potentially
permitting a filtering router with a MAC policy to authenticate the
label to provide assurance that the MAC policy was implemented as
intended and was not being spoofed.

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

They do the above only when the sys/net admin wants that done as part
of policy.  More often in my experience, unlabeled packets are sent,
no router mangling occurs, and unlabeled packets are implicitly
treated as "unclassified".   The multi-level systems generally do
include IPSO labels with the label reflecting the level of the data
in the packet.

% The MLS gateway 3 probably just passes the IPSO on unmodified but here
% there are also cases where the IPSO could be changed to reflect differing
% policies. A case in point might be where the WAN has routers that only
% pass RFC1108 BSO IPSO. In that case the ESO (compartments) would be
% dropped before going out on the WAN.

Again, these are LOCAL policies.  If users wish to shoot themselves in
the foot, no RFC will prohibit that.  But if they want to use AH with
the labels, they won't want or need to configure the routers to munge
IPSO options.

% The WAN is assumed to be reliably authenticated, possibly encrypted,
% and physically secure data link. 

It is always encrypted, with either a link encryptor or an IP
encryptor, but never in my experience has per-packet authentication
(which authentication IS needed and currently missing and is something
AH ought to be providing).

% The caveat here of course would be that it is unlikely that highly
% classified data would be routed over the big bad Internet...

Yes.  Certainly it is never sent without military-grade encryption being
used, typically with SP3D as the encapsulation protocol if IP encryption
is in use.

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

Typo: Substitute "IPv4" above where it says "IPv6".  IPSO is ONLY IPv4.

I would contradict this directly and say that it is obvious that IPSO
MUST be authenticated in order to prevent spoofing attacks and false
downgrading of information.  I am aware of major router vendorS that
report are implementing AH for IPv4 (I can't say which ones, sorry).
There are MANY users and a few good vendors who want to have routers
authenticate but not modify IPSO labels.  If IPSO is included in the
AH computation, this desirable goal will almost certainly come to
pass.  If IPSO is excluded from the AH computation, this will
definitely be precluded.  The community is definitely on a major
decision point here.

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

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

No.  The IPv6 end systems will use authenticated or encrypted packets
and will include the security level as part of the Security
Association data as the specs already make clear and will NOT use IPSO

[IPSO is for IPv4 only in any event.  Please go read the spec language
about implicit labeling being "must implement".

IPv4 systems SHOULD use authentication and add their own labels.  It
is likely that future DoD contracts (e.g. Navy's TAC-5, worth a few
Billion $) will make support for authenticated IPSO labels a "must
implement in hosts if you want to bid" item.  In the past, vendors
have implemented new features of similar complexity in order to bid on
large DoD contracts (e.g. TAC-3, TAC-4).

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

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

IMHO, this is the best approach, particularly if we use encryption
rather than authentication.  For MLS, one really wants encryption to
separate the different security levels.

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

Systems that can't be updated will be forced to not use ANY of the IPsec
mechanisms by the same reasoning that you use in the paragraph above.
For them there will be no change in the status quo.

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

One obvious problem with encapsulation is that if IPSO is in the inner
packet, it can't easily be examined by the routers to perform
filtering as routers do right now.  This means the same
interoperability issues with the status quo will also exist in this
case.

It is really important to understand that IPSO is almost never used
outside of military networks and is almost never used within The
Internet.  Within those military networks, the network operator has
fairly total control over how the network and its routers are
configured.  So if they don't want to use AH or ESP, they simply
decide not to use it.

The specs as agreed to and as published are and always were intended to
provide end2end authentication of the entire IP packet, not just the
upper-layer data portion as Bill as recently misstated.

I don't think it is hard to implement the specs as written and suggest
perusal of the code I announced earlier today before we continue that
line of discussion, if we do.

Now as a process comment, the specs are out as Proposed Standard and
the usual IETF way is that the next 6 months or so will be spent
implementing and testing interoperability.  After that period, the WG
will be asked to consider moving the specs to Draft Standard.  At that
point the WG can alter/amend/clarify the specs as WG consensus
dictates and subject, as always, to IESG approval.  

As document editor, I _will_ edit the documents in accordance with WG
consensus, as best the co-chairs and Security AD can determine it,
even if I personally disagree with the changes.

NRL is ready to do interoperability testing for IPv4 or IPv6 AH or ESP
today.  Mind, our implementation is per the Proposed Standard RFCs.
If you want to test, send me email and we can arrange something.

Ran
rja@cs.nrl.navy.mil

employed by, but not speaking officialy for the
	US Naval Research Laboratory


Follow-Ups: