Subject: [VRRP] Meeting Minutes for IETF56 WG Session.

From: [email-masked]
Date: Thu, 20 Mar 2003 23:18:31 -0600

Folks,

Here are the meeting minutes (thanks Jeff !!) and the presentation =
slides from the IETF 56 VRRP WG session. Please review them and let me =
know if something needs to be corrected. If I don't hear anything back, =
I will send them to [email-masked] on Monday.

- Mukesh

=========================================================
VRRP Working Group Minutes
IETF 56 San Francisco, CA, USA
March 20th 2003.

Chair: Mukesh Gupta

Meeting Notes taken by Jeffery Hass. Modified/Formatted by Mukesh Gupta.

Mukesh presented the Agenda and Milestones/Plans. (See the slides)

Security Issues:
-------------------
Mukesh presented the summary of security problem and the proposed solution.

everyone was in favor of removing security. No one was in favor of keeping it.

Then the question was how to remove it so that we don't have backward compatibility issues. 

Bob: We should deprecate the authType values other than 0.

Bill Fenner:
We should do what the implementations do when there is no security present?
Reccomend turning off security on the other implementations.

Radia:
We arent' really removing stuff from the headers and just making them reserved?

Mukesh:
If the authentication is non-zero, drop the packet?

Radia:
Its no different than if somone misconfigured it its no different than wrong password. So just notify the administrator for this.

Mukesh:
There is a MIB object for this. We could use it.

Radia: 
This should be brought to the attention of the operators.

Mukesh: Do we need to recycle it through PS again?

Bob: As we are removing security that was stopping it to go to DS, we should just go to DS after removing security.

Mukesh:
The MIB (2787) will need to be updated for this. Should we remove the security related object from the MIB ?

Bill Fenner:
They should to be deprecated.

Mukesh:
The mib will be updated.

vrrpv3:
----------
Mukesh: The security things can be removed completely from here.

Bob: Kame/tahe folks have an implementation?

Mukesh: Yeah but it is just one implementation and we should remove these things before we start seeing more implementations.

Who has read the draft?
Bob and Radia.

Anyone planning on implementing this?  No.  In the future?  No.

Before we can move to proposed standard, we need at least one.

Radia:
Why would people have implemented this for v4 than v6?

Tony:
v6 stuff just lags.

mukesh: should we just wait?

Bob:
This isn't a routing protocol?

Bill F:
Its in the routing area.

Its not clear if the rfc 1264 applies.

"I don't like having rules that I am applying ad-lib".  If this applies on routing protocols, then we can use the rfc 2026 rules.

Tony:
In the past when we chartered the working group - its a one-hop routing protocol.

Radia:
A case can be made that something a router does is a routing protocol.  
*laughs*

Mukesh:
The draft will expire in June.

Bob:
Security changes should be made no matter what. So that will give us 6 more months. He will talk to the KAME folks about implementations.

vrrpv3 mib:
--------------
Its needed at least in drafts.
Some people have started working on it.
Will write a new draft instead of updating the existing one. (RFC 3291 has the reason)
Draft will be submitted to the WG soon.
Please review it!

IPR Issues (Cisco)
---------------------
We found the following statement from Robert barr
http://www.in-addr.de/pipermail/lvs-users/2001-November/004135.html
(excerpt)
essentially, Cisco will use it as a defensive patent only.

IPR Issues, IBM:

Brian Carpenter:
"don't shoot the messenger"
"I haven't read any of the documents"
"I do it for IBM.
I cannot clarify the disclosure about patent (mumble).
Attempting to get clarification about this.
I have become aware of another US Patent 6148410 that may affect VRRP.
IBM will provide a disclosure of their position on the patent."
He has expectations that IBM would provide non-discriminatory licensing.

So, we now have 3 patents to worry about.

Are we interested in:
------------------------
-- IPsec AH security for VRRP draft?  

Radia:
We will have the same problem in the other security section.  Misconfiguratinos will yield two masters.
If we are merely preventing bad guys from doing vrrp, you aren't preventing them from doing maximal harm.
What kind of threat are we dealing with that this would solve?

Mukesh:
Some people on mailing list were interested in some form of security.

Bill F:
In any work that happens, we would like to see something that covers more of the underlying issues.  Some of these aren't within our domain - mac address of VR, for example.  Learning bridges will think the router is "over towards you".  Its not in our space.  Its a much worse problem than two masters.

Mukesh:
Most people think we shouldn't work on this.  He will confirm on mailing list.

-- Removing priority value 0 - hold election now option?

j: why are we removing this?

r:
it harms
only speeds thins up for case where you know you're going down.

Jeff:
This helps for graceful restart situations.

Bill:
Graceful restart is often wants to keep forwarding?  We wont want to do this.

Why is 1 not dangerous?  Any priority lower than the master is similarly dangerous.

Bob:
There are nastier ways to be evil. This wont help security by removing it.

Mukesh:
Who thinks we should keep?  Most people.  No one voted for removing it.

-- Issus and arguments document ?
Radia says we should write this.  Basically lets us encode history.
Who thinks this would should be useful?

Bill: Do we remember enough of the history?

Radia: Its useful even if we don't get all of the issues.

Support is a few, but not enthusiastically.

No opposition to it.

Radia: I will liely be writing this with some help.  If anyone can provide her with help on issues, that'd be good.
Mukesh: Bob would be good for that.

- Anything else?
Mark H from HP
I never liked using the duplicate MAC address.  Why aren't we using unsolicited arps.  Because it wont update their cache in some implementations.  Is this really important in ipv6?  Surely there is a better answer.  Do we have to make the same mistake for v6.

Tony:
First we did router discovery, not!  Then we did this hack for hsrp.  With v6, we have a clean slate.  We could simply insist people implement router discover.  Its the way it should have been.

Radia:
Bridges really don't like duplicate macs, it makes her uneasy.  If unsolicited arps got lost, then you'll end up with lost or blackholes.

Bob:
v6 drafts - the goal was to do the switchover quickly.  He agress with tony that the v6 nodes will hear router advertisements.  With the timers for neighbor advertisements and router discovery, it may not be fast enough for tcp connections to stay up.  it might be worth looking at again.  All v6 nodes will listen to these types of packets, maybe that is a better mechanism.

When I was writing this draft, he asked "do we need this at all?" and wasn't able to convince himself.

THE END
=========================================================
_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp