Subject: Gen-art review of draft-stjohns-sipso-05.txt

From: Elwyn Davies <[email-masked]>
Date: Sun, 12 Oct 2008 23:59:40 +0100

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 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf