Re: WGLC pim-rpf-vector

Ice,

> >>
> >> As it is now its up to the implementor to decide.
> >
> > Which means that the routers just ignore the F bit. Correct ?
> >
> > It would be useful to spell out that if a router supports a particular
> > TLV, (e.g., the RPF Vector TLV) then the router MUST ignore the value
> > of the F bit carried by the TLV.
> 
> This is how it is documented in the attributes draft:
> 
> F bit, Forward Unknown TLV.  If this bit is set the TLV is forwarded
>     regardless if the router understands the Type.
> 
> Meaning, if the TLV is unknown, you forward if this bit is set.
> 
> I think it is obvious that if the TLV is known, this bit has no  
> relevance.

While this may be "obvious", I think the spec clarify would be
improved by explicitly spelling out that if the TLV is known, the
F bit MUST be ignored.

Yakov.

Re: WGLC pim-rpf-vector

Yakov,

>>
>> This is how it is documented in the attributes draft:
>>
>> F bit, Forward Unknown TLV.  If this bit is set the TLV is forwarded
>>     regardless if the router understands the Type.
>>
>> Meaning, if the TLV is unknown, you forward if this bit is set.
>>
>> I think it is obvious that if the TLV is known, this bit has no
>> relevance.
>
> While this may be "obvious", I think the spec clarify would be
> improved by explicitly spelling out that if the TLV is known, the
> F bit MUST be ignored.

Ok, will add it.

Thx,

Ice.

I-D Action:draft-ietf-pim-lasthop-threats-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Protocol Independent Multicast Working Group of the IETF.

	Title           : Host Threats to Protocol Independent Multicast (PIM)
	Author(s)       : P. Savola, J. Lingard
	Filename        : draft-ietf-pim-lasthop-threats-02.txt
	Pages           : 11
	Date            : 2007-10-05

This memo complements the list of multicast infrastructure security
threat analysis documents by describing Protocol Independent
Multicast (PIM) threats specific to router interfaces connecting
hosts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pim-lasthop-threats-02.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-pim-lasthop-threats-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html

draft-ietf-pim-lasthop-threats-02

Hello,

In response to the lively WGLC feedback and the following BIDIR-PIM 
discussion, I've revised and just published 
draft-ietf-pim-lasthop-threats-02.

Get it here:
http://www.ietf.org/internet-drafts/draft-ietf-pim-lasthop-threats-02.txt

Diffs etc will be available at (when the site gets updated):
http://tools.ietf.org/wg/pim/draft-ietf-pim-lasthop-threats/

I'd be interested in hearing feedback whether I got everything 
covered.  There was substantial revision to consider BIDIR-PIM issues 
as well (Text contributions from Stig were greatly appreciated).

--

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: draft-ietf-pim-lasthop-threats-02

On Fri, 5 Oct 2007, Pekka Savola wrote:
> In response to the lively WGLC feedback and the following BIDIR-PIM 
> discussion, I've revised and just published 
> draft-ietf-pim-lasthop-threats-02.
>
> Get it here:
> http://www.ietf.org/internet-drafts/draft-ietf-pim-lasthop-threats-02.txt
>
> Diffs etc will be available at (when the site gets updated):
> http://tools.ietf.org/wg/pim/draft-ietf-pim-lasthop-threats/
>
> I'd be interested in hearing feedback whether I got everything covered. 
> There was substantial revision to consider BIDIR-PIM issues as well (Text 
> contributions from Stig were greatly appreciated).

Based on Stig's comment, I've made one additional change in my working 
copy, in new Section 2.6:

     In contrast to all the other PIM multicast routing protocols, BIDIR-
     PIM does not use RPF check to verify that the forwarded packets are
     being received from a "topologically correct" direction.

is now:

     PIM protocols do not perform RPF check on the shared tree (e.g., in
     PIM-SM from the RP to local receivers).  On the other hand, RPF
     check is performed e.g., on stub host interfaces. Because all
     forwarding in BIDIR-PIM is based on the shared tree principle, it
     does not use RPF check to verify that the forwarded packets are
     being received from a "topologically correct" direction.

New Version Notification for draft-ietf-pim-lasthop-threats-02

A new version of I-D, draft-ietf-pim-lasthop-threats-02.txt has been successfuly submitted by Pekka
Savola and posted to the IETF repository.

Filename:	 draft-ietf-pim-lasthop-threats
Revision:	 02
Title:		 Host Threats to Protocol Independent Multicast (PIM)
Creation_date:	 2007-10-05
WG ID:		 pim
Number_of_pages: 11

Abstract:
This memo complements the list of multicast infrastructure security
threat analysis documents by describing Protocol Independent
Multicast (PIM) threats specific to router interfaces connecting
hosts.

The IETF Secretariat.

Regarding (s,g) and (*,g) assert mechanism...

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

Re: Regarding (s,g) and (*,g) assert mechanism...

snibad initiated a hyperspace jump with:
> Hi all , I have a doubt in assert mechanism ... why is the following
> paragraph specified
> 
> in PIM RFC is needed ... anyone pls shed some light on it ...
> 
> "It is important to note that NO TRANSITION CAN OCCUR in the (*,G) state
> machine as a result of receiving an Assert message unless the (S,G)
> assert state machine for the relevant S and G is in the "NoInfo" state
> after the (S,G) state machine has processed the message.  Also NO
> TRANSITION CAN OCCUR in the (*,G) state machine as a result of receiving
> an assert message if that message triggers any change of state in the
> (S,G) state machine.

If the (S,G) assert winner sends a (*,G) assert then the losers will
see the assert as inferior and transition to No Info. Additionally,
you only want to cause churn to the (*,G) tree if there are two or more
routers actually forwarding active traffic on the (*,G) tree. In the loser
transition, this may not be the case.

On receiving such and it causes a transition in the (S,G) state machine
its one of the following:
a) no info -> winner
b) winner -> winner
c) loser -> no info (if the winner sent it)

So you don't process it if the router transitions to winner, is the winner,
or the winner sent the assert.

> For example, if both the (S,G) and (*,G) assert state machines where in
> the NoInfo state when an Assert message arrives, and the message causes
> the (S,G) state machine to transition to either "W" or "L" state, then
> the assert would not be processed by the (*,G) assert state machine.

This is case a from above.

This is misleading there is no transition to "L" from No Info.

> Another example: if the (S,G) assert state machine is in "L" state when
> an assert message is received, and the assert metric in the message is
> worse than my_assert_metric(S,G,I), then the (S,G) assert state machine
> will transition to NoInfo state.  In such a case if the (*,G) assert
> state machine were in NoInfo state, it might appear that it would
> transition to "W" state, but this is not the case because this message
> already triggered a transition in the (S,G) assert state machine."

This is case c from above.

This is misstated. It will only transition to No Info if the assert
is worse than my_assert_metric(S,G,I) and it is received from the
current assert winner.

Chris

I-D Action:draft-ietf-pim-lasthop-threats-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Protocol Independent Multicast Working Group of the IETF.

	Title           : Host Threats to Protocol Independent Multicast (PIM)
	Author(s)       : P. Savola, J. Lingard
	Filename        : draft-ietf-pim-lasthop-threats-03.txt
	Pages           : 11
	Date            : 2007-10-10

This memo complements the list of multicast infrastructure security
threat analysis documents by describing Protocol Independent
Multicast (PIM) threats specific to router interfaces connecting
hosts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pim-lasthop-threats-03.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-pim-lasthop-threats-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pim-lasthop-threats-03.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

pim wg last call on draft-ietf-pim-lasthop-threats-03.txt

This message announces a pim wg last call on "Host Threats to Protocol
Independent Multicast (PIM)"  <draft-ietf-pim-lasthop-threats-03.txt>.
The last call will conclude at 1700EDT on Mon, 2007-10-24.

Please respond to this wg last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the wg last call, the document will not be advanced
to the IESG.

draft-ietf-pim-lasthop-threats-03.txt describes Protocol Independent
Multicast (PIM) threats specific to router interfaces connecting hosts.
It is available at
http://www.ietf.org/internet-drafts/draft-ietf-pim-lasthop-threats-03.txt

Note that there was a wglc on revision 01 of this draft a few weeks ago
(Aug 26 to Sep 10).  Several issues were brought up which this revision
tries to address.

Stig