Subject: (ION) RFC 2332 - authentication

From: Archana Nehru <[email-masked]>
Date: Thu, 25 Feb 1999 17:41:46 -0800

Hi,

I have a question about the authentication extension in RFC 2332(NHRP).

RFC 2332 says that "authentication data" on a NHRP packet is generated
after zeroing out the "authentication data" field at both the sender and
the receiver. This is done so that the "hash" computed over the NHRP
packet is the same at both the ends(refer to section 5.3.4.3)

Now the problem here is that there is a dependency between the
"checksum" and the "authentication data" calculated on the NHRP packet.

At the source, the "checksum" over the NHRP packet is computed after the
"authentication data" is filled into the NHRP packet. Note that we are
modifying the "checksum" field of the packet after computing the
"authentication data" over the NHRP packet.

This means that at the receiving end, the receiver not just has to zero
out the "authentication data" field but also must zero out the 
"checksum" field before computing the "authentication data",
otherwise the hash computed over the NHRP packet will never match.

Is this true or not? I appreciate any input on this.

Regards
Archana

________________________________________________________________________
Archana Nehru                     :  Trillium Digital Systems, Inc 
E-mail: [email-masked]       :  Los Angeles, California     
Phone: +1 310 442 9222     
________________________________________________________________________
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Navin Kumar Agarwal <[email-masked]>
Date: Wed, 3 Mar 1999 16:45:19 +0530 (IST)

Hi All,

If an NHC (with routing capability) comes in the routed path of an NHRP
Resolution Request packet destined for some host, what will be the NHCs
behaviour? 

Though the section 2.2 of RFC2332 specifies (as rewritten below) that 
only NHSs should come in the path. How do we control routing table lookup 
result in the case NHRP stations are running dynamic routing protocols?

   "If a serving NHS is to be able to supply the address resolution
   information for an NHC then NHSs must exist at each hop along all
   routed paths between the NHC making the resolution request and the
   destination NHC."

Thanks in anticipation.

Regards,
Navin

---

From: "Srinivasan.E.Seshadri" <[email-masked]>
Date: Wed, 03 Mar 1999 11:30:15 -0500

Hi Navin,

 Let me float my ideas..

 An NHC is not required to process any of the incoming NHRP resolution requests.
In fact, it is always the serving NHS (In case of the so called "A" bit being
set) or a transit NHS (In case of A bit being not set and a mapping exist at the
particular NHS) is the one which will respond for all the NHRP resolution
queries. Even if an NHC is situated along the routed path, the same system
should be co-locating an NHS in order for NHRP to work properly. Otherwise, the
packet will not get forwarded and it would result in some kind of error
indications towards the source NHC by the previous NHS itself.

Even, if the NHC is in possession of the NHRP packet (which can only happen due
to misconfiguration at the previous hop), the best thing it could do is to drop
the packet as it is not meant for forwarding the NHRP packets..

Hope i get across.

--E.S.
__________________________
Srinivasan.E.Seshadri
Ficon Technology
E-mail: [email-masked] | [email-masked]
Web:    www.ficon-tech.com

---

From: Navin Kumar Agarwal <[email-masked]>
Date: Fri, 5 Mar 1999 14:00:49 +0530 (IST)

Hi Srini,

Thanks for your reply. Please See my comments below.

--Navin

> indications towards the source NHC by the previous NHS itself.

	When we say that an NHC is coming in the routed path, this means 
that it is having routing functionality co-located in it or in other 
words, its a routing peer. if so is the case, it should be able to 
forward the resolution request packet. I give reference of Sec 4.0 of 
RFC2332 for supporting my argument.

> the packet as it is not meant for forwarding the NHRP packets..

	If that is the case, shouldn't be mentioned under the functionality 
of an NHC station in the RFC2332.