-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven M. Bellovin wrote: > On Sun, 05 Oct 2008 17:40:18 -0400 > Bill Sommerfeld <sommerfeld at sun.com> wrote: > >> On Fri, 2008-10-03 at 14:54 -0700, Joe Touch wrote: >>> I.e., if this is really a virtual network, there's a LOT of work >>> left to be done. >> All that behavioral description work is entirely independent of the >> label encoding draft, and there is IMHO no rational reason to delay >> publication of draft-stjohns-sipso-* (and the allocation of relelvant >> codepoints by IANA) in order to document minutiae of behavior which >> are better spelled out in separate drafts documenting the interaction >> of MLS labeling and specific protocols. >> > I disagree -- I think there have been enough points raised on the > clarity of the threat model and some behavioral points that I think > more discussion is indicated. Apart from that, it does prescribe > behavior at variance with the TCP standard. (As I noted, I think this > document is more correct, but it nevertheless contradicts 793.) I'm not entirely sure how to proceed. Here's the issue: The goal of draft-stjohns-sipso-* appears to be limited to extending endpoint identifiers primarily for transport protocols - TCP in specific. I.e., it extends transport names (AFAICT). That would make sense if there were security levels associated with ports, as a TCP option. However, the draft is described as an extension of IP, which implies a broader extension of the endpoint namespace (as the document describes). Here's the catch: - - if the doc focuses only on TCP, then: a) the 'virtual network' description needs revision to focus on extending only the impact on transport, notably TCP b) ICMP needs to be addressed, i.e., either ICMP needs to be extended similarly, or the impact on TCP needs to be described. this means either: i) ICMPs would be potentially processed by the security level of the payload, not the header or ii) TCP under MLS should assume ICMPs are black-holed, and thus should disable PMTUD. c) DNS needs to be addressed, notably how SRV records would work in this environment - - if the doc really does need to extend the whole network to understand MLS, then the impact on the whole network needs to be considered - this includes forwarding, routing, multicast, DNS, etc. These are neither minutae nor can these issues be relegated to supplemental documents. If you have a system based on what has been written thus far, you're already making assumptions about the above (some problematic, IMO), and you need to do more than just ignore these elephants. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjq3jsACgkQE5f5cImnZrurAgCeNB8r8brS8XBWXM47lZGoBrun 3+gAnRXob/+YLqdmaveON1S5WtJqEvhM =VxsC -----END PGP SIGNATURE----- _______________________________________________ saag mailing list saag at ietf.org https://www.ietf.org/mailman/listinfo/saag
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.