> 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
> [email protected]
> 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: [EMAIL PROTECTED]
_______________________________________________
Ietf mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ietf
