I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
_http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-stjohns-sipso-05.txt
Reviewer: Elwyb Davies
Review Date: 12 October 2008
IETF LC End Date: 23 October 2008
IESG Telechat date: (if known)-
Summary:
There are a number of issues which I believe should be considered before
this document is ready for the IESG.
One possibly major concern is the relationship with the corresponding
IPv4 IPSO option as regards IPv4 over IPv6 and IPv6 over IPv4 tunnels.
It may be that MLS systems explicitly forbid such situations, but if not
this needs to be addressed.
I am aware that there has been extensive discussion on the IETF and SAAG
lists of the impact of this option on the semantics of transport
connections through its concept of virtual networks selected by
Sebsitivity Label value. In my opinion the statements made in this
document about the limited scope of usage for the CALIPSO option mean
that the question of the effect on the wider Internet architecture is
irrelevant. This could be reinforced by choosing '01' for the top two
bits of the option type so that systems that don't understand the
CALIPSO option are required to (silently) discard the labelled packets.
There are certainly issues that arise as a result of the extension of
the transport end point identfier to include the sensitivity label but I
am assuming that the implementors of MLS systems have sufficient
knowledge stemming from the corresponding IPv4 systems to provide a
solution that does what is needed in the limited context they need to
address. An IESG note on the applicability of this option would probably
cover the case.
Likewise I will not revisit the discussions resulting from the secdir
review on the use of the AH integrity checks.
Comments:
S5: Is there any need to specify an ordering constraint on where the
CALIPSO option should appear in the hop-by-hop header?
S5, para 2: ‘normally contains’: I think what this means is that each
hop-by-hop header should contain EXACTLY one CALIPSO option. If a
datagram happens to contain multiple hop-by-hop headers then it might
contain more than one. Be explicit!
S5, para 2: What about IPv4 in IPv6 and IPv6 and IPv4 tunnels? Is there
some relationship between the IPSO/IPv4 security labels and CALIPSO/IPv6
labels? I think maybe the draft needs some coverage of tunnel gateways
as a special case of intermediate systems (or end systems - depending on
how they are seen by the MLS community).
S5.1.1: It would be desirable to explain why the top three bits should
be 000 (it is only done in the IANA section presently.)
S5.1.1/s9.1: The choice of option flags is rather at odds with the
specification.
- The option specifies ‘continue processing’ but if the option should
not escape onto to the global Internet (and ‘all systems’ in the private
networks would be expected to understand CALIPSO options), it would
surely be better to specifiy ‘drop if not understood’.
- The fact that translation can occur if there is no AH header is at
odds with the ‘unchanged en route’ bit. One solution to this would be to
ask for two option type values - one for use with AH and one without.
S5.1.7: The CRC-16 value is just a bit pattern rather than an integer.
S6.2.2/S6.3: ‘A datagram with a Sensitivity Label above the
permitted range MUST be dropped.’ In s6.2.2 this is not classified as a
security fault but in s6.3 it is. Is there some significance in this
difference?
S6.3.3, Item 3: ‘If an
unlabelled packet has been dropped because the
packet is required to be labelled, then a reason
code of "Administratively Prohibited" is used.
In all cases, if an ICMP Error Message is sent,
then it MUST be sent with the same Sensitivity
Label as the rejected datagram.’
Probably need to call out the special case of the unlabelled packet in
the second paragraph here. It would also be useful to remind readers
that the ‘same label’ ought to be OK for sending back out the incoming
interface even though it is no good for the selected outgoing interface.
I had to think about this for a while.
S6.3.3, Item 3, last para: The term ‘OFF’ is not clear here. One assumes
it means ‘not enabled’ but it would be good to be explicit.
S6.4, para 5: Presumably the incoming DOI is also involved in the
choice? At present it is purely on the standard IP parameters.
S9.2: ‘DOI values beginning with decimal 0:0:0 are reserved for
private use amongst consenting parties; values in this range
will not be allocated by IANA to any particular user or user
community. For reasons of interoperability, these DOI values
MUST NOT ever appear on the global public Internet.’
Er.. but these options are NEVER supposed to appear on the global
Internet. Calling out this range specially doesn’t make any sense.
S9.2: The proposed distinction between commercial operations and
government agencies is probably unusable in today’s environment of
semi-commercial agencies used for arm’s length operations by many
governments. Be that as it may, the whole attempt to be parsimonious
with allocations of DOIs seems pretty pointless. Given that there are
more than 4*10^9 DOI numbers and realistically there may be a few
hundred organisations seeking DOI allocations, suggesting to IANA that
they might deny a single organisation seeking to acquire (say) more than
100 DOIs, but otherwise allocating on a FCFS basis would seem to be
unlikely to cause problems. I really cannot see that 4*10^7
organisations will be implementing distinct MLS systems! Some advice to
organisations that they really don’t want to have lots of DOIs and to
IANA to refuse stupidly large requests would seem to be the appropriate
way to go.
Editorial:
General: The RFC Editor insists on ‘e.g.,’ and ‘i.e.,’ rather than
‘e.g.’ and ‘i.e.’
S2.3 et seq: The verb ‘to dominate’ is used with a particular technical
meaning that is not defined.
S2.5.1: The verb ‘to promote’ is used with a particular technical
meaning that is not defined.
S2, para 2: s/.[CW87]/{CW87}./
S4, para 4: s/unaware to assign/unable to assign/
S5.1, para 5: s/envelopes/envelops/
S5.1.3 para 2: s/but instead/but also/
S9.2, 2nd para after ‘255:0:0:0..’: s/DOI values beginning with
decimcal/DOI values beginning with decimal/
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf