Subject: [VRRP] What packets to drop when accept mode is false? (was RE: DISCUSS and COMMENT: draft-ietf-vrrp-unified-spec )

From: "Stephen Nadas" <[email-masked]>
Date: Thu, 6 Nov 2008 07:40:53 -0600

Hi Jari, 

Thank you for the comments; I'm breaking and snipping into several
threads for VRRP list for their feedback.

Regards, 
Steve 

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Thursday, November 06, 2008 08:33
> To: [email-masked]
> Cc: Christian Vogt; [email-masked]; 
> [email-masked]
> 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 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.
> 
> I would like to talk about these on the call or with the authors.
> 
> > Accept_Mode  Controls whether a virtual router in Master
> >              state will accept packets addressed to the
> >              address owner's IPvX address as its own if it
> >              is not the IPvX address owner.  Default is
> >              False.
> >
> >              Note: IPv6 Neighbor Solicitations and
> >              Neighbor Advertisements should not be dropped
> >              when Accept_Mode is False.
> >
> >...
> >
> >Compute and join the Solicited-Node multicast address 
> [RFC4291] for the 
> >IPv6 address(es) addresses associated with the Virtual Router.
> 
> Are these the only messages that should not be dropped?! What
> about:
> 
> - RA/RS
> - MLD
> - CPS/CPA (RFC 3971)
> - IGMP
> 
> Is the idea that you actually do stop responding to RA/RS, 
> and that by this hosts should migrate to to use the remaining 
> router natively, rather than the remaining router as a backup 
> for the dead one? If yes, say so.
> 
> MLD is generally sent to multicast addresses, but RFC 3810 Section
> 5.1.15 also talks about a MUST requirement for a router to 
> accept unicasted MLD. How is this accommodated in VRRP?
> 
> What about the SEND certificate retrieval messages CPS/CPA? 
> Lets say the primary router died just when a host had found 
> it, but had not had time to ask for CPS/CPA. What will happen?
> 
[snipped]
_______________________________________________
vrrp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vrrp

---

From: "Stephen Nadas" <[email-masked]>
Date: Thu, 6 Nov 2008 07:43:07 -0600

For VRRP list comments.... 
Steve  

[Snipped]
> >7.4. IPv6 Interface Identifiers
> >
> >IPv6 Routers running VRRP MUST create their Interface Identifiers in 
> >the normal manner (e.g., RFC2464 "Transmission of IPv6 Packets over 
> >Ethernet").  They MUST NOT use the Virtual Router MAC 
> address to create 
> >the Modified EUI-64 identifiers.
> >
> >... 
> >
> >If there are several VRRP routers, it is cumbersome for the 
> operator to 
> >configure the same VRRP protected link-local address on all of them.
> >An implementation might choose simplify this for the 
> operator by using 
> >the VRRP MAC in the formation of these link local addresses.
> 
> Isn't the former MUST NOT instruction contradictory with the 
> guidance in the latter paragraph? Or am I missing something obvious?
[snipped]

---

From: "Stephen Nadas" <[email-masked]>
Date: Thu, 6 Nov 2008 07:45:03 -0600

For VRRP list comments
Steve 

[snipped]
> >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.)

Note, Christian's comments went under separate email thread. 

> 
> Comment:
> Christian Vogt's review:
> 
> - The document uses the acronym "IPvX" in order to refer to 
> both/either
>   IP version.  Since IPvX might be confused with the more prevalent
>   acronym IPX for Novell's Internetwork Packet Exchange protocol, I
>   would replace the occurrences of IPvX with either "IPv4 or IPv6", or
>   simply with "IP".
> 
> - In the figures illustrating sample configurations in 
> section 4, it is
>   not clear which IP address labels denote a host's own IP address vs.
>   which denote the IP address of the router that a host is using.
>   Both is currently denoted "IPvX A" in the figure.  Suggest
>   distinguishing the two types of labels more clearly.
> 
>