Jean-Michele,
Thanks for the thoughtful review. I will post a new version addressing your
comments today or tomorrow.
Responses inline......
Ron
> Subject: [Int-area] Intdir early review of draft-ietf-intarea-probe-00
> Message-ID: <150912536515.22228.10940363588216201...@ietfa.amsl.com>
> Content-Type: text/plain; charset="utf-8"
>
> Reviewer: Jean-Michel Combes
> Review result: Almost Ready
>
> Hi,
>
> I am an assigned INT directorate reviewer for draft-ietf-intarea-probe-06.
> These comments were written primarily for the benefit of the Internet Area
> Directors. Document editors and shepherd(s) should treat these comments
> just like they would treat comments from any other IETF contributors and
> resolve them along with any other Last Call comments that have been
> received. For more details on the INT Directorate, see
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.ietf.org_iesg_directorate.html&d=DwICAg&c=HAkYuh63rsuhr6Sc
> bfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=VGSSVlquIpFROEmOdJ5fpnG3ivRSQQaY23hP8P0
> dBQs&s=mO2Ham-yMdBeeKDYThOOP6vfCePpUoAVnBorws9AIuU&e=.
>
> PROBE: A Utility For Probing Interfaces
> draft-ietf-intarea-probe-06
>
> <snip>
>
> 1. Introduction
>
> <snip>
>
> If the probed interface resides on a node that is directly connected to the
> probed node, PROBE reports that the interface is up if it appears in the IPv4
> Address Resolution Protocol (ARP) table or the IPv6 Neighbor Cache.
> Otherwise, it reports that the interface does not exist.
>
> <JMC>
> Comment:
> Normative references to "IPv4 Address Resolution Protocol (ARP) table" (i.e.,
> RFC 826) and "IPv6 Neighbor Cache" (i.e., RFC 4861) are missing. </JMC>
>
> <snip>
>
[RB ]
Good catch. Fixed in next version.
> 2. ICMP Extended Echo Request
>
> <snip>
>
> o L (local) - The L-bit is set of the probed interface resides on the probed
> node. The L-bit is clear if the probed interface is directly connected to the
> probed node.
>
> <JMC>
> Typo:
> s/"The L-bit is set of the probed interface resides on the probed node."/"The
> L-bit is set if the probed interface resides on the probed node." </JMC>
>
> <snip>
[RB ]
Another good catch. Fixed in the next version.
>
> 3. ICMP Extended Echo Reply
>
> <snip>
>
> o F (IPv4) - The F-bit is set if the A-bit is also set and IPv4 is running
> on the
> probed interface. Otherwise, the F-bit is clear.
>
> o S (IPv6) - The S-bit is set if the A-bit is also set and IPv6 is running
> on the
> probed interface. Otherwise, the S-bit is clear.
>
> o E (Ethernet) - The E-bit is set if the A-bit is also set and IPv4 is
> running on
> the probed interface. Otherwise, the E-bit is clear.
>
> <JMC>
> Question:
> Why IPv4 must also run to have the E-bit set?
> Question:
> Why the E-bit is not set if IPv4 is not running and IPv6 is running?
> </JMC>
[RB ]
This was a typo. I meant to say:
0 E (Ethernet) - The E-bit is set if the A-bit is also set and Ethernet is
running on the probed interface. Otherwise, the E-bit is clear.
>
> 4. ICMP Message Processing
>
> <snip>
>
> o Set the Code field as described Section 4.1
>
> o If the Code Field is equal to No Error (0) and the L-bit is clear,
> set the A-Bit.
>
> o If the Code Field is equal to No Error (0) and the L-bit is set
> and the probed interface is active, set the A-bit.
>
> <JMC>
> Question:
> Why the A-bit is not set when Code Field is equal to Multiple Interfaces
> Satisfy Query (3) and the L-bit is clear? Question: Same question when L-bit
> is
> set. </JMC>
>
> <snip>
>
[RB ]
Error code 3 (Multiple Interfaces Satisfy Query) means that they query is
ambiguous. Or, on other words, that two or more interfaces satisfy the match
conditions specified by the query. So, we can't set the A, F, S or E bits
because we don't know which interface the user is asking about.
> 8. Security Considerations
>
> <snip>
>
> In order to protect local resources, implementations SHOULD rate-limit
> incoming ICMP Extended Echo Request messages.
>
> <JMC>
> Comment:
> IMHO, the main security threat I see with this mechanism is to use it as
> "reflection" scanning: to discover nodes "behind" the proxy interface,
> without raising alarms from security probes watching the networks hosting
> these nodes.
> So, rate-limit can help to mitigate this potential threat too. </JMC>
[RB ]
Yes, this does slow down the scanning attack. But it doesn't really mitigate
it. The savvy attacker will scan slowly.
Thanks again for the thorough review.
Ron
>
> 9. References
>
> 9.1. Normative References
>
> <snip>
>
> <JMC>
> Comment:
> Too add normative references to "IPv4 Address Resolution Protocol (ARP)
> table"
> (i.e., RFC 826) and "IPv6 Neighbor Cache" (i.e., RFC 4861), as commented
> previously. </JMC>
>
> <snip>
>
> Thanks in advance for your replies.
>
> Best regards,
>
> JMC.
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_int-
> 2Darea&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=VGSSVlquIpFROEmOdJ5fpnG3ivRSQQaY23hP8P0
> dBQs&s=Y0X9xlzWjiF5Nk7ImagKKmupi29NSBXKlHFhrzO7dYc&e=
>
>
> ------------------------------
>
> End of Int-area Digest, Vol 146, Issue 28
> *****************************************
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
