Hi, Donald, On 1/4/2017 5:43 PM, Donald Eastlake wrote: > Hi Joe, > > Thanks for the comments. > > On Tue, Jan 3, 2017 at 1:56 PM, Joe Touch <touch@xxxxxxx> wrote: >> - the use of two different ports invites some potentially unintended >> problems, e.g., selective blocking of the control vs. data plane. IMO, >> given that TRILL's purpose is to extend Ethernet (not IP), this service >> would be better served using a single port and differentiated >> encapsulated traffic by whatever method TRILL nodes use internally. >> Otherwise, this spec needs to include specific description of unexpected >> behavior, e.g., data frames on the IS-IS port and IS-IS frames on the >> data port. > I guess I don't see this. It's a configuration issue - what happens when (not if) a sysadmin opens up one port but not the other? IMO, unless there's a reason for that sort of selective filtering or there's a specific need to encapsulate the traffic differently, these ought to be treated as a single service - TRILL UDP encapsulation. It's only inside the TRILL system that the difference between data and IS-IS is useful and this encapsulation will have no effect on those nodes. > As for selective blocking, if someone can control the passing of > traffic through links connecting TRILL switches, they can always block > a subset of traffic based on whatever criteria they want. I don't > think it makes significant difference what header field they look at. I'm thinking of the increased complexity and potential for failure by not "fate sharing" data and IS-IS traffic. > Similarly, if someone can modify traffic passing through links between > TRILL switches, if the traffic is IP they could swap around port > numbers, but they could also swap around other header fields. > Presumably it is a policy decision for network managers based on their > threat model whether or not to use facilities by TRILL or otherwise to > provided to secure control traffic and/or use link security to protect > all traffic over a link. (Similarly, it is a matter for end system > users/managers to decide whether to use end-to-end security.) I'm asking whether you actually expect or want IP transit nodes to treat data and IS-IS traffic differently - via different routes, different drop policies, etc. If not, then there's no benefit from having two service ports. > I suppose we could throw in a few sentences saying that if security is > not being used and data or control is mislabeled as the other and it > happens to be parseable as the other, you will get junk in the data > stream or screwed up control information. TRILL data and IS-IS is already treated differently inside a TRILL campus, e.g., by their existing headers. I can't see data being treated as IS-IS or vice versa inside the campus, regardless of which port the traffic arrives on. That's largely my point - if the encap/decap node wouldn't need to treat these differently in either direction (leaving or entering the TRILL campus), then they're one service. > But I don't think the > mislabeling of control and data as the other by TRILL code is a > realistic problem. It would be detected by the crudest of testing. It *can* be detected, but your protocol needs to specify the correct behavior. Is the UDP tunnel ingress/egress supposed to prevent such mislabeling on ingress? If so, why would it care? If not, then again there's no point to two services. Joe