Re: [VRRP] DISCUSS and COMMENT: draft-ietf-vrrp-unified-spec

["Stephen Nadas" <[e-mail]>]

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:[e-mail]] 
Sent: Friday, July 10, 2009 6:07 AM
To: [e-mail]
Cc: [e-mail]; 
[e-mail]
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.