Hi Jari, 1) As to VRRP and SEND, is this text agreeable to you? In the context of IPv6 operation, if SEcure Neighbor Discovery (SEND) is deployed, VRRP is s compatible with the "trust anchor" and "trust anchor or cga" modes of SEND [RFC3971]. The (SEND) configuration needs to give the master and backup routers the same prefix delegation in the certificates so that master and backup routers advertize the same set of subnet prefixes. However, the master and backup routers should have their own key pairs to avoid private key sharing. 2) As to "Requirement to send router advertisements is in 6.4.2 but not in 6.4.3, why?" (I realized it's not so easy to discuss this and be sure we are discussing the same things, so please see attached where I added line #s to identify (it's just 6.4.1 thri 6.4.3). I'm not sure I love this approach, but it it at least clrifying...) I think you are talking about in section 6.4.2 (395) (?) which occurs on backup -> master transition. But in 6.4.3 (630) says to send RA. I don't yet understand your comment, can you clarify? 3) as to "In Section 6.4.3, the Accept_Mode flag is only checked in the IPv6 branch of the code, is this correct?" This looks like a good catch. Looks like I should add an analogue of (635) after (610). 4) as to "In Section 6.4.3, I don't understand how there's first a MUST statement on responding to Neighbor Solicitations, and then two steps later a conditional statement based on the value of Accept_Mode, again on the the same thing, responding to NSes." I think this is in connection with (625) and (635). (635) was to cover this case: http://www.ietf.org/mail-archive/web/vrrp/current/msg00806.html Thanks, Steve -----Original Message----- From: Jari Arkko [mailto:jari.arkko at piuha.net] Sent: Friday, July 10, 2009 6:07 AM To: iesg at ietf.org Cc: vrrp-chairs at tools.ietf.org; draft-ietf-vrrp-unified-spec at tools.ietf.org Subject: DISCUSS and COMMENT: draft-ietf-vrrp-unified-spec Discuss: This is a well written specification, and I'm prepared to ballot Yes on it. However, there were three issues (1 left) that deserve some discussion and probably small modifications are needed before this can happen. Two of the issues relate to apparently missing information, and one may be either a simple mistake or I misunderstood something. >In the context of IPv6 operation, if SEcure Neighbor Discovery (SEND) >[RFC3791] is deployed, VRRP authentication could be usefully added, >because misconfiguration of secrets will not be an issue. Routers with >different secrets will have different IPv6 addresses, and therefore >there will be no issue with multiple masters with the same >IPv6 (and MAC) addresses. Also, SEND will prevent malicious routers >from sending misleading ND messages. Hmm. As an author of RFC 3971 it is not quite clear to me what you mean above. First of all, no "secrets" are involved in RFC 3971, only key pairs for CGA addresses. Secondly, it is not required for routers to employ the CGA part of SEND; in most cases I would expect the configuration of certificates for prefix::1 or something like that. Thirdly, I do not understand why there is no issue, because the backup taking over, because then the backup has to authoratively sign the NAs and RAs it is sending, for the primary's address. If the "trust anchor and cga" mode from RFC 3971 is used, the private key would have to be shared, or this would not work at all. And private key sharing is not necessarily a good idea. I would recommend saying this: - VRRP is compatible with "trust anchor" and "trust anchor or cga" modes of SEND - The configuration needs to give the two routers the same prefix delegation in the certificates - But still, the routers should have their own key pairs (Further modes are possible when the CSI WG gets some work done.) Comment: I think the new version is a significant improvement, and I have decided to clear the ND and virtual MAC related parts of my Discuss. However, I still think there's something wrong with some of the text, e.g., Requirement to send router advertisements is in 6.4.2 but not in 6.4.3, why? In Section 6.4.3, the Accept_Mode flag is only checked in the IPv6 branch of the code, is this correct? In Section 6.4.3, I don't understand how there's first a MUST statement on responding to Neighbor Solicitations, and then two steps later a conditional statement based on the value of Accept_Mode, again on the the same thing, responding to NSes.
Attachment:
preV0418-24.pdf
Description: preV0418-24.pdf