This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1336328525==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enigCADC6924BAD7521CFFC2A32E"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCADC6924BAD7521CFFC2A32E
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
mharrima101 (sent by Nabble.com) wrote:
Please excuse if this post is not in the correct place - I wasn't sure
where to put a question such as this.
=20
We are using an HP ProCurve switch in our network as a router ( it=E2=80=
=99s a
layer 3 switch ). We are communicating with all devices on the far sid=
e
of the router (HP switch) with SNMP =E2=80=93 including the far side ma=
nagement
interface of the HP switch. When the switch responds to the SNMP query=
it uses the near side IP address as the source address in the UDP heade=
r
=E2=80=93 rather than the far side IP address that the query was addres=
sed to.
Since this is not the IP that we are intending to talk to, our securit=
y
policy does not allow us to accept the message. =20
=20
Is the behavior of the HP switch legal under UPD? It seems to me as
though this should not be allowed.
UDP is connectionless.
=46rom a UDP point of view, it is legal for the HP switch to send a UDP
packet with any IP address from one of its own network interfaces (as
per RFC1122, since it is acting as a host when it sources or sinks traffi=
c).
This may or may not be the case from SNMP's point of view, however, just
as Sec 7.3 of RFC1035 points out a similar DNS "name server bug" (quoted
from the RFC, as others have raised as related).
I.e., this is probably an SNMP bug, possibly an SNMP protocol violation,
but not a UDP issue. (hint: if you have to look at the UDP payload to
decide if it's valid, it's not a UDP issue).
Joe
Well while not illegal it is expected that response should come
from the address the request was sent to. SNMP is a request /
response application and unless otherwise specified the response
should be coming from the address the request was being sent to.
I would say the switch in question was broken.
Mark
4.1.3.5 UDP Multihoming
When a UDP datagram is received, its specific-destination
address MUST be passed up to the application layer.
An application program MUST be able to specify the IP source
address to be used for sending a UDP datagram or to leave it
unspecified (in which case the networking software will
choose an appropriate source address). There SHOULD be a
way to communicate the chosen source address up to the
application layer (e.g, so that the application can later
receive a reply datagram only from the corresponding
interface).
DISCUSSION:
A request/response application that uses UDP should use
a source address for the response that is the same as
the specific destination address of the request. See
the "General Issues" section of [INTRO:1].
--------------enigCADC6924BAD7521CFFC2A32E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFD8gfAE5f5cImnZrsRAl+rAKCOXUa+35mb83cerEIiU185RGpOZwCgpB6G
Z3Tc4vp4KFQj4P+5CBctu0M=
=YC4M
-----END PGP SIGNATURE-----
--------------enigCADC6924BAD7521CFFC2A32E--
--===============1336328525==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
--===============1336328525==--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf