[savi] Status of draft-ietf-savi-fcfs

[Jari Arkko <[e-mail]>]

This draft was in IESG review last week. There are quite many Discusses, 
but I think they are relatively easily dealt with. Please respond to the 
Discuss holders and take care of everything that was reported. There 
were many details and I have not had time to analyze every single issue, 
but the key points that I got from my IESG colleagues are as follows:

* You should fix the reference issue that Dan brought up.

* You should narrow down the specification to cover the switched ports 
case, as that is the only that you have really specified in full. Future 
specifications may explain how to use this technology in some other 
context. (Russ' and David's Discusses)

* You should make the changes suggested by Stephen to avoid privacy 
impacts of unnecessary logging information from this technology

* You should address the specific issues brought up by Wes and Ralph

* I will ask Sean to remove his Discuss, as the primary issues have been 
removed and his just agreeing with

Jari

> Summary: /Has 7 DISCUSSes. Has enough positions to pass once DISCUSSes 
> are resolved./
>
>
>     Adrian Farrel
>
> *Comment (2011-05-25)*
>
> There are plenty of Discuss points already raised with which I agree.
>
> ---
>
> Section 1
> "The proposed mechanism..."
> It is no longer a proposal.
>
> ---
>
> The figure on page 9 has a misalignment.
>
> ---
>
> The writeup says:
>    There are existing implementations of a very similar feature for
>    IPv4.
> This is fair enough, but I am surprised to see no reference to this in
> the document and no description of the differences.
>
>
>     Dan Romascanu
>
> *Discuss (2011-05-26)*
>
> Section 3.2.5 speaks 'the case the SAVI device is a switch that supports
> VLANs'but provides no reference to what IEEE 802,1 specification it refers and
> what types of VLAN capable bridges (switches) are covered. Is the intent to
> cover all types of VLANs defined by IEEE 802.1? Clarification and proper
> references are required.
>
>
>     Pete Resnick
>
> *Comment (2011-05-24)*
>
> Section 2 title - I would prefer to strike "non-normative". I see
> no reason for it and the use of this expression is turning into an
> IETF fetish. Instead, you can add on to the the Introduction:
> "Section 2 gives the background and description of FCFS SAVI,
> and Section 3 specifies the FCFS SAVI protocol."
>
> Section 2.6:
>
>    Before creating a SAVI
>    binding in the local SAVI database, the SAVI device will send a NSOL
>    message querying for the address involved.  Should any host reply to
>    that message with a NADV message, the SAVI device that sent the NSOL
>    will infer that a binding for that address exists in another SAVI
>    device and will not create a local binding for it.  If no NADV
>    message is received as a reply to the NSOL, then the local SAVI
>    device will infer that no binding for that address exists in other
>    SAVI device and will create the local SAVI binding for that address.
>    (NOTE that the description included here is overly simplified to
>    illustrate the mechanism used to preserve the coherency of the
>    binding databases of the different SAVI devices.  The actual SAVI
>    mechanism normative specification as described in Section 3 varies in
>    the fact that in some cases it is the SAVI device that generates the
>    NSOL while in other cases it simply forwards the NSOL generated by
>    the end host, and that the SAVI device will send multiple copies of
>    the NSOL in order to improve the reliability of the message exchange,
>    among other things).
>
> Start with the words, "As a simplified example of how this might work:",
> and then strike the parenthetical NOTE entirely.
>
> Section 3 title - strike "normative"
>
>
>     Peter Saint-Andre
>
> *Comment (2011-05-23)*
>
> Please expand "DoS" on first use and add an informational reference to RFC 4732.
>
>
>     Sean Turner
>
> *Discuss (2011-05-26)*
>
> Edited to remove #2.
>
> #1) Many of the discusses that have been logged I agree with.
>
> #2) addressed: I've been convinced that standards track is okay.
>
>
>     Stewart Bryant
>
> *Comment (2011-05-25)*
>
> I support the discusses raised against this document.
>
>
>     David Harrington
>
> *Discuss (2011-05-27)*
>
> There are many points in my DISCUSS, but most are requests to tighten the
> RFC2119 language, or explain in the text what the valid exceptions are to each
> SHOULD.
>
> 2) in 2.4, "For the rest of the document, we will assume that the binding
> anchors are ports of a switched network." Having this statement at the end of a
> paragraph in non-normative background text seems insufficient. To be compliant
> to this standard, the binding anchors MUST be ports of a switched network. I
> think this should be clearly specified in RFC2119 langauge in the normative
> section.
>
> 3) in 2.5, "a secondary goal is to assist in traceability for determining who an
> improper actor is." I don't see this in the charter, and question whether this
> is an IETF-supported secondary goal. (I see that Stephen has raised a DISCUSS on
> this in more detail).
>
> 4) in 3.2.2, "transit traffic and the packet SHOULD be discarded" why only
> SHOULD? what are the valid exceptions to this?
> 5) in 3.2.3, "the SAVI device
> SHOULD execute the process of sending Neighbour Solicitation messages"
> s/SHOULD/MUST/
> 6) "are NOT forwarded" s/are NOT/MUST NOT be/
> s/they are
> sent/they MUST be sent/
> s/are discarded/MUST be discarded/
> s/is discarded/MUST
> be discarded/
> s/packet is either stored or discarded/ - why the choice? Please
> use RFC2119 language.
> ... the rest o fthe state table shoul dbe in RFC2119
> terms.
> s/relay/rely/
> s/must join/MUST join/
> s/SHOULD join/MUST join/
> 7) 3.2.4
> "SHOULD be connected" - when is ti valid to not be connected? should thi sbe a
> MUST to ensure that transit traffic is not dropped?
> multiple SHOULDs here; why
> not MUSTs? If SHOULD, what are the valid exceptions?
> 8) 3.2.5 "will behave as if
> " - MUST behave as if
> 9) section 4, why 4 bindings? where did 4 come from?
> Doesn't this exhuast memory four times faster than an implementation that
> reserves memory for 1 binding per port? Isn't the reserved memory wasted if the
> port consistently has only one binding?
> 10) "A SAVI device MUST limit the amount
> of memory" I think this should be a SHOULD. If an implemnter chooses to allocate
> unlimited memory, they should probably be allowed to. How will thi sbeing a
> SHOULD impact interoperability, as compared to its being a MUST?
> 11) "The other
> type of attack is when an attacker manages to create state in the SAVI device
> that will result in blocking the data packets sent by the legitimate owner of
> the address. In IPv6 these attacks are not an issue thanks to the 2^64 addresses
> available in each link." I don't see how the 2^64 addresses available mitigates
> the ability of an attacker to create state that would block a valid address.
> 12)
> "the SAVI device can be used as an amplifier by attackers. In order to limit
> this type of attack, it is RECOMMENDED that the SAVI device performs rate
> limiting " why not MUST?
>
> *Comment (2011-05-24)*
>
> 1)  in 2.3, "SAVI checks would not be fulfilled by the transit traffic" I think
> fulfilled might be the wrong word here; do you mean performed?
>
> 2) a stylistiuc point. The document often uses "This means". This is totally
> unnecessary. Just say what it means without the "this means phrase". This means
> don't use this means.
>
> 3) in 2.6, summary, "A SAVI device only verifies packets coming through one
> interface connected to the untrusted part of the topology." why only ***one
> interface*** per SAVI device?
>
> 4) in 2.6, "In particular, it is important to avoid that the same source address
> is bound to different binding anchors in different SAVI devices. Should that
> occur, then it would mean that two hosts are allowed to send packets with the
> same source address, which is what SAVI is trying to prevent." Is this accurate?
> Does it necessarily imply there are two hosts?
>
>
>     Ralph Droms
>
> *Discuss (2011-05-24)*
>
> 1. The definitions of "source address validation", "address ownership"
> and the concept that a " source address [...] belongs to the
> originator of the packet" need to be clarified this paragraph:
>
> 2.3.  Address ownership proof
>
>    The main function performed by FCFS SAVI is to verify that the source
>    address used in data packets actually belongs to the originator of
>    the packet.  Since FCFS SAVI scope is limited to the local link, the
>    originator of the packet is attached to the local link.  In order to
>    define a source address validation solution, we need to define some
>    address ownership proof concept i.e. what it means that a given host
>    owns a given address in the sense that the host is entitled to send
>    packets with that source address.
>
> FCFS SAVI does not require that a host provide any sort of proof of
> "ownership" of an address before that address is registered in an FCFS
> SAVI function.  A host merely needs to claim the address through
> traffic sent to the FCFS SAVI function.  In contrast, a SAVI function
> implemented by bindings learned through manual configuration or
> through interactions with a DHCPv6 address assignment function can
> make a statement that an IP address belongs to a host.
>
> What FCFS SAVI does is prevent simultaneous use of a single IP address
> as a source address through multiple ports.  There is no guarantee
> that the FCFS binding in any way reflects intended ownership of the
> bound address.
>
> 2. There needs to be text in section 2.1 explaining why FCFS SAVI is
> applicable or inapplicable to addresses assigned through DHCPv6.
>
> 3. What about links for which there are no prefixes that are
> advertised as on-link?  Similarly, what about addresses that are
> assigned through DHCPv6 but are not taken from an on-link prefix?
>
> 4. In section 3.2.2:
>
>       *  If the IP source address does not belong to one of the local
>          prefixes of the receiving interface, this means that the data
>          packet is transit traffic and the packet SHOULD be discarded.
>
> s/SHOULD/MUST/
>
> How are the FCFS SAVI assumptions maintained and how is
> spoofed traffic discarded if the FCFS SAVI function decides to forward
> transit traffic?
>
> 5. Section 3.2.4 must be worded more strongly to guarantee FCFS SAVI
> protection.  Some of the items in the list are "MUST" or FCFS SAVI
> protection will not be provided:
>
>    o  Ports connected to hosts SHOULD be configured as Validating ports.
>       Not doing so will allow the host connected to that port to send
>       packets with spoofed source address.
>    o  Ports connected to a chain of one or more legacy switches that
>       have hosts connected SHOULD be configured as Validating ports.
>       Not doing so will allow the host connected to any of these
>       switches to send packets with spoofed source address.
>
> This requirement is a MUST.  There are no alternatives to the given
> configurations that still provide FCFS SAVI protection.
>
> 6. I agree with Stephen Farrell's DISCUSS points 3 and 4, but feel
> less strongly about a fix.  Specifically, I agree that FCFS SAVI is
> inappropriate for a deployment in which an external router can pass
> transit traffic to an FCFS SAVI function.  But that just means SAVI
> FCFS is inappropriate.  There are other SAVI mechanisms that can work;
> for example, a DHCPv6-based mechanism in which the (non-FCFS) SAVI
> function is aware of the addresses and prefixes assigned through a
> binding anchor and, therefore, bound to that binding anchor.
>
> One way to address this issue some additional text describing how SAVI
> can be used to provide perimeter security, where that SAVI might be
> FCFS SAVI over part of the perimeter or some other kind of SAVI over
> the remainder of the perimeter.
>
> 7. This paragraph from section 4 needs some clarification:
>
>    The other type of attack is when an attacker manages to create state
>    in the SAVI device that will result in blocking the data packets sent
>    by the legitimate owner of the address.  In IPv6 these attacks are
>    not an issue thanks to the 2^64 addresses available in each link.
>
> Random address selection makes it difficult for an attacker to hijack
> an address and deny legitimate use of an address.  However, in
> deployments that use SLAAC, a host has a predictable global address
> (perhaps augmented by random privacy addresses) that can be hijacked.
>
> 8. In TESTING_VP state, section 3.2.3:
>
>    o  If a data packet is received through a Trusted Port port that is
>       other than port P, the state is moved to TESTING_TP-LT, and the
>       packet MAY is discarded.
>
> Certainly it can't be just any packet received through a Trusted Port
> that triggers this action.  And, if P is a validating port, won't
> traffic on any Trusted Port be "other than port P"?  This bullet needs
> to be corrected.
>
> 9. Throughout section 3.2.3, there are several occurrences of "If a
> DAD_NSOL" which need the qualification ""with target address set to
> IPAddr".
>
> 10. In section 3.2.3, does "==" mean "is set to"?  In the last bullet
> of TESTING_VP, does the FCFS SAVI function continue the TESTING_VP
> state and is the lifetime modified?
>   
>
> *Comment (2011-05-24)*
>
> 1. What is the relationship between the contributors in section 6 and
> the contents of the document and the list of authors?  A quick
> sentence about why the contributors are listed as such - rather than
> as authors or in the acknowledgments - would be helpful.
>
> 2 I think it should be made clear whether the term "SAVI" refers to
> "FCFS SAVI" or, more generally, to any form of SAVI throughout the
> document.  Section 2.6, for example, is unclear about the use of
> "SAVI".  It's important to be clear in section 2.6 because in my
> opinion a SAVI perimeter could be composed out of various kinds of
> SAVI functions.
>
> 3. What is the definition of a "realm"?  It's important to define
> realm because, by using ND to confirm the correctness of SAVI
> bindings, the FCFS SAVI function only checks on the link to which it
> is attached, not across the entire FCFS SAVI perimeter.
>
> 4. Also in section 3.2.3:
>
>    NO_BIND
>
>    o  Upon the reception through a Validating Port (VP) of a Neighbour
>       Solicitation (NSOL) generated by the Duplicate Address Detection
>       (DAD) procedure (hereafter named DAD_NSOL) containing Target
>       Address IPAddr, the SAVI device MUST forward the NSOL and 250
>
> In the last line, s/NSOL/DAD_NSOL/  How does the FCFS SAVI function
> differentiate between NSOLs generated by DAD and other NSOLs?
>
> 5. In TENTATIVE state, section 3.2.3:
>
>       the state remains in
>       TENTATIVE_DAD_NSOL,
>
> s/TENTATIVE_DAD_NSOL/TENTATIVE/
>
>
>   
>
>
>     Russ Housley
>
> *Discuss (2011-05-26)*
>
>   A quick read resulted in these concerns:
>
>   - The majority of the document is about switch port mappings
>     although it says early on that this is not the only way to do
>     things.
>
>   - The switch port mapping scheme implied by the unlabeled figure
>     on page 9 appears to allow a host connected to a switch outside
>     the perimeter to pretend to be any other host attached to the
>     switch without SAVI knowing differently as the packets come in
>     through the same 'protected' port.
>
>   - Does the scheme work with multi-subnet links?  If the subnets are
>     supported by different routers, then packets may go between routers.
>     This may work out, but nothing says one way or the other.  Please
>     add some discussion.
>
>   - Does the scheme work with multi-homed hosts?  Again, there is no
>     discussion.  Please add some discussion.
>
> *Comment (2011-05-26)*
>
>   I support the DISCUSS positions offered by Ralph and Dan.
>
>
>     Stephen Farrell
>
> *Discuss (2011-05-23)*
>
> While this is quite long and maybe has some controversial things, it
> doesn't impact that much on details of the actual scheme so I hope
> it's less bad than it appears.
>
> (1) A general point about SAVI that also applies to SAVI FCFS: Since
> SAVI is only about spoofed source addresses and is not about
> monitoring hosts that never spoof anything, and since privacy is a
> concern for the (I assume) huge majority of non-spoofing hosts I
> would like to see this (and all SAVI standards track documents) say
> something like: 
>
> "Compliant implementations MUST NOT log binding anchor information
> except where there is an identified reason (see section X for the
> list of reasons applying for FCFS-SAVI) why that information is
> likely to be involved in detection or prevention of actual source
> address spoofing.  Information that is not logged MUST be deleted as
> soon as possible (see section Y for the conditions that make it safe
> to delete information). Information about the majority of hosts that 
> never spoof SHOULD NOT be logged."
>
> The conditions for when logging is allowed and when each piece of
> state can be deleted need to be specifically called out.  Those would
> be the putative sections X & Y in the above suggested paragraph above.
>
> I realise this may seem like a significant change (though not to the
> parts of the protocol that actually detect spoofing) but I think it is
> an important one.
>
> (2) Abstract - SAVI is not about the general "control of source
> addresses used" - it is chartered to help detect/prevent source
> address spoofing and that is all. 
>
> (3) My phone can be a WiFi access point. How would that continue to
> work if SAVI-FCFS were deployed? I think the document needs to say how
> one can differentiate transit traffic from spoofed source addresses in
> that case or that SAVI FCFS MUST NOT be used in networks that should
> allow my phone to do its thing.  2.1 says that this technique only
> applies to local traffic so implementers will need to know how to do
> this. 
>
> (4) I think SAVI FCFS needs a way to allow transit traffic and
> disallow spoofed source addresses but that is not trivial to fool by
> just pretending to be a router. If that is not possible, then this
> technique just seems broken. Its not clear to me whether the spec has
> this problem or not.   
>
> (5) 2.4 - saying you "assume" that the binding anchor is a port on a
> switched network implies that SAVI-FCFS MUST NOT be used in any other
> case. You need to say that. On a related point, you need to clearly
> say that this is just for IPv6 if that is the case, (depending on rfc
> 4861 seems to make that the case). All text that implies that the
> binding anchor for SAVI FCFS can be anything other than a port number
> should also be excised since SAVI FCFS is only defined for the port
> number being the binding anchor as far as I can see. This could
> probably best be done via an applicability statement section at the
> front. (Probably just a short paragraph is all that's needed.)
>
> (6) 2.5 I totally disagree that its a good idea for SAVI to log all
> this information. I'd like to see the section removed. (And as in (1)
> above, replaced with a MUST NOT for "normal" traffic and binding
> anchor information.)
>
> (7) (If 2.5 ends up staying...) Where in the SAVI charter does it say
> that "a secondary goal is to assist in traceability.."? Is there IETF
> consensus for this goal? I don't believe there is. RFC 2804 would
> imply the opposite.
>
> (8) If I end up in the rough on point (1) above, I would like to
> discuss whether not not SAVI goals could be met while only dealing
> with an anonymized form of binding anchor information. If so, then
> maybe you should have a MUST for doing that where the binding anchor
> information could be personally identifying.  While this is less
> relevant for SAVI-FCFS than perhaps other variants, (e.g. MAC address
> or NAI) even a port can be personally identifying in a some networks. 
>
> (9) The SAVI DB content says "such as the layer-2 address" but you've
> gone to lengths to say that's not trustworthy so its presumably not
> useful for detection of source address spoofing and should not be
> included here. See also point (1) above - MAC addresses of
> non-spoofing users should not be retained casually like this. I'd like
> to see a statement that personally identifying data MUST NOT be
> included in the SAVI DB with the MAC address as the canonical example.
> (If packets do indicate attempted spoofing then I've no problem about
> logging the MAC address.)
>
> (10) The prefix in the prefix list is v6 only - right? If so maybe
> worth saying so.
>
> (11) 3.2.1 talks about what the SAVI device does when it boots - is
> that the only time it is supposed to update the prefix list for
> transit traffic? That seems wrong.
>
> (12) 3.2.2 uses the phrase "local prefixes" which doesn't seem to be
> defined - does that cover prefixes for routers or not?`
>
> (13) 3.2.2 seems to say that transit traffic received on validating
> ports is just dropped - that can't be right so maybe the text needs to
> be rephrased to make it clear what happens. This may be related to
> (12) above, but I find 3.2.2 just too hard to follow.
>
> (14) MLD is used without expansion and with no reference.
>
> (15) End of state machine, p17 - what does "P'==P''" mean here?
>
> (16) Why are the security considerations talking about the binding
> anchor being a MAC address when you've ruled that out?  The spec needs
> to be clear about what binding anchor information can be used and not
> discuss other possible binding anchor information types.
>
> [The next 3 are from the secdir review by Juergen Schoenwaelder.]
>
> (17) [secdir#1] 
>
> My first question was triggered by text on page 8:
>  
>    [...] Before creating a SAVI binding in the local SAVI database,
> the SAVI device will send a NSOL message querying for the address
> involved.  Should any host reply to that message with a NADV message,
> the SAVI device that sent the NSOL will infer that a binding for that
> address exists in another SAVI device and will not create a local
> binding for it.
>
> Now, that sounded like it is easy to DoS new devices simply by
> generating fake NADV messages. Later in section 3, it seems you only
> accept NADV messages from trusted ports. If my reading is correct,
> then a better wording might be:
>
>    [...] Before creating a SAVI binding in the local SAVI database,
> the SAVI device will send a NSOL message querying for the address
> involved.  Should any host _on a trusted port_ reply to that message
> with a NADV message, the SAVI device that sent the NSOL will infer
> that a binding for that address exists in another SAVI device and will
> not create a local binding for it.
>
> But then I am not sure whether it is really practical to assume that
> NADV messages always come from a trusted port.
>
> (18) [secdir#2]
>
> My second question concerns the construction of the prefix list. One
> option is to learn prefixes by listening to Router Advertisements. Is
> there a way to make SAVI do bad things by announcing bogus prefixes?
>
> (19) [secdir#3]
>
> My third question concerns this statement in the security
> considerations:
>
>    The other type of attack is when an attacker manages to create
> state in the SAVI device that will result in blocking the data packets
> sent by the legitimate owner of the address.  In IPv6 these attacks
> are not an issue thanks to the 2^64 addresses available in each link.
>
> The second sentence makes this sound like a non-issue but it seems to
> be correct only if devices uniformly pick random addresses out of the
> full 2^64 address space. If for whatever reason I can guess with a
> decent likelihood an address, it looks like SAVI becomes a tool to
> help me with denying service for such an address.
>
> (20) The "Security Logging" section should be changed significantly to
> say that only suspected spoofing should be logged and that for privacy
> reasons SAVI MUST NOT otherwise log normal use of the network.
>   
>
> *Comment (2011-05-23)*
>
> (1) I don't understand the sentence at the end of 2.1 " Manually
> configured IPv6 addresses can be supported by FCFS SAVI, but manual
> configuration of the binding on the SAVI device provides higher
> security and seems compatible with manual address management."
>
> (2) 2.2 says that "non-compliant" packets can be dropped - there's no
> IESG write-up so I'm wondering if this is safe or if there's any
> evidence that this would be safe? Has this been implemented and if so
> have any results of its effects been published? (I know that's not a
> requirement for PS, but in this case, I think it would be very useful
> information.)
>
> (3) 2.3 "prove address ownership" is too strong and I think ownership
> is the wrong phrase in any case.
>
> (4) I don't understand "FCFS SAVI function relies on state information
> binding the source address used in data packets to the binding anchor
> that contained the first packet that used that source IP address."
> Seems like it needs re-phrasing - "contained the first packet" is the
> wrong bit.
>
> (5) The "it" in "CFS SAVI function relies on state information binding
> the source address used in data packets to the binding anchor that
> contained the first packet that used that source IP address" seems
> ambiguous. I'm fairly sure it refers to each SAVI instance rather than
> the set of instances in a SAVI perimeter but that should be made
> clear.
>
> (6) State machine ascii art - expanding T.O. to timeout (I guess)
> would be clearer.
>
> (7) "MLD considerations" - should you s/relay/rely/?
>
> (8) From section 4 on there are more English language errors that
> should be fixed, e.g "The attacks against the SAVI device basically
> consist on making the SAVI device to consume its resources until it
> runs out of them" has two (and maybe 3) errors.  There are also some
> similar problems in Appendix A. (I have some marked up on paper so
> easiest will be if I try to list any that remain if you rev. the I-D.)
>
> (9) [secdir review nits]
> Editorial nits:
>
> - p10: s/because the connect/because they connect/  (twice)
> - p10: s/through validating port/through validating ports/
> - p11: s/prefixes.A/prefixes. A/
> - p13: s/may due/may be due/
> - p13: s/packets has been/packets have been/
> - p18: s/relay/rely/
> - p24: s/coalition/collision/
> - p26: s/case fixed/case of fixed/
>
>
>     Wesley Eddy
>
> *Discuss (2011-05-24)*
>
> Some questions I think the authors should respond to:
>
> I believe the RetransTimer is configurable in RFC 4861, so why is 250 ms a magic
> number in Section 3.2.3 of this document?  Are there scenarios where this value
> needs to be configured differently or is this really one size fits all?  I
> didn't notice the motivation for this constant in the document, and it probably
> should be explained.  It seems to be fixed rather than just a default, but the
> wording in this document is actually a little ambiguous about this.
>
> The same comment applies to TENT_LT (500 ms) and DEFAULT_LT (5 minutes).  If
> these constants are special for some reason and not just defaults that can be
> tweaked to suit a deployment, it needs to be described why, otherwise the logic
> for setting them a certain way needs to be given.
>
> *Comment (2011-05-24)*
>
> Some comments that I don't think are very important and that the authors should
> feel free to either take or ignore:
>
> In section 2.1, second paragraph, it might make sense to be more clear that
> routers use their own MAC address, but the packets that they forward have an
> off-link source address that doesn't belong to them.  However, I don't think
> anyone will really be confused either way, so this is just a suggestion.
>
>
> The definition of the term "binding anchor" is somewhat implicit in this
> document.  It might be a good idea to make it more explicit with just a sentence
> or so more where it's first used in 2.3, and only one very brief example is
> given.
>
>
> In section 2.3, second paragraph, should "(e.g. the port in a switched LAN)" be
> "(e.g. the MAC address and/or port in a switched LAN)"?