Subject: Re: A query on RIPv2

From: Stewart Bryant <[email-masked]>
Date: Thu, 28 Feb 2013 15:03:36 +0000

The confusion seems to be whether the AH, which gets carried as
a special type of RIP entry, is an RTE or not.

I can see arguments both ways, although the fact that this has taken
25 years to surface suggests that most implementers have
subscribed to a common view that the an AH is not an RTE,
and therefore the RFC is correct.

I propose that we close this as an errata to be fixed in next version
with the statement:

"Some readers have been confused as to whether an AH is considered
to be an RTE. The consensus view it that that it is not. If this
RFC is revised, some clarifying text should be added."

Is that a reasonable way forward?

Stewart

On 02/01/2013 06:08, Bharat Joshi wrote:
> Dear Gopakumar,
>
>         I understand what you are saying. In fact, I tested some vendor's behaviour to understand how other people have implemented it.
>
>         When authentication is enabled, there should be 2 route entries for things to work but I still feel that the RFC is not clear enough on this. In fact, in my search, I found that Quagga has issues with this.
>
> Regards,
> Bharat
> ________________________________________
> From: Gopakumar C [[email-masked]]
> Sent: Wednesday, January 02, 2013 11:05 AM
> To: Bharat Joshi; [email-masked]
> Subject: RE: A query on RIPv2
>
> Dear Bharat,
>
> In the scenario that you mentioned RIP packet will have two RTEs after the RIP header, first one will be authentication RTE and second one will be FULL table request RTE with address family identifier as 0. This may be followed by authentication trailer depending on the authentication scheme selected.
>
> RFC section 3.9.1 first states the general format of RIP Version 2 request message. Even though authentication is present, there is only one RTE (full table RTE) other than authentication as authentication RTE doesn't convey routing information.
>
> Hope this helps.
>
> Note: I think this is not correct forum to discuss this issue. I am not sure where you can post it as RIP mailing list is not active anymore.
>
> Regards,
> -Gopakumar
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Bharat Joshi
> Sent: Tuesday, December 25, 2012 4:02 PM
> To: [email-masked]
> Cc: Bharat Joshi
> Subject: A query on RIPv2
>
> Hi All,
>
>       I came across some text in RFC 2453 (RIPv2) which has confused me. It would be great if someone can clarify this for me. I searched the net and looked through the errata but could not find any reference to this.
>
> In section 3.9.1 of RFC 2453 (http://tools.ietf.org/html/rfc2453#section-3.9.1), in second para, following text is available:
>
> <quote>
>
>     There is one special case.  If there is exactly
>     one entry in the request, and it has an address family identifier of
>     zero and a metric of infinity (i.e., 16), then this is a request to
>     send the entire routing table.
>
> <unquote>
>
> In section 4.1 of same RFC (http://tools.ietf.org/html/rfc2453#section-4.1), in first para, following text is available:
>
> <quote>
>
>     If the Address Family Identifier of the first (and
>     only the first) entry in the message is 0xFFFF, then the remainder of
>     the entry contains the authentication.
>
> <unquote>
>
>      Now what has confused me is that if a router is configured to use authentication, how should its 'request' message for full routing table look? Should it go without authentication information or with authentication information?
>
>      If it goes with authentication information then it is not conforming to the statement of 3.9.1. If it goes without authentication information then it is not conforming to the user configuration and also there may be security issues.
>
> Regards,
> Bharat
>
> PS: I am currently not subscribed to RTG working group mailing list, so please reply all so that I can get your reply.
>
>
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
> for the use of the addressee(s). If you are not the intended recipient, please
> notify the sender by e-mail and delete the original message. Further, you are not
> to copy, disclose, or distribute this e-mail or its contents to any other person and
> any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
> every reasonable precaution to minimize this risk, but is not liable for any damage
> you may sustain as a result of any virus in this e-mail. You should carry out your
> own virus checks before opening the e-mail or attachment. Infosys reserves the
> right to monitor and review the content of all messages sent to or from this e-mail
> address. Messages sent to or from this e-mail address may be stored on the
> Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
> .
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Acee Lindem <[email-masked]>
Date: Thu, 28 Feb 2013 15:44:14 +0000

Hi Stewart, 
To retain compatibility with RIPv1, the RIPv2 WG kept the packets formatted as a variable number of 20 byte entries. The one containing the authentication is, well, the authentication and, by definition, is not a route. I'm don't think this needs any clarification. 
Thanks, 
Acee

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 28 Feb 2013 16:19:48 +0000

That is a valid response and I agree that the text is strictly
correct. However there also appears to be an existence
proof that more than one reader was confused (the
reference to Quagga).

It would be at least charitable  to has some text somewhere
that unconfused such a reader and the only way I can see
to do this is either to add an accepted errata or a fixed in
next version saying something like.

In section 3.9.1 "Note that an authentication header is
not considered to be an RTE".

Yes/No/Other proposals?

- Stewart

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 Feb 2013 12:05:34 -0500

That works for me.
Yours,
Joel

On 2/28/2013 11:19 AM, Stewart Bryant wrote:
>> To retain compatibility with RIPv1, the RIPv2 WG kept the packets
>> formatted as a variable number of 20 byte entries. The one containing
>> the authentication is, well, the authentication and, by definition, is
>> not a route. I'm don't think this needs any clarification.
>> Thanks,
>> Acee
>>
>>>>         I understand what you are saying. In fact, I tested some
>>>> vendor's behaviour to understand how other people have implemented it.
>>>>
>>>>         When authentication is enabled, there should be 2 route
>>>> entries for things to work but I still feel that the RFC is not
>>>> clear enough on this. In fact, in my search, I found that Quagga has
>>>> issues with this.
>>>>
>>>> Regards,
>>>> Bharat
>>>> In the scenario that you mentioned RIP packet will have two RTEs
>>>> after the RIP header, first one will be authentication RTE and
>>>> second one will be FULL table request RTE with address family
>>>> identifier as 0. This may be followed by authentication trailer
>>>> depending on the authentication scheme selected.
>>>>
>>>> RFC section 3.9.1 first states the general format of RIP Version 2
>>>> request message. Even though authentication is present, there is
>>>> only one RTE (full table RTE) other than authentication as
>>>> authentication RTE doesn't convey routing information.
>>>>
>>>> Hope this helps.
>>>>
>>>> Note: I think this is not correct forum to discuss this issue. I am
>>>> not sure where you can post it as RIP mailing list is not active
>>>> anymore.
>>>>
>>>> Regards,
>>>> -Gopakumar
>>>>
>>>>       I came across some text in RFC 2453 (RIPv2) which has confused
>>>> me. It would be great if someone can clarify this for me. I searched
>>>> the net and looked through the errata but could not find any
>>>> reference to this.
>>>>
>>>> In section 3.9.1 of RFC 2453
>>>> (http://tools.ietf.org/html/rfc2453#section-3.9.1), in second para,
>>>> following text is available:
>>>>
>>>> <quote>
>>>>
>>>> In section 4.1 of same RFC
>>>> (http://tools.ietf.org/html/rfc2453#section-4.1), in first para,
>>>> following text is available:
>>>>
>>>> <quote>
>>>>
>>>>      Now what has confused me is that if a router is configured to
>>>> use authentication, how should its 'request' message for full
>>>> routing table look? Should it go without authentication information
>>>> or with authentication information?
>>>>
>>>>      If it goes with authentication information then it is not
>>>> conforming to the statement of 3.9.1. If it goes without
>>>> authentication information then it is not conforming to the user
>>>> configuration and also there may be security issues.
>>>>
>>>> Regards,
>>>> Bharat
>>>>
>>>> PS: I am currently not subscribed to RTG working group mailing list,
>>>> so please reply all so that I can get your reply.
>>>>
>>>>