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/