Mukesh.Gupta | 6 Mar 01:20 2003
Picon

Agenda for IETF 56, San Francisco

Folks,

Here is the rough agenda for the WG meeting in SFO. Let me know if you have any comments.

=================
Virtual Router Redundancy Protocol WG (vrrp)

CHAIR: Mukesh Gupta <Mukesh.Gupta <at> nokia.com>

AGENDA:
Agenda Bashing	5 mins
Milestones/Plans	5 mins
Security Issues 	15 mins
VRRPv3		5 mins
VRRPv3 MIB		10 minutes
IPR Issues		5 mins
=================

regards
Mukesh
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

PC Drew | 6 Mar 15:00 2003

Shared Password Authentication

I know I probably shouldn't bring this up again, but I'm still kind of 
confused as to why everyone is so against using the password 
authentication in VRRP.  Many other protocols implement this same kind 
of authentication with success (i.e. OSPF).  I feel that this kind of 
authentication is a good, cheap way to prevent forged packets from 
screwing up my network.  Of course, I have the potential of screwing 
myself up by entering the wrong password in the configuration...but the 
same thing could happen when I'm running OSPF in authentication mode.

To simplify my question: what is the benefit of *removing* this 
functionality vs. keeping it in?

--

-- 
PC Drew
Manager, Client Services

IBSN
12600 W. Cedar Drive, Suite 100
Lakewood, CO 80228

Email: drewpc <at> ibsncentral.com
Phone: 303-984-4727
Cell: 720-841-4543
Fax: 303-984-4730

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

(Continue reading)

Don Provan | 7 Mar 18:26 2003
Picon

RE: Shared Password Authentication

The argument, in a nutshell, is that any entity that can
inject proper VRRP packets into your network (including
the 255 IP TTL, for example) can deceive the rest of the
network directly without having any need to fool the VR
master into relinquishing control. Besides, such an entity
would almost certainly be in a position to monitor VRRP
traffic to read the password if it wanted. So the password
accomplished nothing to improve security.

So *all* the password did was ensure that misconfigured
hosts couldn't talk to each other. This might seem like
a good idea in itself, but actually it has exactly the
opposite of any desired effect: when they don't talk to
each other, the network is hosed because the conflicting
routers will fight uncontrollably for control of the
Virtual Router's addresses.

In short, worthless as a defense, yet dangerous
when innocently misconfigured. No upside.

There are several differences for OSPF. For one thing,
a forged packet fools the entire OSPF area, not just
the immediately connected network that an intruder
would be able to fool anyway. For another, by ignoring
a bad password in OSPF, you keep the offending node
outside "the club". In VRRP, it just divides the
environment into two clubs, neither having any
intrinsic authority from the point of view of the
systems being served.

(Continue reading)

Picon

RE: Shared Password Authentication


>
>>>
>>> I know I probably shouldn't bring this up again, but I'm
>>> still kind of
>>> confused as to why everyone is so against using the password
>>> authentication in VRRP. 

It's natural and healthy
for people to wonder about things like this.

I'm trying to encourage IETF WGs to view themselves
as educational instead of just being reference material
for those that basically understand the protocol.

So for really complex protocols, I think there should
be a companion document which is a tutorial.

But for protocols such as VRRP that aren't complex
enough to really require a tutorial document (that's
not a criticism...that's high praise!), I'd
still recommend a second document that documents
what the interesting issues were, and the arguments
on all sides. The email archives might contain this
information, but I don't think we should expect
people to have to read email archives.

So, what would people think of a companion "issues
and arguments" for VRRP? What interesting controversies
besides the security stuff were there?
(Continue reading)

Mukesh.Gupta | 7 Mar 19:19 2003
Picon

RE: Shared Password Authentication

Hi Radia,

That's an excellent idea. Would you like to work on this "issues and arguments" document ?

regards
Mukesh

-----Original Message-----
From: ext Radia Perlman - Boston Center for Networking
[mailto:Radia.Perlman <at> sun.com]
Sent: Friday, March 07, 2003 9:58 AM
To: 'PC Drew'
Cc: vrrp <at> ietf.org
Subject: RE: [VRRP] Shared Password Authentication

>
>>>
>>> I know I probably shouldn't bring this up again, but I'm
>>> still kind of
>>> confused as to why everyone is so against using the password
>>> authentication in VRRP. 

It's natural and healthy
for people to wonder about things like this.

I'm trying to encourage IETF WGs to view themselves
as educational instead of just being reference material
for those that basically understand the protocol.

So for really complex protocols, I think there should
(Continue reading)

Picon

RE: Shared Password Authentication

Sure. Though it would be helpful if people could
by send me other issues.
Anyone interested in helping?

Radia

<Mukesh.Gupta <at> nokia.com> wrote:
>Hi Radia,
>
>That's an excellent idea. Would you like to work on this "issues and arguments"
>document ?
>
>regards
>Mukesh
>

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

Craig Verge | 10 Mar 18:02 2003

Clarification on Handling of Invalid Advertisements (Section 7.1)

The section in the RFC reads:

7.1. Receiving VRRP Packets
   Performed the following functions when a VRRP packet is received:

      - MUST verify that the IP TTL is 255.
      - MUST verify the VRRP version
      - MUST verify that the received packet length is greater than or
        equal to the VRRP header
      - MUST verify the VRRP checksum
      - MUST perform authentication specified by Auth Type

   If any one of the above checks fails, the receiver MUST discard the
   packet, SHOULD log the event and MAY indicate via network management
   that an error occurred.

      - MUST verify that the VRID is valid on the receiving interface

   If the above check fails, the receiver MUST discard the packet.

      - MAY verify that the IP address(es) associated with the VRID are
        valid

   If the above check fails, the receiver SHOULD log the event and MAY
   indicate via network management that a misconfiguration was detected.
   If the packet was not generated by the address owner (Priority does
   not equal 255 (decimal)), the receiver MUST drop the packet,
   otherwise continue processing.

      - MUST verify that the Adver Interval in the packet is the same as
        the locally configured for this virtual router

   If the above check fails, the receiver MUST discard the packet,
   SHOULD log the event and MAY indicate via network management that a
   misconfiguration was detected.

If I read this correctly then for all advertisement error scenarios except the IP address list mismatch the receiver should discard the advertisement and not continue further processing...Correct?

This means that a received advertisement failing one of the checks (except the IP address check) is the same as an advertisement never received?  In which case one of the backup routers for this VRID will transition to master after the master_down_timer fires and there will be two masters.  Is this correct?  With two masters on the LAN we may cause the switch for this LAN to become confused.  We will have two routers responding to ARP requests and the switch with think the device with this vmac is constantly changing between two different ports.

Maybe we should differentiate the type of incorrect advertisement as misconfiguration versus protocol or hardware error.  If there is a misconfiguration in the Advertisement Interval we should NOT transition to master (i.e. reset master_down_timer) since we know the owner is out there but is not configured the same as the backup.  It will still be master and forward IP packets from the local devices.

If there is a protocol violation (incorrect TTL) or data corruption (checksum) then we don't reset the timer since maybe there is something wrong with this masters NIC causing checksum failure or a software problem resulting in the incorrect TTL.  A non-configuration problem of this type (i.e. possible hardware or software error) could impact the owners ability to forward IP packets from the local devices.

Cheers,
Craig Verge

Vikram Pendharkar | 10 Mar 19:39 2003

Re: Clarification on Handling of Invalid Advertisements (Section 7.1)

Hi Craig,

Craig Verge wrote:

> The section in the RFC reads:
>
> **
>
<snip>

> If I read this correctly then for all advertisement error scenarios 
> except the IP address list mismatch the receiver should discard the 
> advertisement and not continue further processing...Correct?
>
Yes.

> This means that a received advertisement failing one of the checks 
> (except the IP address check) is the same as an advertisement never 
> received?  In which case one of the backup routers for this VRID will 
> transition to master after the master_down_timer fires and there will 
> be two masters.  Is this correct? 
>
Yes.

> With two masters on the LAN we may cause the switch for this LAN to 
> become confused.  We will have two routers responding to ARP requests 
> and the switch with think the device with this vmac is constantly 
> changing between two different ports.
>
Yes. However, it is also dependent on how the router's arp is configured 
to act when it detects another response for a mac which it thinks it 
owns. Mostly, they might just raise an alarm or log the event.

> Maybe we should differentiate the type of incorrect advertisement as 
> misconfiguration versus protocol or hardware error.  If there is a 
> misconfiguration in the Advertisement Interval we should NOT 
> transition to master (i.e. reset master_down_timer) since we know the 
> owner is out there but is not configured the same as the backup.  It 
> will still be master and forward IP packets from the local devices.
>
What  you are suggesting is to not propogate an error. But what a backup 
sees as incorrect adver interval may actually be due to something else 
done incorrectly. So we cannot say for certain that 'master is just 
fine, backup neednt transition to master'. Having two masters IMO is a 
lesser sin than risking a chance that there is no forwarding at all. And 
plus, there's one more avenue to know something's wrong.

> If there is a protocol violation (incorrect TTL) or data corruption 
> (checksum) then we don't reset the timer since maybe there is 
> something wrong with this masters NIC causing checksum failure or a 
> software problem resulting in the incorrect TTL.  A non-configuration 
> problem of this type (i.e. possible hardware or software error) could 
> impact the owners ability to forward IP packets from the local devices.
>
just a nit, incorrect TTL could also be because the packet came from a 
different subnet, not necessarily incorrect software. Another indicator 
of how what you see may not indicate the correct source of problem.

> Cheers,
> Craig Verge
>
Regards,
Vikram

--

-- 
Vikram Pendharkar			
Ericsson IP Infrastructure

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

Vikram Pendharkar | 10 Mar 19:56 2003

Re: Clarification on Handling of Invalid Advertisements (Section 7.1)

Vikram Pendharkar wrote:

> just a nit, incorrect TTL could also be because the packet came from a 
> different subnet, not necessarily incorrect software. Another 
> indicator of how what you see may not indicate the correct source of 
> problem.

...well maybe not! ultimately its all a software problem :-)

--

-- 
Vikram Pendharkar			
Ericsson IP Infrastructure

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

Mukesh Gupta (IPD_NMS | 11 Mar 21:45 2003
Picon

[Fwd: Text Conferencing for the 56th IETF meeting in San Francisco]

FYI.

I am looking for a volunteer scribe. Please let me know if you would
like to be the one.

-------- Original Message --------
Subject: Text Conferencing for the 56th IETF meeting in San Francisco
Date: Tue, 11 Mar 2003 13:59:19 -0500
From: "ext Marshall Rose" <mrose+mtr.ietf <at> dbc.mtview.ca.us>
To: IETF-Announce: ;

 Remote Access for the 56th IETF meeting in San Francisco:
                             Text Conferencing

At each IETF meeting, two of the working group meeting rooms are
equipped
for video multicast and remote participation.  That is, for every IETF
meeting slot, two of the working groups can see and hear the
meeting. For the 56th IETF, in *addition* to the usual network A/V, text
conferencing will be provided for every working group that meets.

All of the conference rooms will be hosted on

    conference.ietf.jabber.com

and each is named using the official IETF abbreviation found in the
agenda (e.g., "apparea",  "dhc", "forces", and so on -- for all the
examples that follow, we'll use "foobar" as the abbreviation).

Each conference room also has a 'bot which records everything that gets
sent. So, the minute taker can review this information right after the
meeting.

1. Before the meeting:

1.1. If you want to participate

If you don't already have one, get yourself a Jabber client, here are
some
suggestions:

    platform    suggestion
    --------    ----------
    win32       http://exodus.jabberstudio.org
    'nix        http://gabber.sf.net
    macos       http://jabberfox.sf.net

When you start the client for the first time, it will eventually ask if
you want to register on a public server. Go ahead and do
that.

If you want to find out more, instead of choosing these defaults, here
are pointers to some additional information:

    list of clients:    http://www.jabber.org/user/clientlist.php
              howto:    http://www.jabber.org/user/userguide/
        server list:    http://www.jabber.org/user/publicservers.php

To make sure everything is running ok, do a "Join Group Chat" with your
Jabber client:

    Group/Room: plenary
    Server:     conference.ietf.jabber.com

This conference room is up and running right now (although probably no
one will be in it when you connect).

1.2. What the Chair does

If you want to make text conferencing available, you'll need to have a
volunteer scribe in the meeting room. The scribe will be typing in a
running commentary as to what's going on in the room (who's presenting,
what question is being asked, etc.)

So, why not send an email out on the mailing list now, before the
meeting, to ask for volunteers?

2. At the meeting

2.1. What the Chair does

When a session starts, the chair asks if someone in the room is willing
to act as "scribe". If no one volunteers, read no further, we're done!

Otherwise, the scribe should do a "Join Group Chat" with their Jabber
client, e.g.,

    Group/Room: foobar
    Server:     conference.ietf.jabber.com

2.2. What the Scribe does

The scribe types in a running commentary as to what's going on in the
room. For example, if a speaker makes a presentation, the scribe types
in the URL for the presentation (more on this in a bit).

Simlarly, during question time, a remote participant can type a question
into the room and the scribe can pass it on to the speaker.

2.3. What each Presenter does

Each presenter should put a copy of their presentation on a web server
somewhere, so remote participants can follow along.

2.4. Where to find the conference log

   
http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/

NOTE: the logging facility will not be active until later this week...

                                  #######
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp


Gmane